Saltar a contenido

Rolling Updates y Rollbacks

1. Rolling Update (El Superpoder de Actualizar sin Caídas)

Por defecto, cuando cambias la imagen de un contenedor en un Deployment (ej. pasas de nginx:1.14 a nginx:1.15), Kubernetes no destruye todos los Pods antiguos de golpe. Utiliza la estrategia RollingUpdate, que reemplaza los Pods gradualmente.

Para que Kubernetes sepa qué tan rápido o lento debe hacer este reemplazo, utiliza dos parámetros matemáticos clave:

  • maxSurge (Exceso Máximo): ¿Cuántos Pods adicionales por encima de la capacidad deseada se pueden crear durante la actualización?

  • Ejemplo: Si tienes 10 réplicas y maxSurge es 2, Kubernetes puede llegar a levantar hasta 12 Pods temporalmente para ir inyectando la nueva versión antes de apagar los viejos.

  • maxUnavailable (Inactividad Máxima): ¿Cuántos Pods pueden estar "fuera de servicio" o eliminados respecto a la capacidad deseada durante la actualización?

  • Ejemplo: Si tienes 10 réplicas y maxUnavailable es 2, Kubernetes garantiza que al menos 8 Pods siempre estarán respondiendo tráfico mientras ocurre el reemplazo.

(Nota: Ambos valores pueden definirse como un número entero o como un porcentaje %).

2. Rollbacks (El Botón de Pánico)

¿Qué pasa si despliegas la versión v2 de tu aplicación y resulta que el código tiene un error crítico que hace que los Pods entren en CrashLoopBackOff?

Kubernetes guarda un historial de las actualizaciones exitosas anteriores en objetos ocultos llamados ReplicaSets. Gracias a este historial, puedes ordenar una reversión (Rollback) casi instantánea hacia una versión anterior que sabías que funcionaba perfectamente.

🚀 Comandos

# Observa en tiempo real cómo los pods viejos mueren y los nuevos nacen
kubectl rollout status deployment/mi-app

# Reiniciar deployment causando menor downtime
kubectl rollout restart deployment/mi-app

# Ver el historial de revisiones del Deployment
kubectl rollout history deployment/mi-app

# Ver los detalles exactos de qué imagen tenía una revisión pasada (ej. la revisión 2)
kubectl rollout history deployment/mi-app --revision=2

# 🚨 El Botón de Pánico: Deshacer el último cambio (volver a la versión anterior)
kubectl rollout undo deployment/mi-app

# Revertir a una revisión específica en el tiempo
kubectl rollout undo deployment/mi-app --to-revision=1

Estrategias de Despliegue (Deployment Strategies)

1. Estrategias Nativas (En el objeto Deployment)

Estas se configuran directamente en el manifiesto YAML bajo spec.strategy.type.

  • RollingUpdate (Actualización Continua) - El Estándar
  • Cómo funciona: Reemplaza gradualmente los Pods antiguos por los nuevos. Nunca apaga la versión antigua por completo hasta estar seguro de que la nueva está funcionando.
  • Downtime (Caída): Ninguno.
  • Control: Utiliza los parámetros matemáticos maxSurge (cuántos pods extra puedo levantar temporalmente) y maxUnavailable (cuántos pods me permito tener inactivos) que ya vimos anteriormente.

  • Uso: Es el valor por defecto. Ideal para aplicaciones sin estado (stateless) o bases de datos retrocompatibles.

  • Recreate (Recreación) - El Botón de Apagado

  • Cómo funciona: El comportamiento "vieja escuela". Mata de golpe absolutamente todos los Pods de la versión actual (v1). Una vez que todos están muertos, recién empieza a levantar los Pods de la nueva versión (v2).
  • Downtime (Caída): SÍ. El tiempo que tarden en apagar y encender.
  • Uso: Crítico cuando tu aplicación NO permite que la versión 1 y la versión 2 corran al mismo tiempo (ej. migraciones de esquemas de bases de datos muy destructivas, o uso de volúmenes ReadWriteOnce que no pueden compartirse entre pods viejos y nuevos).

2. Estrategias Avanzadas (A nivel de Enrutamiento / Service)

Kubernetes no tiene un strategy: BlueGreen nativo en el Deployment. Estas se logran manipulando el tráfico a nivel del objeto Service, Ingress o Gateway API.

  • Blue / Green (Azul / Verde) - El Cambio de Vía
  • Cómo funciona: Tienes en paralelo dos Deployments completos ejecutándose al 100%. "Blue" es la versión actual que recibe tráfico. "Green" es la nueva versión que instalas, pero a la que nadie puede entrar excepto tu equipo de QA. Cuando validas que "Green" está perfecto, cambias el Selector del Service para que el tráfico pase instantáneamente de Blue a Green.
  • Downtime: Ninguno (el cambio es instantáneo).
  • El Superpoder: Rollback instantáneo. Si "Green" falla en producción real, cambias el Service de vuelta a "Blue" en 1 segundo porque los Pods viejos nunca se apagaron.

  • La Desventaja: Cuesta caro. Necesitas el doble de recursos (CPU/RAM) en tu clúster mientras dura la transición.

  • Canary (Despliegue Canario) - El Piloto de Pruebas

  • Cómo funciona: Despliegas la versión 2 (v2) solo para un subconjunto minúsculo de tus usuarios reales (por ejemplo, el 10%). Si el 10% no reporta errores (no suben los logs de error 500), escalas la v2 al 100% y eliminas la v1.
  • Cómo se implementa:
    1. Estilo Básico: Tienes 9 pods de v1 y creas 1 pod de v2 detrás del mismo Service. El tráfico se divide 90/10 de forma natural.
    2. Estilo Pro: Usando pesos (weights) en Gateway API (como vimos en tus apuntes de kgateway) o Service Meshes como Istio.
  • Uso: Excelente para probar nuevas funcionalidades con riesgo oculto sin afectar a toda tu base de usuarios.

📊 Tabla de Batalla (Decisión Rápida)

Estrategia ¿Tiene Downtime? Costo de Recursos Velocidad de Rollback ¿Viene Nativo en Deployment?
RollingUpdate No Bajo (solo maxSurge) Medio (Tiene que recrear pods) SÍ
Recreate SÍ (Total) Nulo (Usa la misma capacidad) Lento (Tiene que matar y crear) SÍ
Blue/Green No El Doble (200%) Instantáneo NO (Se hace con el Service)
Canary No Bajo (Depende del tamaño del canario) Rápido NO (Se hace con Service/Gateway)