5.3Kubernetes en 20 minutos : Pod, Deployment, Service
Lo esencial en 30 segundos
- Tres objetos, un principio : el Pod envuelve los contenedores, el Deployment mantiene N Pods idénticos y los actualiza, el Service da una dirección estable delante de Pods intercambiables.
- Se declara, kubectl aplica : manifiestos en YAML, comando único de aplicación — el clúster mantiene el estado deseado (Pod faltante = Pod recreado).
- Laboratorio local primero : un solo clúster local basta para aprender — tags de imagen inmutables, nunca bricolaje autohospedado en producción sin equipo.
Mini-caso hilado — Idir toca Kubernetes en local
Idir, devops junior en Alger, quiere entender Kubernetes sin nube ni factura : crea un clúster local en un comando en su máquina, aplica en él un Deployment (3 réplicas) y un Service, alcanza su app en local, luego mata un Pod para ver al Deployment recrearlo. Continuación del caso 5.2 — Idir pasa del stack Swarm al primer despliegue Kubernetes.
Continuación del caso 5.2 — Idir aprende en clúster local antes de toda idea de producción.
1. Tres objetos, un principio
El Pod es la envoltura de uno o varios contenedores co-localizados ; el Deployment mantiene N Pods idénticos y gestiona sus actualizaciones ; el Service da una dirección estable delante de Pods intercambiables que nacen y mueren. Idir retiene la frase : se alcanza lo estable (Service), no lo movedizo (Pods).
Se declara el estado deseado en YAML (réplicas, imagen, selectores, puertos), se aplica con el cliente kubectl, y el clúster mantiene ese estado : es el principio declarativo.
2. El laboratorio local
Sin nube para empezar : un clúster local creado en un comando basta, con kubectl configurado encima. Idir aplica en él sus manifiestos, verifica sus 3 Pods, alcanza el Service en local (redirección de puerto para el dev) — tablero opcional.
En producción real, se apunta a un clúster gestionado : operar uno mismo un clúster exige un equipo. La regla : aprender en local, producir en gestionado.
3. Aplicar, ver, exponer
Aplicar el archivo, listar Pods, Deployments y Services, alcanzar en local. La actualización = cambiar el tag de imagen + reaplicar : rolling update automático con vuelta atrás posible. Idir mata un Pod y observa su resurrección : el orquestador mantiene el estado declarado.
Disciplina de imágenes : tags inmutables en los YAML, nunca tag movedizo en despliegue — si no ya no se sabe qué corre realmente.
🔎 Ejemplo concreto — La app de Idir en 3 réplicas en clúster local
Declarar, aplicar, alcanzar.
kubectl apply -f deploy.yaml
kubectl get pods
kubectl get deploy
kubectl get svc
kubectl port-forward svc/web 8080:80Lectura : 3 Pods tras una dirección estable, alcance en local.
Lección : matar un Pod lo hace renacer — el estado deseado se mantiene.
Vocabulario de la sección
- Pod
- La unidad más pequeña : la envoltura efímera de uno o varios contenedores.
Ejemplo sencillo: Idir ve sus Pods nacer, morir y renacer en su clúster local.
Lo que no es: una dirección estable que alcanzar durablemente.
Reflejo: ¿estoy alcanzando un Pod o un Service?
- Deployment
- El controlador que mantiene N Pods idénticos y gestiona sus actualizaciones.
Ejemplo sencillo: Idir declara 3 réplicas : un Pod matado es recreado.
Lo que no es: un contenedor lanzado a mano sin controlador.
Reflejo: ¿cuántas réplicas he declarado?
- Service
- La dirección estable delante de Pods intercambiables.
Ejemplo sencillo: Idir alcanza el Service, no los Pods movedizos.
Lo que no es: la dirección directa de un Pod efímero.
Reflejo: ¿qué queda estable cuando los Pods se mueven?
- kubectl
- El cliente en línea de comando que pilota el clúster.
Ejemplo sencillo: Idir aplica, lista e inspecciona con kubectl.
Lo que no es: una acción manual en cada contenedor.
Reflejo: ¿mi kubectl apunta al clúster correcto?
- Tag inmutable
- Una etiqueta de imagen fija que designa exactamente una versión.
Ejemplo sencillo: Idir actualiza cambiando de tag y reaplicando.
Lo que no es: un tag movedizo que cambia de contenido sin avisar.
Reflejo: ¿sé exactamente qué versión corre?
En la práctica — Kubernetes en local
- Cree un clúster local (un comando).
- Aplique el Deployment + Service del modelo siguiente.
- Verifique los 3 Pods, alcance vía redirección de puerto.
- Mate un Pod y observe su resurrección.
Guion listo para decir — proponer el laboratorio Kubernetes
«Para entender Kubernetes sin riesgo, propongo un laboratorio local en Alger : un clúster en mi máquina, un Deployment a 3 réplicas con tag inmutable, un Service alcanzado en local. Veremos la autorreparación matando un Pod — ninguna producción tocada, ninguna factura cloud.»
Para decir al referente para validar el aprendizaje en local antes de todo proyecto clúster.
Modelo copiar-pegar — Deployment + Service genéricos
K8S GENÉRICO — archivo deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: mon-registre/mon-app:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 80
COMANDOS : kubectl apply -f deploy.yaml · kubectl get pods · kubectl port-forward svc/web 8080:80Solo / presupuesto reducido
Idir solo : un clúster local gratuito basta — 3 réplicas, alcance local.
TPE / equipo reducido
Demo compartida : uno mata un Pod, el otro constata la resurrección.
PYME en Alger
Idir fija en Alger un taller : cada uno aplica el manifest en su puesto.
Equipo que empieza
Binomio : uno escribe el YAML, el otro verifica selectores y tags antes del apply.
✓ Buenas prácticas
- Aprenda en clúster local, produzca en gestionado.
- Tags de imagen inmutables en los YAML.
- Redirección de puerto para el dev, exposición real en producción.
✗ Errores frecuentes
- Tag movedizo en un Deployment (ya no se sabe qué corre).
- Clúster bricolado en prod sin equipo para operarlo.
- Confundir Pod efímero y Service estable.
Puntos clave
- Pod = envoltura efímera, Deployment = réplicas, Service = dirección estable.
- Se declara en YAML, kubectl aplica, el clúster mantiene.
- La actualización = nuevo tag + reaplicación, vuelta atrás posible.
- Aprender en local, tags inmutables, producción en gestionado.
Reto 48h — aplique mañana
Aplique el Deployment + Service genérico (modelo anterior) en un clúster local : 3 Pods visibles, alcance local OK, resurrección tras eliminar un Pod.
- Puedo describir Pod, Deployment y Service en una frase cada uno.
- Mi despliegue local muestra 3 Pods tras un Service.
- Sé actualizar por nuevo tag + reaplicación.
Preguntas frecuentes
¿Hay que migrar todo a Kubernetes tras esta guía?
No : este nivel da las claves para entender y decidir. Muchas apps siguen muy bien en Compose o Swarm — Kubernetes solo renta si el parque, los equipos y las exigencias (autoescalado, multi-equipos) lo justifican.
¿Por qué certificación empezar tras esta guía?
De forma genérica : primero una certificación centrada en Docker que corona esta guía (imágenes, redes, volúmenes, Compose, Swarm, seguridad), luego una certificación Kubernetes si Kubernetes es su objetivo. Ambas se preparan con labs prácticos, no de memoria.
Un Pod muere. ¿Qué hace el Deployment?