Rolling Update

Resumen

En un rolling update, el orquestador —Kubernetes, por ejemplo— va reemplazando pods viejos por pods nuevos de a uno o en lotes. Mientras tanto, las instancias que todavía no fueron reemplazadas siguen atendiendo tráfico. El servicio nunca se interrumpe completamente.

Es la estrategia por defecto en Kubernetes: cambiás la imagen en el Deployment y K8s crea pods nuevos, espera a que estén saludables, y termina pods viejos gradualmente. Es simple, no requiere duplicar infraestructura como Blue-Green, pero el rollback es más lento —hay que hacer otro rolling update a la versión anterior—.

Alcance y supuestos

Cubre rolling updates, su diferencia con Blue-Green y canary, y configuración en Kubernetes. Asume familiaridad con deploys.

Modelo mental

Cambiar las ruedas de un auto en movimiento —metafóricamente—. No detenés el auto. Cambiás una rueda, después la otra, después la otra. En todo momento, al menos tres ruedas están funcionando. Cuando terminaste, las cuatro ruedas son nuevas sin haber frenado nunca.

Uso práctico

• ✅ Deploys rutinarios, aplicaciones stateless.
• ❌ Cambios de esquema de base de datos incompatibles con versiones anteriores.

Ejemplo trabajado: rolling update en Kubernetes

Deployment con replicas: 5, maxSurge: 1, maxUnavailable: 0. Cambia la imagen. K8s crea 1 pod nuevo, espera ready, mata 1 pod viejo. Repite 5 veces. Cero downtime.

Evidencia

• Kubernetes Deployments implementan rolling updates por defecto con maxSurge y maxUnavailable.