¿Qué hace Kubernetes realmente por vos que Docker solo no hace?

#Docker responde "cómo corro un contenedor". Kubernetes responde "cómo corro una flota".

Docker (y el runtime OCI que tiene debajo) resuelve un problema real: empaquetar una aplicación con sus dependencias y correrla de forma consistente en cualquier lugar. Lo que no resuelve es qué pasa en el momento en que tenés más de un host y más de una instancia de un servicio — y en producción, siempre los tenés. Ese hueco es exactamente lo que llena Kubernetes?. No es "Docker pero mejor"; es una capa de orquestación que asume que los contenedores ya existen y agrega la maquinaria para correr cientos de ellos, en muchas máquinas, sin que un humano decida a mano dónde va cada uno.

#Lo que Docker solo te deja construir a vos

Si todo lo que tenés es docker run en un puñado de servidores, sos personalmente responsable de: decidir qué host tiene capacidad para un contenedor nuevo, reiniciar un contenedor que se cayó o todo un servicio si muere un host, darles a quienes llaman una dirección estable para un grupo de contenedores cuyas IPs individuales cambian cada vez que reinician, rutear tráfico externo al servicio correcto por hostname o path, desplegar una versión nueva sin downtime y poder revertirla si sale mal, e inyectar configuración y secretos sin hornearlos dentro de la imagen. Nada de eso es una función de Docker — es infraestructura que tendrías que scriptear a mano, mal, para siempre.

#Los objetos centrales, y el trabajo de cada uno

• Pod — la unidad desplegable más pequeña. Casi siempre un contenedor, a veces un par fuertemente acoplado (una app más un sidecar), compartiendo un namespace de red y una IP. Los Pods son descartables y se espera que mueran; casi nunca creás uno directamente.
• Deployment — una declaración del estado deseado: "quiero 3 réplicas de esta plantilla de Pod, corriendo esta imagen". Un Deployment administra un ReplicaSet, que es lo que realmente mantiene correcta la cantidad de réplicas, y la capa de Deployment encima agrega actualizaciones progresivas (rolling) e historial de rollback.
• Service — una IP virtual estable y un nombre DNS que balancea carga entre los Pods que en cada momento coincidan con un selector de etiquetas. Los Pods son ganado con IPs que cambian; un Service es la única dirección que nunca cambia, y eso es lo que le permite a un componente encontrar a otro sin hardcodear nada.
• Ingress — ruteo de capa 7 hacia el clúster: reglas por host y por path, terminación TLS, todo canalizando el tráfico HTTP(S) externo hacia el Service correcto. Un Service solo te da una dirección interna estable; un Ingress es lo que permite que api.example.com/orders y api.example.com/users lleguen a dos Services distintos a través de un único balanceador externo.

#La idea debajo de todo esto: el bucle de reconciliación

Cada uno de esos objetos se administra de la misma manera, y es el concepto individual más importante de Kubernetes: declarás lo que querés (spec), y un controlador empuja continuamente el estado real hacia eso (status). Es un bucle de control level-triggered (disparado por nivel), no un manejador de eventos — no reacciona una sola vez a "un Pod murió", sino que se pregunta continuamente "¿el estado real coincide con el deseado ahora mismo?" para siempre, y eso es lo que lo hace autorreparable incluso frente a fallas para las que nadie escribió código explícito.

Ningún componente único "despliega tu app". El controlador de Deployment solo decide cuántos Pods deben existir; el scheduler solo decide qué nodo corre cada uno; el kubelet de ese nodo solo hace que el runtime arranque el contenedor de verdad y sigue reportando si está vivo. Cada uno observa el API server, hace su trabajo acotado y escribe su resultado de vuelta — y como cada paso se re-ejecuta continuamente, que un nodo muera no requiere que un humano se dé cuenta: el scheduler ve Pods sin un nodo saludable y los reprograma, y el controlador de Deployment ve caer la cantidad de réplicas y pide más.

#Lo que ganás y que Docker solo nunca te dio

• Autorreparación — un contenedor caído o un nodo muerto dispara una reprogramación automática, sin necesidad de una alerta de guardia para el caso común.
• Descubrimiento de servicios y balanceo de carga integrados a la plataforma, inmunes a las IPs efímeras de los Pods.
• Actualizaciones progresivas y rollback declarativos — kubectl rollout undo revierte al ReplicaSet anterior en segundos.
• Autoescalado horizontal guiado por CPU/memoria o métricas personalizadas.
• Una API uniforme para secretos, configuración, almacenamiento y políticas de red, en vez de un script a medida por cada preocupación.

🧠 Check your understanding
0/3 · 0/3 answered
1. La IP de un Pod cambia cada vez que reinicia. ¿Qué objeto de Kubernetes existe específicamente para darles a otros componentes una dirección estable que sobreviva a ese cambio?
IngressDeploymentNamespaceService
2. ¿Qué agrega un Ingress por encima de lo que ya provee un Service?
Autoescalado horizontal automático de DeploymentsRuteo de capa 7 (reglas host/path) y terminación TLS para el tráfico externo hacia uno o más ServicesUn protocolo de red más rápido entre PodsReemplaza por completo la necesidad de Pods
3. Un nodo se cae y se lleva con él dos Pods de un Deployment. ¿Qué es lo que realmente lo nota y lo arregla, sin que intervenga un humano?
El bucle de reconciliación: el scheduler ve Pods sin asignar o no saludables y el controlador de Deployment ve réplicas reales por debajo de las deseadas, y ambos actúan continuamente hasta que vuelven a coincidirNada — Kubernetes requiere reprogramación manual después de la falla de un nodoDocker reinicia automáticamente el nodoEl controlador de Ingress reinicia el nodo afectado