Desplegando un cluster productivo de OKD

En este artículo vamos a explicar el proceso para el despliegue de un cluster productivo de OKD sobre un virtualizador de KVM en el cual no disponemos de cloud-init por lo que el proceso de despliegue se hace siguiendo la documentación como si lo desplegasemos sobre un entorno de baremetal, de hecho este mismo artículo serviría si queremos hacer el despliegue sobre un entorno baremetal.

Denominamos este cluster como productivo, ya que vamos a hacer un despliegue de un total de 5 nodos de Fedora CoreOS, de los cuales 3 servidores van a corresponderse con nodos master y 2 de ellos serán los denominados nodos worker, para entender mejor este despliegue, os dejo una imagen con un esquema de los componentes con sus IPs de tal forma que si a lo largo del artículo no se entiende alguno de los elementos se pueda revisar la imagen para entenderlo mejor.

Para comenzar, debemos conocer los requisitos para el despliegue de un cluster de este estilo. En primer lugar, vamos a necesitar de un DNS privado que resuelva dominios con una definición estándar, así como sus registros inversos, importante el paso de la resolución inversa de los dominios, ya que si esto no se produce, te encontrarás un entorno que parece que despliega, pero que realmente se queda bloqueado por ciertos operadores de cluster y nunca termina de desplegarse por completo.

Si disponemos de un servidor DNS configurado con bind puedes directamente usar ese, si no tienes ningún servidor DNS privado y quieres instalar uno rápidamente te recomiendo crear una máquina virtual/servidor ligero e instalar pi-hole cuyo software nos proporciona la posibilidad de crear los registros necesarios para un cluster de OKD, en la imagen a continuación podéis ver como se definen estos registros (muy importante conservar los nombres DNS tal cual indica la documentación {master0, master1, worker0, worker1,…}.{cluster_name}.{dominio})

El segundo requisito es la necesidad de un balanceador de carga externo al propio cluster, si no dispones de ninguno la propia documentación te recomienda usar haproxy, por lo que para este despliegue vamos a hacer uso de este software.

Siguiendo con las recomendaciones de la documentación creamos el cluster creando el fichero de configuración del haproxy (/etc/haproxy/haproxy.cfg) como sigue.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

global
  log         127.0.0.1 local2
  pidfile     /var/run/haproxy.pid
  maxconn     4000
  daemon
defaults
  mode                    http
  log                     global
  option                  dontlognull
  option http-server-close
  option                  redispatch
  retries                 3
  timeout http-request    10s
  timeout queue           1m
  timeout connect         10s
  timeout client          1m
  timeout server          1m
  timeout http-keep-alive 10s
  timeout check           10s
  maxconn                 3000
listen api-server-6443
  bind *:6443
  mode tcp
  server bootstrap bootstrap.okd-pro.alefnode.com:6443 check inter 1s backup
  server master0 master0.okd-pro.alefnode.com:6443 check inter 1s
  server master1 master1.okd-pro.alefnode.com:6443 check inter 1s
  server master2 master2.okd-pro.alefnode.com:6443 check inter 1s
listen machine-config-server-22623
  bind *:22623
  mode tcp
  server bootstrap bootstrap.okd-pro.alefnode.com:22623 check inter 1s backup
  server master0 master0.okd-pro.alefnode.com:22623 check inter 1s
  server master1 master1.okd-pro.alefnode.com:22623 check inter 1s
  server master2 master2.okd-pro.alefnode.com:22623 check inter 1s
listen ingress-router-443
  bind *:443
  mode tcp
  balance source
  server worker0 worker0.okd-pro.alefnode.com:443 check inter 1s
  server worker1 worker1.okd-pro.alefnode.com:443 check inter 1s
listen ingress-router-80
  bind *:80
  mode tcp
  balance source
  server worker0 worker0.okd-pro.alefnode.com:80 check inter 1s
  server worker1 worker1.okd-pro.alefnode.com:80 check inter 1s

A continuación será necesario volver a la máquina de pi-hole para añadir un elemento, la resolución mediante wildcard de todas las apps que se vayan a desplegar en el cluster, para esta tarea debemos añadir en el directorio /etc/dnsmasq.d y agreguemos un fichero 02-cluster-okd.conf con la línea:

1

address=/apps.okd-pro.alefnode.com/192.168.6.18

En donde le indiquemos que apps.nombrecluster.dominio resuelva la dirección ip del haproxy

Una vez dispongamos de estos dos elementos esenciales, podremos comenzar con la creación del cluster, esto significa que debemos conocer primero un poco sobre como funciona CoreOS, básicamente se trata de un sistema operativo de carácter inmutable y cuya finalidad es buscar la estabilidad de la máquina o instancia, se intenta que el sistema operativo tenga la mayor parte posible de directorios en modo solo lectura de cara a evitar posibles puntos de fallo al modificar ficheros del sistema, para realizar una instalación sobre este tipo de sistemas operativos necesitamos generar los denominados ficheros ignition que se pasan en el arranque de la máquina y se ejecutan en el initramfs, de esta forma se aseguran que las modificaciones quedan hechas para todos los reinicios y se evita la modificación posterior de elementos del sistema.

Para crear estos ficheros ignition la comunidad de OKD (y Red Hat) nos proporciona una serie de binarios, los cuales permiten crear y modificar estos ficheros ignition, este tipo de instalación que vamos a realizar es la denominada como UPI (User Provided Infrastructure) en la cual intentamos no depender o lo que es lo mismo abstraernos en todo lo posible de instaladores que realicen todo el trabajo sobre nuestros equipos sin tener el conocimiento de realmente que es lo que están haciendo.

Por lo que descargamos el binario de OKD que nos permite generar los ficheros de configuración. En nuestro caso estamos usando openshift-install-linux-4.14.0-0.okd-2023-11-14-101924.tar.gz estos ficheros se pueden obtener del enlace https://github.com/okd-project/okd/releases también tenemos que descargar el fichero client para nuestra plataforma, siempre usando la misma versión.

1
2
3
4
5
6
7

export cluster_name=okd-pro
mkdir odk
cd okd
tar -xzvf openshift-install-linux-4.14.0-0.okd-2023-11-14-101924.tar.gz
tar -xzvf openshift-client-linux-4.14.0-0.okd-2023-11-14-101924.tar.gz
mkdir ${cluster_name}
cd ${cluster_name}

Una vez tengamos la estructura de carpetas creada, añadimos el fichero install-config.yaml (muy importante que la extensión sea yaml, no yml) con contenido tal que así.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

apiVersion: v1
baseDomain: alefnode.com
compute:
- hyperthreading: Disabled
  name: worker
  replicas: 0
controlPlane:
  hyperthreading: Disabled
  name: master
  replicas: 3
metadata:
  name: ${cluster_name}
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/16
    hostPrefix: 24
  networkType: OpenShiftSDN
  serviceNetwork:
  - 172.30.0.0/16
platform:
  none: {}
fips: false
pullSecret: '${pull_secret}'
sshKey: '${cluster_pubkey}'

Una vez tengamos definido esto, tan solo tendremos eu ejecutar:

1

./openshift-install create manifests --dir ${cluster_name}

Esto nos genera una serie de ficheros yml que podemos editar y configurar a nuestro gusto por si necesitamos hacer una instalación más personalizada, si no es nuestro caso, tan solo tendremos que asegurarnos que el fichero ${cluster_name}/manifests/cluster-scheduler-02-config.yml tiene el parámetro mastersSchedulable: false, ya que estamos realizando un despliegue de 5 nodos.

Y con el mismo binario ejecutamos la creación de los ficheros ignition ./openshift-install create ignition-configs –dir ${cluster_name}

Para poder usar estos ficheros necesitamos que se encuentren en un servidor HTTP/HTTPS, en nuestra caso no disponemos de ninguno, por lo que vamos a usar la máquina virtual en la que hemos instalado el haproxy para instalar un servicio web en un puerto alternativo de uso temporal. Nos conectamos via ssh a la máquina e instalamos un servidor nginx y lo levantamos en el puerto 1080 (el 80 está siendo usado por el propio balanceador)

1
2
3

sudo apt install nginx
sudo sed -i "s/listen 80/listen 1080/g /etc/nginx/sites-available/default"
sudo systemctl enable --now nginx

Lo siguiente es conseguir la ISO que vamos a utilizar para la creación del cluster y para ello podemos obtener los enlaces con el siguiente comando:

1

./openshift-install coreos print-stream-json | grep '\.iso[^.]'

En nuestro caso lo descargamos en el Proxmox y lo ponemos como iso de arranque para cada máquina que vamos a desplegar.

Una vez tengamos nuestros nodos preparados procederemos con la instalación de los nodos, arranca el servidor con la ISO y en el menudo pulsa TAB y luego añade:

ip=192.168.6.20::192.168.5.1:255.255.255.0::ens18:none nameserver=192.168.6.15

Ten en cuenta que la interfaz puede ser otra distinta en función si estás usando una máquina virtual o una máquina física, si no sabes el nombre de la interfaz puedes arrancar sin nada escrito y revisarlo antes de comenzar el procedimiento, es importante que las ips encajen con los DNS por ello es importante o bien fijarlas mediante DHCP (si las fijas mediante DHCP no necesitarías este paso) o bien definirlas durante el arranque como una ip estática (y para esto usamos la línea indicando los datos de red en el arranque)

Una vez el sistema arranque procedemos a la instalación en el disco.

1

sudo coreos-installer --ignition-url=http://okd-pro.alefnode.com:1080/bootstrap.ign --insecure-ignition --insecure -n /dev/sda

Fijándonos el comando es importante observar que se le indica la ruta del fichero ignition que vamos a utilizar (bootstrap.ign, master.ign o worker.ign) así como el dispositivo de almacenamiento donde se instalará. También le indicamos que conserve la configuración de red que definimos en el paso anterior (opción -n), así como los parámetros insecure, ya que no hemos añadido certificado SSL a nuestro servidor nginx.

Una vez termine apagamos la máquina, retiramos la ISO de instalación y la encendemos.

Esperaremos a que el nodo bootstrap termine de arrancar correctamente antes de proceder a repetir los pasos para los demás nodos.

Repetiremos este paso para cada uno de los nodos de nuestro cluster, tanto para los master como para los worker.

Para saber el estado en el que se encuentra la instalación podemos utilizar el comando:

1

watch -n 5 ./oc get clusteroperators

Una vez todos los componentes se encuentren en Ready tendrás el cluster de OKD instalado.

Por cierto mencionar que el consumo de recursos para el despliegue de un OKD productivo básico es bastante elevado.