Construcción de una nube privada sobre hardware físico con Kubernetes y Talos Linux

En una publicación del blog de Kubernetes en abril de 2024, Andrei Kvapil de Ænix describió un método para construir una infraestructura de nube privada utilizando únicamente tecnologías de código abierto. La guía se centra en la preparación de servidores de hardware físico para alojar clústeres de Kubernetes gestionados, alejándose de las capas de virtualización tradicionales como OpenStack.

Qué ocurrió

Kvapil describió el proceso de creación de Cozystack, una plataforma diseñada para ejecutar clústeres de Kubernetes de inquilinos directamente sobre hardware físico. Este enfoque desafía la práctica común de utilizar OpenStack para gestionar servidores de hardware físico antes de instalar Kubernetes encima. En su lugar, aprovecha Kubernetes mismo para manejar la complejidad de la gestión de la infraestructura, con el objetivo de reducir el número de sistemas complejos en el ecosistema.

El artículo sirve como la primera parte de una serie que detalla esta arquitectura. Cubre los cimientos iniciales necesarios para preparar los centros de datos, incluyendo la ejecución de máquinas virtuales, el aislamiento de redes y la configuración de almacenamiento tolerante a fallos. El objetivo es aprovisionar clústeres de Kubernetes completos que soporten la provisión dinámica de volúmenes, balanceadores de carga y escalado automático sin depender de proveedores de nube externos.

Cómo funciona

La distinción principal radica en cómo opera Kubernetes en la nube frente al hardware físico. En las nubes públicas, servicios como los volúmenes persistentes, los balanceadores de carga y el aprovisionamiento de nodos son gestionados externamente por el proveedor. Esto permite tratar los nodos como utilidades efímeras que pueden eliminarse y recrearse fácilmente. En el hardware físico, estos servicios deben ejecutarse dentro del clúster, lo que hace que las actualizaciones y el mantenimiento sean significativamente más complejos porque los servidores físicos no pueden simplemente eliminarse y reemplazarse como las máquinas virtuales.

Para abordar esto, la guía recomienda usar Talos Linux, un sistema operativo especializado diseñado para Kubernetes. Talos permite definir toda la configuración del sistema en un único archivo. Este enfoque declarativo habilita las actualizaciones de módulos del kernel y componentes de Kubernetes sin requerir la recreación completa del nodo o la migración de servicios. El equipo de Ænix utiliza este método para integrar los módulos del kernel necesarios, como ZFS y DRBD, en una imagen de sistema personalizada.

Para el despliegue, el proceso utiliza arranque PXE. Servidores DHCP y PXE temporales se ejecutan dentro de contenedores para entregar la imagen personalizada de Talos Linux a los nodos físicos. Un script de inicialización luego prepara los nodos y establece el plano de control inicial de Kubernetes. Una vez que el clúster base está funcionando, se utilizan herramientas GitOps como FluxCD para instalar y gestionar los componentes del sistema, asegurando que el clúster mantenga su estado deseado mediante charts Helm declarativos.

Detalles clave

• La guía aboga por reemplazar OpenStack con un enfoque nativo de Kubernetes para reducir la complejidad del ecosistema.
• Talos Linux se utiliza como sistema operativo base debido a su modelo de configuración inmutable y declarativa.
• Las imágenes de sistema personalizadas se construyen usando Docker para incluir módulos específicos del kernel como ZFS, DRBD y OpenvSwitch.
• Se emplea el arranque PXE para entregar la imagen del SO a los servidores de hardware físico durante el aprovisionamiento inicial.
• Se recomienda FluxCD sobre ArgoCD para gestionar los componentes del sistema y mantener la uniformidad del clúster mediante GitOps.
• El proceso de inicialización inicial puede desplegar un clúster de Kubernetes funcional sobre hardware físico en aproximadamente cinco minutos.

Por qué importa

Para los equipos de ingeniería que gestionan su propio hardware, este enfoque ofrece un camino hacia la agilidad tipo nube sin la sobrecarga de mantener plataformas de virtualización separadas. Al tratar la infraestructura como código y utilizar sistemas operativos inmutables, los equipos pueden reducir el riesgo de desviación de configuración y simplificar el proceso de actualización. Esto es particularmente relevante para organizaciones que necesitan un control estricto sobre sus datos y hardware, pero aún desean los beneficios operativos de Kubernetes.

Sin embargo, este método transfiere una responsabilidad significativa al equipo de infraestructura. A diferencia de los servicios de nube gestionados, los ingenieros deben encargarse ellos mismos de la red, el almacenamiento y la aplicación de parches de seguridad. La complejidad pasa de gestionar múltiples sistemas dispares a comprender profundamente la interacción entre Kubernetes, el sistema operativo subyacente y el hardware físico. Esto requiere un nivel superior de experiencia, pero puede resultar en una infraestructura más ágil y rentable para despliegues a gran escala.

Qué puedes hacer

• Evalúa Talos Linux como sistema operativo base para tus clústeres de Kubernetes en hardware físico para simplificar la gestión de nodos.
• Implementa prácticas GitOps usando FluxCD para gestionar declarativamente los componentes del sistema y los charts Helm.
• Construye imágenes de sistema personalizadas usando Docker para incluir módulos específicos del kernel como ZFS, DRBD y OpenvSwitch.
• Utiliza el arranque PXE para entregar la imagen del SO a los servidores de hardware físico durante el aprovisionamiento inicial.
• Considera FluxCD sobre ArgoCD para gestionar componentes del sistema y mantener la uniformidad del clúster vía GitOps.
• Prueba el proceso de inicialización para ver si puedes desplegar un clúster funcional en unos cinco minutos.