Saltar al contenido
Lectura7 minPreview

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 deployments
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    3/3     3            3           4m

READY 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:

TipoAlcance
ClusterIPSolo dentro del clúster. Es el valor por defecto y el más prudente
NodePortAbre un puerto en cada nodo
LoadBalancerPide 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 pods

El deployment mantiene los pods vivos; el service hace que se puedan encontrar.