Kubernetes: el orquestador que gestiona miles de contenedores
En un artículo anterior explicamos qué es un contenedor: ese paquete que envuelve una aplicación con todo lo que necesita para ejecutarse de forma aislada y reproducible. Pero cuando una empresa lanza una web con cientos de servicios, cada uno replicado varias veces para soportar la carga, los contenedores se multiplican por miles. ¿Quién los levanta, los vigila, los reinicia cuando caen y reparte el tráfico entre ellos? Aquí entra Kubernetes (abreviado K8s, porque tiene 8 letras entre la K y la s), el orquestador de contenedores que se ha convertido en el estándar de facto de la industria.
El problema que resuelve
Gestionar unos pocos contenedores a mano es viable: los arrancas con docker run y los conectas entre sí. Pero a escala, aparecen preguntas que un humano no puede responder en tiempo real: ¿cuántas copias de cada servicio necesito ahora mismo?, ¿en qué servidor coloco cada contenedor para aprovechar la memoria?, ¿qué pasa si un servidor entero se apaga?, ¿cómo hago una actualización sin cortar el servicio ni un segundo?
Kubernetes automatiza todas esas decisiones. Es, en esencia, un sistema de control con lazo cerrado (closed loop): observa continuamente el estado real del sistema, lo compara con el estado deseado que le has declarado y ejecuta acciones para que coincidan. Si definiste que debe haber 5 réplicas de un servicio y una muere, Kubernetes crea otra para volver a 5, sin que nadie intervenga.
Los componentes clave: el plano de control y los nodos
Un clúster de Kubernetes se divide en dos planos lógicos. El plano de control (control plane) es el cerebro: decide qué, dónde y cuándo. El plano de datos lo forman los nodos (nodos), que son las máquinas (físicas o virtuales) donde realmente corren los contenedores.
Dentro del plano de control destacan varios componentes que dialogan mediante una API REST central llamada kube-apiserver, la puerta de entrada única a todo el clúster. El etcd es una base de datos clave-valor distribuida que guarda el estado deseado y actual de todo el sistema, basada en el algoritmo de consenso Raft para garantizar que todas las copias coinciden incluso si algún nodo falla. El scheduler decide en qué nodo colocar cada contenedor nuevo en función de los recursos libres (CPU, memoria) y de restricciones como «no juntes dos réplicas del mismo servicio en la misma máquina».
En cada nodo, el kubelet es el agente que habla con el apiserver y se encarga de que los contenedores que le han asignado estén realmente corriendo, invocando al runtime de contenedores (como containerd). El kube-proxy implementa las reglas de red del nodo para enrutar el tráfico hacia los contenedores correctos.
Pods: la unidad mínima
Kubernetes no ejecuta contenedores sueltos, sino pods: el grupo mínimo de contenedores que se despliegan juntos en el mismo nodo y comparten una misma red y almacenamiento. Aunque un pod puede contener varios contenedores (por ejemplo, uno con la app y otro con un sidecar que recoge sus logs), lo habitual es un pod por contenedor. El pod tiene una IP propia y efímera: cuando muere, Kubernetes crea otro con una IP nueva. Por eso, nunca deberías conectarte a un pod por su IP, sino a través de los servicios que abstraen ese caos.
Servicios, Deployments y escalado
Un Service es una capa de abstracción que da a un conjunto de pods una dirección estable y un mecanismo de balanceo de carga: reparte las peticiones entrantes entre todas las réplicas de un pod mediante reglas internas de red (normalmente iptables o eBPF). Gracias a los labels (etiquetas clave-valor) y los selectors, un Service sabe exactamente a qué pods debe dirigir el tráfico, sin necesidad de conocer sus IPs concretas.
El Deployment es el objeto que describe el estado deseado de una aplicación: qué imagen de contenedor usar, cuántas réplicas quiero y cómo actualizarlas. Cuando lanzas una nueva versión, Kubernetes realiza una actualización gradual (rolling update): va sustituyendo réplicas de una en una, manteniendo siempre un mínimo disponible, de modo que los usuarios no notan la transición. Si algo sale mal, un rollback revierte al estado anterior. Y cuando la carga sube, el autoscaler horizontal (HPA) mide métricas como el uso de CPU y aumenta o reduce el número de réplicas de forma automática.
Alta disponibilidad: sobrevivir a las caídas
La clave de Kubernetes es su tolerancia a fallos. Cada componente del plano de control suele replicarse en varios nodos para que, si uno cae, los demás sigan gobernando el clúster sin pérdida de servicio. El mecanismo de health checks (probes) permite al kubelet saber si un contenedor sigue sano: hay liveness (¿sigue vivo el proceso?), readiness (¿está listo para recibir tráfico?) y startup. Si una sonda falla, el contenedor se reinicia o se retira del balanceo hasta que se recupere.
¿Es Kubernetes para todos?
Kubernetes no es una herramienta pequeña: su curva de aprendizaje es pronunciada y su complejidad operativa, alta. Para un blog personal o una web sencilla es una exageración; basta con un contenedor. Pero para servicios que deben escalar, actualizarse sin cortes y sobrevivir a fallos, es la infraestructura sobre la que hoy se apoya buena parte de internet. Entender sus piezas —el apiserver como única puerta, el etcd como memoria de estado, los pods como unidad mínima y los Services como dirección estable— es entender cómo funciona la nube moderna por dentro.
