En este segundo post vamos a ver la forma en la que vamos a crear las máquinas y adecuarlas para la instalación de k0s.
Características
Las características de los nodos que van a formar parte del cluster dependen totalmente de las nuestras necesidades y de los recursos que tengamos a nuestra disposición.
Para este caso vamos a desplegar 6 máquinas con las siguientes características:
- Control Plane
- 8 CPU
- 16GB RAM
- 150GB de disco principal
- Workers
- 8 CPU
- 16GB RAM
- 150GB de disco principal
- 5 TB para ser utilizado por Ceph
Creación de las VMs
Para la creación de los nodos que forman parte del cluster dependerá de las opciones que tengamos en nuestro entorno.
Habitualmente podremos crear las máquinas desde la interfaz web del hypervisor como VMWare o ProxmoxVE. Con una plantilla o clonando una máquina podemos tener en pocos minutos todas las máquinas disponibles.
Si está disponible la opción ideal sería utilizar un sistema de provisionamiento como Terraform. A través de su arquitectura de infrastructure as code podemos crear una configuración para nuestro cluster que, al aplicarla, hará todas las modificaciones necesarias para crear o destruir recursos.
De esta forma podemos tener en unos segundos todo disponible y además la posibilidad de añadir fácilmente nodos o recursos a los nodos.
Todas las pruebas de este cluster se han realizado utilizando Terraform pero en el entorno de despliegue no está disponible así que solicitamos la creación de las máquinas al departamento correspondiente.
Comprobaciones previas con Ansible
Dado que vamos a estar haciendo operaciones sobre las máquinas del cluster constantemente, realizarlo de manera manual haciendo SSH a cada nodo y ejecutando comandos es tremendamente ineficiente. Además del tiempo es muy posible que al ser tareas manuales terminemos teniendo configuraciones diferentes entre las máquinas. Esta circunstancia es algo que debemos intentar evitar especialmente en un cluster donde lo que buscamos es que la infraestructura sea lo más homogénea posible.
Para realizar todas las comprobaciones y configuraciones en las máquinas vamos a utilizar la herramienta más habitual de automatización que es ansible.
Añadimos la siguiente configuración en el inventario local de ansible:
Y procedemos a hacer un ping para ver que todo está correctamente configurado:
Para ansible pueda acceder a los nodos tendremos que tener SSH configurado, habitualmente añadiendo nuestra clave pública en la máquina remota.
Comprobamos que todos los equipos están usando el mismo kernel:
Actualización
Al revisar las máquinas vemos que hay diferentes versiones de Red Hat instaladas:
Para minimizar problemas procedemos a actualizar todos los nodos a la última versión disponible:
ansible cluster -m shell -a 'dnf update -y'Después de varios minutos de actualizaciones el comando finaliza y procedemos a reiniciar las máquinas:
ansible cluster -m shell -a 'reboot'Al reiniciarse las máquinas comprobamos que las versiones ya son todas iguales:
Redimensionado de las particiones
En las máquinas entregadas existe espacio sin particionar. Afortunadamente todas las instancias son iguales así que podremos redimensionarlas a la vez de forma remota.
Ya tengo un artículo sobre como aumentar el espacio en una máquina con LVM. En esta ocasión vamos a tener que repetir los pasos pero ejecutándolos con ansible en todas las instancias en paralelo.
Si ejecutamos un vgdisplay vemos que tenemos casi 100GB sin asignar.
El logical volume a redimensionar será el /dev/rhel/var. Lo ampliaremos con todo el espacio disponible en el VG porque en el /var es donde se instala k0s y donde utiliza todo el espacio.
Ejecutaremos lvextend en todas las máquinas del cluster.
Y finalmente extenderemos el sistema de ficheros que en este caso es XFS con el comando xfs_growfs /mount/point.
Y finalmente comprobamos que se han ampliado todas las particiones correctamente.
Comprobaciones de red
Los nodos de un cluster de Kubernetes se tienen que comunicar utilizando una serie de puertos que pueden estar bloqueados en algunos entornos.
Antes de desplegar el cluster debemos asegurarnos de que estos se encuentran abiertos para no encontrarnos problemas en el futuro.
El primer acceso necesario es por SSH a todos los nodos pero esto ya sabemos que funciona porque lo estamos utilizando con Ansible.
En la documentación oficial de Kubernetes podemos encontrar los puertos y protocolos necesarios para hacer funcionar un cluster.
En el caso de Red Hat la utilidad netcat está en el paquete nmap-ncat que instalo en todas las máquinas para poder hacer las pruebas.
Una forma sencilla de probar la conectividad es por parejas de máquinas ejecutar en una:
# nc -l port_numbery en otra:
# nc ip_address_to_test port_numberY mandar algunos caracteres para ver que aparecen en la máquina destino y viceversa.
Tendremos que repetir esto para todos los puertos que están en la documentación de Kubernetes o al menos los puertos que sabemos con toda seguridad que vamos a utilizar como los de la API y similares.
En un entorno corporativo restrictivo este paso es crítico porque si desplegamos el cluster sin tener la total seguridad de que existe comunicación entre las máquinas nos vamos a encontrar con problemas difíciles de depurar.
Monitorización
El último paso de las comprobaciones previas sería el añadir los nodos del cluster al sistema de monitorización que estemos utilizando.
En el día a día del cluster estaremos haciendo uso de la capa de kubernetes o configurando algo desde fuera con k0sctl. Lo que no se nos puede olvidar es que cada uno de los nodos que componen el cluster son máquinas físicas o virtuales que deben ser monitorizadas y actualizadas como cualquier servidor.
Es cierto que corriendo un sólo servicio y que éste esté bastante aislado del sistema operativo es poco probable que nos encontremos con problemas de seguridad originados en el sistema operativo pero en cualquier caso es recomendable tenerlo siempre actualizado con los paquetes oficiales.
Comentarios