Pod, deployment y service
Kubernetes tiene decenas de tipos de objetos, y la documentación oficial puede abrumar el primer día. Para desplegar una aplicación sencilla bastan tres: pod, deployment y service. Si entiende cómo se relacionan, el resto se aprende sobre la marcha.
Pod: la unidad mínima
Kubernetes no ejecuta contenedores sueltos; ejecuta pods. Un pod envuelve uno o más contenedores que comparten red y almacenamiento, aunque en la práctica la mayoría lleva uno solo.
Los pods son desechables. Cuando uno muere, no se repara: se crea otro, con otro nombre y otra IP. Quien viene de administrar servidores tarda en aceptarlo, porque la costumbre es entrar a ver qué le pasó a la máquina. Aquí se mira el registro y se deja que nazca el reemplazo. Por esa razón casi nunca se crean pods directamente.
Deployment: el que cuida las copias
Un deployment declara cuántas réplicas de un pod quiere y con qué imagen. Por debajo usa un ReplicaSet, que vigila que el número de pods coincida con lo pedido.
También maneja las actualizaciones. Si cambia la imagen de nginx:1.26 a nginx:1.27, Kubernetes reemplaza los pods de forma escalonada, sin tumbar la aplicación, y permite volver atrás si algo falla.
Así se ve al listarlo con kubectl get, que verá a fondo en la próxima lección:
kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGE
web 3/3 3 3 4mREADY compara pods listos con pods pedidos. Un 2/3 que no cambia en varios minutos es lo primero que conviene investigar.
Service: una dirección que no cambia
Si los pods cambian de IP cada vez que se recrean, otra aplicación no puede apuntarles. Para eso está el service: da un nombre DNS y una IP fija dentro del clúster y reparte el tráfico entre todos los pods que tengan cierta etiqueta.
Las etiquetas son pares clave-valor, como app: web, pegados a los objetos. El service no apunta a pods concretos, sino a "todos los que digan app: web". Cuando el deployment crea o borra pods, el service se ajusta solo. El fallo clásico del principiante es un error de tipeo en la etiqueta: el service existe, los pods corren, y no hay tráfico porque no coinciden.
Tipos de service:
| Tipo | Alcance |
|---|---|
| ClusterIP | Solo dentro del clúster. Es el valor por defecto y el más prudente |
| NodePort | Abre un puerto en cada nodo |
| LoadBalancer | Pide un balanceador al proveedor de nube y expone el servicio hacia afuera |
Cómo encajan
Service web (ClusterIP) --> pods con app=web
^
Deployment web (replicas: 3) ----+ crea y vigila esos podsEl deployment mantiene los pods vivos; el service hace que se puedan encontrar.