En la lección anterior cambiamos la imagen de tienda-web y observamos algo que dejamos deliberadamente sin explicar: apareció un segundo ReplicaSet, el viejo se quedó a cero réplicas sin borrarse, y durante unos segundos convivieron pods de dos versiones. Ese mecanismo es la razón de ser del Deployment y la respuesta directa al primero de los cuatro objetivos de Rutas Norte: cero cortes en los despliegues, frente al minuto o dos de parada que hoy obliga a desplegar los martes de madrugada. En esta lección tomamos el control de ese trasvase. Verás las dos estrategias nativas del Deployment y cuándo exige cada una, calcularás pod a pod lo que ocurre durante una actualización de api-reservas, ajustarás el ritmo con maxSurge y maxUnavailable, distinguirás qué cambios generan una revisión nueva y cuáles no, y manejarás el juego completo de kubectl rollout: status, history, undo, pause y resume. Y terminarás rompiendo un despliegue a propósito con una imagen inexistente, diagnosticándolo y deshaciéndolo.

1. Las dos estrategias nativas: RollingUpdate y Recreate
2. Por qué postgres-reservas no admite RollingUpdate
3. maxSurge y maxUnavailable, paso a paso con api-reservas
4. Ritmo y tolerancia: minReadySeconds, progressDeadlineSeconds, revisionHistoryLimit
5. Qué dispara una revisión nueva y qué no
6. El juego completo de kubectl rollout
7. La anotación kubernetes.io/change-cause
8. Despliegue sin corte: qué hace falta de verdad
9. Diagnóstico y rollback de un despliegue atascado

spec.strategy.type solo admite dos valores. No hay más estrategias nativas en Kubernetes: blue-green y canary, que verás en 11-04, se construyen combinando estos ladrillos con Servicios e Ingress.

Sustituye los pods de forma progresiva: levanta pods de la versión nueva y retira los de la vieja poco a poco, manteniendo siempre un número mínimo de pods sirviendo.

Mata todos los pods viejos, espera a que desaparezcan, y solo entonces crea los nuevos. Hay un intervalo, normalmente de segundos a un par de minutos, sin ningún pod sirviendo.

Cómo se declara explícitamente:

Es la pregunta clave de este apartado, y la respuesta enseña más que la estrategia en sí. Imagina que postgres-reservas fuera un Deployment de 1 réplica con RollingUpdate y maxSurge: 1. Durante la actualización, esto es lo que pasaría:

1. Kubernetes crea el pod nuevo antes de retirar el viejo, porque maxSurge: 1 lo permite.
2. Durante unos segundos hay dos procesos PostgreSQL simultáneos.
3. Ambos intentan montar y escribir en el mismo directorio de datos.

Consecuencias reales, en orden de gravedad:

• Bloqueo del arranque: PostgreSQL detecta el fichero postmaster.pid de la instancia viva y se niega a arrancar. El despliegue se atasca (el caso benigno).
• Corrupción de datos si el bloqueo falla o el almacenamiento no lo garantiza: dos procesos escribiendo en los mismos ficheros WAL.
• Escrituras perdidas: reservas confirmadas al cliente que no quedan registradas.

Y hay un segundo motivo, independiente del almacenamiento: la migración de esquema. Si la versión nueva de api-reservas requiere una columna que la vieja no conoce, tener las dos versiones hablando a la vez con la misma base de datos rompe una de las dos. Con RollingUpdate esa coexistencia dura minutos; con Recreate, no existe.

La conclusión honesta: para postgres-reservas, la respuesta correcta no es Recreate, es no usar un Deployment. Recreate es la estrategia adecuada para cargas de una sola réplica que no toleran duplicidad pero tampoco necesitan identidad estable, como nuestro redis-cache.

Aplícalo a redis-cache, que ya desplegaste en la lección anterior:

Recuerda llevar también ese cambio al manifiesto en Git.

Estos dos parámetros gobiernan por completo el ritmo de una actualización progresiva.

Ambos admiten un número entero o un porcentaje. Los porcentajes se redondean así: maxSurge hacia arriba y maxUnavailable hacia abajo, para pecar siempre por exceso de capacidad. Y hay una restricción: no pueden valer 0 los dos a la vez, porque entonces el despliegue no podría dar ni un paso.

api-reservas con 4 réplicas, maxSurge: 1 y maxUnavailable: 1. Actualizamos de la versión 2.4.0 a la 2.5.0. Los números que rigen todo el proceso:

• Máximo de pods simultáneos = replicas + maxSurge = 4 + 1 = 5
• Mínimo de pods disponibles = replicas - maxUnavailable = 4 − 1 = 3

Prepara el escenario:

Las dos lecturas importantes de esa tabla:

• En ningún momento hay menos de 3 pods sirviendo. Rutas Norte nunca pierde capacidad total, solo el 25 % durante unos segundos.
• En ningún momento hay más de 5 pods. El clúster necesita hueco para un pod extra, no para ocho.

En una terminal:

En otra, lanza la actualización:

Y el recuento de réplicas de cada ReplicaSet durante el proceso:

El Deployment está trasvasando réplicas de un ReplicaSet a otro. Eso es, literalmente, todo lo que hace un despliegue progresivo.

Para producción de Rutas Norte, la elección recomendada es maxSurge: 1 y maxUnavailable: 0: en un puente con el tráfico multiplicado por seis, perder un 25 % de capacidad durante un despliegue no es aceptable.

Tres campos que completan el control del despliegue.

minReadySeconds merece una explicación aparte porque su efecto es sutil pero muy valioso. Con el valor por defecto de 0, en cuanto un pod nuevo dice "estoy listo", el controlador retira otro viejo y sigue adelante. Si ese pod se cae dos segundos después, el daño ya está hecho: el despliegue avanza sobre una versión rota. Con minReadySeconds: 15, cada pod nuevo debe sobrevivir 15 segundos listo antes de contar. Si se cae antes, el despliegue se frena.

progressDeadlineSeconds es la diferencia entre un despliegue que falla en silencio y uno que avisa. Sin él, un despliegue atascado por una imagen inexistente se quedaría intentándolo eternamente sin que ningún sistema de alertas se enterase.

Manifiesto de api-reservas con los tres campos y la estrategia de producción:

Con esta configuración, una actualización de api-reservas en rutas-norte-pro tarda como mínimo 4 × 15 = 60 segundos, y si algo falla se declara fallida a los 5 minutos en lugar de a los 10. Lentitud a cambio de seguridad: en un componente que gestiona pagos de billetes, es un cambio excelente.

Esta es la regla más importante de la lección y la más olvidada:

Solo los cambios bajo spec.template disparan una revisión nueva. Todo lo demás, no.

La lógica es transparente: una revisión es un ReplicaSet, y un ReplicaSet se distingue de otro por el hash de su plantilla de pod. Si la plantilla no cambia, el hash no cambia, y no hay ReplicaSet nuevo que crear.

Compruébalo tú mismo:

Mismo historial: escalar no es desplegar.

Una consecuencia práctica que sorprende a mucha gente: cambiar un ConfigMap no reinicia los pods que lo consumen, porque el ConfigMap no está en el template, solo se referencia desde él. El truco habitual, que verás en el módulo 3, es forzar un cambio en el template con una anotación calculada, o usar directamente:

rollout restart no cambia nada funcional: escribe una anotación kubectl.kubernetes.io/restartedAt dentro del template, lo que altera el hash y provoca una sustitución progresiva de todos los pods. Es la forma correcta y sin corte de "reiniciar" un Deployment.

La sintaxis es <nombre-del-contenedor>=<imagen>. El nombre del contenedor es el de spec.template.spec.containers[].name, no el del pod. Con varios contenedores se pueden actualizar a la vez separándolos por espacios.

Aviso de disciplina: en un proyecto declarativo, la vía correcta es editar el manifiesto y aplicarlo. set image es para emergencias, y su cambio se pierde en el siguiente apply.

Y el detalle completo de una revisión concreta:

Esa información sale íntegramente del ReplicaSet a 0 réplicas que quedó guardado. Por eso revisionHistoryLimit: 0 te dejaría sin historial y sin rollback.

Vuelve a la revisión inmediatamente anterior. Para ir a una concreta:

Dos precisiones importantes:

1. Un rollback es un despliegue más: usa la misma estrategia, respeta maxSurge y maxUnavailable, y por tanto tampoco corta el servicio.
2. Deshacer no borra la revisión mala: crea una revisión nueva con el contenido de la antigua. Si estabas en la 3 y haces undo, apareces en la 4, cuyo contenido es el de la 2. Los números nunca retroceden.

Fíjate en que la revisión 2 ha desaparecido de la lista: su ReplicaSet ha sido reutilizado como revisión 4.

Con el Deployment pausado, los cambios que hagas no se aplican. Es la herramienta para agrupar varias modificaciones en un solo despliegue:

Sin pause, esos tres comandos habrían provocado tres despliegues encadenados, cada uno interrumpiendo al anterior. Con pause, uno solo y una sola revisión.

El otro uso de pause es de emergencia: si ves que un despliegue está sacando pods rotos, kubectl rollout pause lo congela en el acto, dejándote los pods viejos que quedan sirviendo mientras decides si arreglar o deshacer.

Tabla resumen del juego completo:

Habrás notado los <none> en la columna CHANGE-CAUSE. Un historial de revisiones sin motivos es casi inútil: a las tres semanas nadie recuerda qué era la revisión 7.

kubernetes.io/change-cause es una anotación del Deployment cuyo valor se copia al ReplicaSet de esa revisión y se muestra en el historial. Tres formas de rellenarla, de peor a mejor:

Con kubectl annotate (rápida, imperativa):

En el manifiesto (la correcta según las convenciones del proyecto):

Automatizada en CI/CD, que es lo ideal:

Un detalle que ya conoces por el apartado 5, pero que conviene repetir porque genera confusión: cambiar solo esta anotación no dispara una revisión nueva, porque vive en el metadata del Deployment y no en el template. Anótala junto con el cambio real, no después.

Buenas prácticas para el texto de Rutas Norte: versión de la imagen, resumen del cambio en lenguaje llano y referencia al ticket. Ejemplo real del proyecto:

Aquí llega el aviso más importante de la lección. Podrías pensar que con RollingUpdate bien configurado ya tienes despliegues sin corte de servicio. No es así, y esta es la causa número uno de errores 502 durante despliegues supuestamente perfectos.

El problema es que, con lo que sabemos hasta ahora, Kubernetes considera que un pod está "listo" en cuanto el proceso arranca. Pero un proceso de Node.js tarda unos segundos en cargar dependencias, conectar a PostgreSQL y quedar operativo. Durante esa ventana:

1. El pod ya cuenta como Ready.
2. El Deployment retira un pod viejo, confiado.
3. El Service empieza a enviarle tráfico real.
4. El pod nuevo todavía no puede responder: errores 502.

La pieza que falta se llama sonda de disponibilidad (readinessProbe): una comprobación que el kubelet ejecuta contra tu aplicación y que decide si el pod está realmente listo para recibir tráfico. Con ella, el paso 1 del esquema no ocurre hasta que la aplicación responde de verdad.

El checklist completo de un despliegue realmente sin corte en Rutas Norte:

Es decir: RollingUpdate es necesario pero no suficiente. Sin sondas, el despliegue progresivo avanza a ciegas. Hasta que lleguemos al módulo 7, minReadySeconds es un sustituto pobre pero útil.

Ejercicio final y el más realista de todos. Un viernes por la tarde, alguien despliega en rutas-norte-dev una versión que no existe en el registro.

Lectura: hay 5 pods listos y disponibles —el servicio sigue funcionando con la versión anterior— pero solo 1 tiene la versión nueva. El despliegue ha dado un paso y se ha parado. Esto es el sistema funcionando bien: maxUnavailable: 0 ha impedido que se retirase ningún pod viejo hasta que el nuevo estuviera listo, y como nunca lo estará, no se ha retirado ninguno.

El ReplicaSet nuevo tiene 1 pod que no llega a READY.

Causa raíz identificada, exactamente con el procedimiento de la lección de Pods.

Available: True (seguimos sirviendo) + Progressing: False con ProgressDeadlineExceeded (el despliegue está muerto) es la firma exacta de un despliegue atascado. En un clúster monitorizado, esa combinación debe generar una alerta.

Dos opciones, según el momento:

Aviso importante: si el Deployment está pausado, undo no surte efecto. Hay que hacer resume antes.

El ReplicaSet roto se queda a 0 réplicas, sin consumir nada, como testimonio del incidente. Y el historial cuenta la historia completa a quien la lea dentro de seis meses.

La moraleja de todo el apartado: durante los seis pasos anteriores, api-reservas no dejó de atender ni una sola reserva. Con el Docker Compose de partida, ese mismo error habría dejado la plataforma caída hasta que alguien lo notara. Eso es lo que compra un Deployment bien configurado.

Deja el clúster ordenado antes de continuar:

• Creer que RollingUpdate garantiza cero cortes por sí solo. Sin readinessProbe, el tráfico llega a pods que aún no pueden responder. Es la causa número uno de 502 durante despliegues.
• Poner maxSurge: 0 y maxUnavailable: 0. La API lo rechaza: el despliegue no podría avanzar.
• Usar RollingUpdate con una carga que no tolera dos versiones simultáneas. Bases de datos de una réplica, procesos con bloqueo exclusivo o migraciones de esquema incompatibles: ahí va Recreate, o directamente un StatefulSet.
• Poner revisionHistoryLimit: 0 para "ahorrar". Los ReplicaSets a 0 réplicas no consumen ni CPU ni memoria, solo unos kilobytes en etcd. A cambio, pierdes por completo la capacidad de deshacer.
• Esperar que cambiar spec.strategy o spec.replicas dispare un despliegue. No están en el template. Solo se aplican en la siguiente actualización real.
• Esperar que modificar un ConfigMap reinicie los pods. No lo hace. Usa kubectl rollout restart.
• Olvidar change-cause. Un historial de <none> no sirve de nada cuando hay que decidir a qué revisión volver a las tres de la madrugada.
• Anotar el change-cause después del despliegue. Como no dispara revisión, se queda asociado al Deployment pero puede no reflejar lo que hizo esa revisión. Anótalo en el mismo apply.
• Hacer undo sobre un Deployment pausado. No pasa nada hasta que hagas resume. Es un clásico de la depuración a ciegas.
• Confiar en kubectl apply como verificación. apply solo dice que la API aceptó el objeto. Encadena siempre kubectl rollout status --timeout=... en tus scripts.
• Consejo: en producción, maxSurge: 1 y maxUnavailable: 0. Cuesta un pod extra de capacidad y garantiza que nunca bajas de la capacidad nominal.
• Consejo: kubectl rollout status devuelve código de salida distinto de 0 si el despliegue falla. Es lo que convierte un pipeline de CI/CD en algo fiable: kubectl apply -f k8s/ && kubectl rollout status deploy/api-reservas --timeout=300s || kubectl rollout undo deploy/api-reservas.

tienda-web está en rutas-norte-pro con 6 réplicas, maxSurge: 2 y maxUnavailable: 1.

1. ¿Cuál es el número máximo de pods simultáneos y el mínimo de pods disponibles?
2. Construye una tabla con los primeros cinco pasos de la actualización, indicando en cada uno: pods viejos, pods nuevos, total y disponibles.
3. Si el equipo de plataforma exige que nunca se baje de 6 pods sirviendo, ¿qué valores pondrías y qué recursos extra necesita el clúster?
4. Con la configuración del punto 3 y minReadySeconds: 20, ¿cuál es la duración mínima teórica del despliegue si cada pod tarda 5 segundos en arrancar?

Sobre tienda-web en rutas-norte-dev:

1. Configura RollingUpdate con maxSurge: 1, maxUnavailable: 0, minReadySeconds: 10 y revisionHistoryLimit: 5, aplicándolo desde el manifiesto.
2. Actualiza a nginx:1.27.1-alpine con su change-cause correspondiente y espera a que termine.
3. Actualiza a nginx:1.26-alpine con otro change-cause.
4. Muestra el historial y el detalle de la revisión 2.
5. Simula que la 1.26 tiene un fallo grave: vuelve a la 1.27.1 y verifica que las tres réplicas la sirven.
6. Explica por qué el historial no muestra la numeración que esperarías.

1. Rompe worker-notificaciones a propósito desplegando la imagen busybox:9.9.9-inexistente, con change-cause incluido.
2. Con cuatro comandos, diagnostica el problema siguiendo el orden correcto: estado del Deployment, ReplicaSets, pod culpable y conditions.
3. Responde: ¿siguen enviándose los correos de confirmación durante el atasco? Justifícalo con la salida de los comandos.
4. Congela el despliegue, comprueba que undo no hace nada mientras está pausado, reanúdalo y deshaz.
5. Documenta el rollback con una anotación y muestra el historial final.

Solución 1

1. Máximo de pods = replicas + maxSurge = 6 + 2 = 8. Mínimo disponibles = replicas - maxUnavailable = 6 − 1 = 5.

2. Primeros cinco pasos:

3. Para no bajar nunca de 6 sirviendo: maxUnavailable: 0, y maxSurge a 1 o 2 según lo rápido que se quiera ir. Con maxSurge: 2, el clúster debe tener hueco para 8 pods de tienda-web a la vez: con requests de 50m de CPU y 64Mi por pod, eso son 100m de CPU y 128Mi de memoria libres de más durante el despliegue. Con maxUnavailable: 0 el clúster debe tener esa capacidad; si no la tiene, los pods nuevos se quedan en Pending y el despliegue no avanza nunca.

4. Con maxSurge: 2 y maxUnavailable: 0, los pods se sustituyen en tandas de 2. Cada tanda tarda 5 s (arranque) + 20 s (minReadySeconds) = 25 s. Seis pods en tandas de dos son 3 tandas: 75 segundos como mínimo teórico, sin contar descargas de imagen ni el tiempo de terminación de los viejos.

Solución 2

6. La numeración sorprende porque las revisiones nunca retroceden. Al deshacer a la revisión 2, Kubernetes no "vuelve" a ella: reutiliza su ReplicaSet y lo renumera como revisión 4, la más reciente. Por eso la 2 desaparece de la lista y aparece una 4 con su mismo change-cause. El número de revisión identifica el orden en que se aplicaron los cambios, no el contenido: un rollback es un cambio más.

Solución 3

3. Sí, los correos se siguen enviando. La prueba está en tres sitios: READY 2/2 y AVAILABLE 2 en el Deployment, los 2 pods de la revisión anterior en Running, y sobre todo Available: True con MinimumReplicasAvailable en las conditions. Solo UP-TO-DATE 1 delata que hay una versión nueva intentando entrar sin conseguirlo. Confirmación directa:

El ReplicaSet roto sigue con 1 réplica: el undo se ha registrado pero no se ha ejecutado, porque el Deployment está pausado.

Has cerrado el círculo que abrimos en la lección anterior con aquel segundo ReplicaSet que apareció sin explicación. Ahora sabes que las dos estrategias nativas del Deployment son RollingUpdate y Recreate, y por qué la elección no es de gusto sino de naturaleza de la carga: tienda-web, api-reservas y worker-notificaciones toleran dos versiones conviviendo y van con RollingUpdate; redis-cache no, y va con Recreate; y postgres-reservas no admite ninguna de las dos porque el Deployment no es su sitio: dos procesos PostgreSQL sobre el mismo directorio de datos significan bloqueo en el mejor caso y corrupción en el peor.

Sabes calcular un despliegue sobre el papel antes de ejecutarlo: replicas + maxSurge es el techo de pods y replicas - maxUnavailable el suelo de disponibles, y con esos dos números puedes reconstruir paso a paso lo que hará el controlador con las 4 réplicas de api-reservas. Conoces las combinaciones útiles y la recomendada para producción, maxSurge: 1 con maxUnavailable: 0, que protege la capacidad nominal en un puente de agosto. Ajustas el ritmo con minReadySeconds, detectas los atascos con progressDeadlineSeconds y conservas tu capacidad de deshacer con revisionHistoryLimit. Tienes clara la regla que gobierna todo: solo los cambios bajo spec.template crean una revisión, y por eso escalar no despliega, cambiar un ConfigMap no reinicia nada y existe kubectl rollout restart. Y manejas el juego completo —status, history, undo, pause, resume— con change-cause documentando cada paso, incluido el rollback de un despliegue atascado por una imagen inexistente, resuelto sin que un solo cliente dejara de comprar su billete.

Queda una advertencia pendiente y una carencia gorda. La advertencia: RollingUpdate es necesario pero no suficiente para desplegar sin corte real; sin una readinessProbe, Kubernetes marca como listo a un pod cuyo proceso acaba de arrancar y le manda tráfico antes de que pueda atenderlo. Esa pieza llega en Verificaciones de Salud y Sondas. Y la carencia: todo el tráfico del que llevamos dos lecciones hablando aún no existe. Nuestros pods tienen IPs que cambian en cada despliegue, y para hablar con api-reservas hemos tenido que buscar a mano la IP de un pod concreto. En la lección siguiente, Servicios, le daremos a cada componente de Rutas Norte una dirección estable que sobreviva a los despliegues, con balanceo de carga entre réplicas incluido.