En las entradas previas se analizó el uso de Docker y Docker Compose para la creación y ejecución de aplicaciones en entornos aislados. Si bien estas herramientas resuelven eficazmente el empaquetado y la ejecución local, presentan limitaciones significativas al trasladarse a entornos de producción de alto tráfico.
La gestión manual de contenedores en un solo servidor carece de mecanismos nativos para garantizar la alta disponibilidad o el escalado dinámico. Ante la necesidad de operar sistemas distribuidos complejos, surge Kubernetes (K8s) como el estándar de la industria para la orquestación de contenedores.
La Motivación: De la gestión manual a la automatización declarativa
La principal razón para adoptar Kubernetes no es simplemente «ejecutar contenedores», sino cambiar el modelo de operación de la infraestructura.
En un enfoque tradicional, la administración de servidores requiere una intervención manual constante: si un servicio falla, un operador debe reiniciarlo; si aumenta la carga, se deben aprovisionar nuevos recursos manualmente. Este modelo no es escalable.
Kubernetes introduce un modelo declarativo. En lugar de ejecutar comandos para realizar acciones (enfoque imperativo), se define el «estado deseado» del sistema (por ejemplo: «se requieren tres réplicas de la aplicación web con 2GB de RAM cada una»). La plataforma se encarga de:
- Auto-reparación (Self-healing): Monitorización continua de los procesos. Si un contenedor falla o un nodo deja de responder, el sistema lo reinicia o lo reprograma automáticamente en otro nodo disponible.
- Escalado Elástico: Ajuste automático del número de instancias de la aplicación en función del uso de CPU o memoria.
- Abstracción de Infraestructura: Desacopla la aplicación del hardware subyacente. Los desarrolladores no necesitan conocer los detalles físicos de los servidores, sino que interactúan con una API unificada.
Arquitectura del Clúster: Plano de Control y Nodos de Trabajo
Para lograr este nivel de abstracción, Kubernetes opera como un sistema distribuido compuesto por dos secciones funcionales claramente diferenciadas: el Control Plane (Plano de Control) y los Worker Nodes (Nodos de Trabajo).
1. El Plano de Control (Control Plane)
Es el cerebro del clúster. Su función es tomar decisiones globales (como la programación de cargas de trabajo) y detectar/responder a eventos del clúster.
Sus componentes principales son:
- API Server: Actúa como la puerta de entrada al clúster. Procesa todas las solicitudes REST para modificar el estado del sistema y valida la configuración. Es el único componente que interactúa directamente con la base de datos.
- etcd: Almacén de datos clave-valor consistente y de alta disponibilidad. Aquí se guarda toda la información de configuración y el estado actual del clúster.
- Kube-Scheduler: Responsable de asignar los nuevos contenedores a los nodos disponibles. Evalúa los requisitos de recursos (CPU/RAM) y las restricciones políticas para decidir la ubicación óptima.
- Kube-Controller-Manager: Ejecuta los procesos de control que regulan el estado del sistema, asegurando que el estado actual coincida con el estado deseado.
2. Los Nodos de Trabajo (Worker Nodes)
Son las máquinas (físicas o virtuales) donde se ejecutan las aplicaciones. Un clúster puede escalar desde un solo nodo hasta miles de ellos.
Sus componentes esenciales incluyen:
- Kubelet: Agente que se ejecuta en cada nodo. Se comunica con el Plano de Control y asegura que los contenedores asignados a ese nodo estén en ejecución y saludables.
- Kube-proxy: Mantiene las reglas de red en los nodos. Permite la comunicación de red hacia los Pods desde dentro o fuera del clúster.
- Container Runtime: El software encargado de ejecutar los contenedores (como containerd o Docker Engine).
La Unidad Atómica: El Pod
Es fundamental comprender que Kubernetes no gestiona contenedores individuales de forma directa. La unidad mínima de despliegue es el Pod.
Un Pod es una abstracción lógica que envuelve uno o más contenedores estrechamente acoplados. Estos contenedores comparten almacenamiento y recursos de red (incluyendo la dirección IP). Se puede conceptualizar el Pod como un «host lógico» efímero donde reside la aplicación.
Conclusión
Kubernetes representa una evolución necesaria para la infraestructura moderna. Al abstraer la complejidad del hardware y automatizar las operaciones críticas mediante un modelo declarativo, permite construir sistemas resilientes y escalables.
Esta arquitectura base es el fundamento sobre el cual se construyen los objetos de nivel superior, como los Deployments (para la gestión de réplicas) y los Services (para la exposición de red), conceptos que serán abordados en la siguiente entrada técnica.
