"Deploy sin downtime" no es una flag. Es el conjunto de decisiones que evita que el tráfego llegue a un pod que aún no está listo — y evita que el cluster mate un pod que solo está lento.

Fallar en readiness es la causa número uno de error 502 en deploy.

Sello del curso: probado en Kubernetes 1.35 con aplicación Java y Nginx.

Los tres probes

Probe	Pregunta	Si falla
startup	¿ya inició?	reinicia (mientras tanto, liveness no corre)
readiness	¿puede recibir tráfego?	sale del Service (sin reiniciar)
liveness	¿está vivo?	reinicia el contenedor

startupProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  failureThreshold: 30
  periodSeconds: 5
readinessProbe:
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet: { path: /actuator/health/liveness, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3

Reglas prácticas:

• Readiness debe verificar dependencias que impiden servir (base de datos, caché crítico). No coloque dependencia no crítica: si Redis cae, el pod se cae sin necesidad.
• Liveness debe verificar solo el proceso. Liveness verificando base de datos = reinicio en cascada cuando la base de datos oscila.
• Startup existe para aplicaciones lentas; sin él, liveness mata la app antes de subir.
• initialDelaySeconds alto es síntoma de liveness mal configurada, no solución.

Rolling update

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

• maxUnavailable: 0 garantiza que la capacidad no cae durante el rollout.
• maxSurge: 1 crea un pod nuevo antes de derribar uno antiguo.
• minReadySeconds evita considerar listo demasiado pronto:

minReadySeconds: 10

• progressDeadlineSeconds evita rollout atascado para siempre:

progressDeadlineSeconds: 600

Monitorea:

kubectl -n portal rollout status deploy/portal-backend --timeout=5m
kubectl -n portal rollout history deploy/portal-backend
kubectl -n portal rollout undo deploy/portal-backend

terminationGracePeriodSeconds y el 502 clásico

Cuando un pod es eliminado:

1. Es marcado como Terminating y sale de los Endpoints.
2. El kubelet envía SIGTERM.
3. El proceso tiene terminationGracePeriodSeconds para finalizar.

Si la aplicación deja de aceptar conexiones en SIGTERM inmediatamente, las conexiones en vuelo caen. El patrón correcto:

• Recibir SIGTERM.
• Continuar sirviendo por algunos segundos (los Endpoints ya se propagaron).
• Cerrar el servidor y las conexiones de base de datos.
• Salir con 0.

lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]
terminationGracePeriodSeconds: 30

El sleep 5 no es elegancia: es el tiempo para que el Service deje de enviar tráfego.

PDB en el deploy

PDB protege durante el drain, no durante el rollout. Aún así, sin PDB un drain puede llevarse todas las réplicas de una vez.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: portal-backend
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: portal-backend

minAvailable: 50% también funciona y escala mejor.

HPA sin tumbar el servicio

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: portal-backend
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: portal-backend
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 50
          periodSeconds: 60

Lecciones:

• minReplicas: 2 para no quedarse sin capacidad en nodo único.
• scaleDown con ventana de estabilización evita flapping.
• Métrica de CPU solo funciona con requests definidos. Sin requests, el HPA no calcula.
• HPA no resuelve cuello de botella de base de datos. Escalar app que mantiene demasiadas conexiones tumba el Postgres — sucedió en nuestro entorno con 10 pods.

Deploy con cuota ajustada

Si el cluster no tiene holgura para maxSurge: 1, el pod nuevo queda Pending y el rollout se atasca. Dos salidas:

• maxSurge: 0 + maxUnavailable: 1 (acepta caída momentánea de capacidad).
• Garantizar holgura de recursos (capítulo 26).

Rollout atascado con Pending es falta de capacidad, no bug de Kubernetes.

Laboratorio

1. Suba un Deployment con 3 réplicas, readiness y maxUnavailable: 0.
2. Haga un bucle de solicitudes y un deploy con imagen nueva:

while true; do curl -s -o /dev/null -w "%{http_code}\n" http://portal.local/api/health; sleep 0.2; done

3. Observe el rollout: no debe aparecer ningún 5xx.
4. Elimine la readinessProbe y repita: los errores aparecen.
5. Pruebe kubectl drain con y sin PDB.
6. Genere carga y vea el HPA escalar:

kubectl -n portal get hpa -w

7. Fuerce un pod en CrashLoopBackOff y observe liveness/startup.

Errores comunes

Síntoma	Causa
502 durante deploy	readiness ausente o preStop faltando
Reinicio en cascada	liveness verificando dependencia externa
Rollout atascado Pending	falta de CPU/memoria para el surge
HPA no escala	sin requests o metrics-server caído
HPA escala y tumba la base de datos	demasiadas conexiones / pool mal dimensionado
Pod nunca Ready	readiness con path/timeout incorrecto
Drain bloqueado	PDB con minAvailable igual al total

Checklist

• [ ] Startup, readiness y liveness con propósitos distintos.
• [ ] Readiness solo con dependencias críticas.
• [ ] maxUnavailable: 0 y maxSurge compatible con la capacidad.
• [ ] minReadySeconds y progressDeadlineSeconds definidos.
• [ ] preStop + terminationGracePeriodSeconds.
• [ ] SIGTERM manejado en la aplicación.
• [ ] PDB por servicio crítico.
• [ ] HPA con requests y behavior de scaleDown.
• [ ] Prueba de deploy con bucle de solicitudes.

Glosario

• readiness: listo para tráfego.
• liveness: proceso saludable.
• startup: inicialización larga.
• maxSurge: pods extra durante el rollout.
• maxUnavailable: pods que pueden faltar.
• PDB: presupuesto de disrupciones.
• HPA: autoscaling horizontal.

Siguiente

Deploy sin downtime resuelto. Ahora cómo llega la imagen hasta aquí: pipeline, imagen inmutable, tag por digest y SBOM en el próximo capítulo.

Siguiente: Curso Kubernetes 24 — CI/CD: imágenes inmutables y SBOM