El pipeline de 05-03 termina en kubectl rollout status y en un commit que Argo CD aplica. Entre "aplicar" y "desplegado" pasa algo que hasta ahora hemos dado por hecho: las réplicas de servicio-pedidos:1.0.0 tienen que dejar paso a las de 1.0.1 sin que un solo POST /v1/pedidos reciba un error de conexión. Cuando se desplegaba cada dos semanas de madrugada, un corte de 30 s se toleraba; cuando cada servicio despliega varias veces al día en horario comercial (que es el objetivo DORA de 05-03), cualquier corte multiplicado por seis servicios y por N despliegues es inaceptable. Esta lección explica las cuatro estrategias (recreate, rolling, blue-green, canary), su implementación en Kubernetes con los manifiestos de 05-02, la condición que todas comparten (dos versiones conviven, así que contratos y esquemas de base de datos deben ser compatibles hacia atrás), los feature flags como forma de separar despliegue de release, y la estrategia elegida por TechCorp para cada servicio. Cómo el mesh hace el canary por peso exacto queda para 05-05.

1. Desplegar sin cortes como requisito
2. Recreate frente a RollingUpdate
3. Compatibilidad hacia atrás durante el rolling: contratos y expand/contract
4. Blue-green
5. Canary
6. Feature flags: despliegue no es release
7. Tabla comparativa
8. La estrategia de TechCorp por servicio
9. Desplegar cambios en consumidores de eventos
10. Rollback, forward-fix y automatización progresiva

Un despliegue "sin cortes" (zero-downtime) exige tres cosas que ya tenemos y una nueva:

• Que las réplicas nuevas no reciban tráfico hasta estar listas: readinessProbe a /health/ready (05-02).
• Que las réplicas viejas terminen lo que tienen entre manos antes de morir: SIGTERM → /health/ready en 503 → servidor.close() (04-02, 05-01) dentro de terminationGracePeriodSeconds: 30 (05-02).
• Que haya más de una réplica, para que siempre quede alguna sirviendo.
• Y la nueva: que la versión vieja y la nueva puedan convivir durante segundos, minutos o días, hablando con los mismos clientes, la misma base de datos y las mismas colas (apartados 3 y 9).

Sin la cuarta condición, ninguna estrategia funciona: no hay forma de cambiar de versión "instantáneamente" en un sistema distribuido; siempre hay una ventana con las dos.

Recreate para todas las réplicas viejas y luego arranca las nuevas: hay un hueco de segundos sin servicio. Solo tiene sentido cuando dos versiones no pueden convivir (un cambio de esquema destructivo, un consumidor exclusivo de una cola) y se acepta el corte. RollingUpdate, el valor por defecto de un Deployment, sustituye réplicas poco a poco:

Con replicas: 3, maxSurge: 1, maxUnavailable: 0, la secuencia es:

Los cuatro parámetros se leen así:

La relación con terminationGracePeriodSeconds: cuando el Deployment borra un pod v1, el kubelet le envía SIGTERM y, en paralelo, el controlador de Endpoints lo saca del Service. Hay una carrera de milisegundos en la que aún puede llegar una petición; por eso /health/ready pasa a 503 primero y servidor.close() sigue atendiendo las conexiones abiertas. Un preStop: { exec: { command: ["sleep", "5"] } } en el contenedor da margen extra si se observan errores en esa ventana.

Y el rollback:

rollout undo es inmediato y seguro si la 1.0.0 puede convivir con lo que la 1.0.1 dejó en la base de datos: apartado 3. Con GitOps (05-03), el rollback canónico es revertir el commit de plataforma; rollout undo es la vía de emergencia.

Durante el rolling (y durante horas o días en canary), la 1.0.0 y la 1.0.1 de Pedidos atienden peticiones a la vez, publican eventos a la vez y escriben en la misma tabla. Dos consecuencias:

1. Contratos: la API y los eventos de la 1.0.1 deben ser compatibles hacia atrás con los consumidores actuales (03-06: añadir campos sí, quitar o cambiar tipo no; /v2/ para lo demás). Un cliente que hable con la 1.0.0 en una petición y con la 1.0.1 en la siguiente (el Service balancea por conexión) no debe notar diferencias incompatibles.
2. Esquema de base de datos: la migración de la 1.0.1 se aplica antes de que arranquen sus pods (el Job de 05-02) y mientras la 1.0.0 sigue escribiendo. Luego la migración tiene que ser compatible con la 1.0.0.

El patrón para conseguirlo es expand/contract: un cambio de esquema se hace en dos (o tres) despliegues, nunca en uno. Con el ejemplo de 03-06, añadir moneda a las líneas de pedido:

Lo que no se hace nunca en un solo paso: renombrar una columna (precio_unitario → precio), cambiar su tipo, borrarla, o añadir un NOT NULL sin DEFAULT. Cualquiera de esas rompe a la versión vieja en el instante en que el Job termina, antes de que la nueva esté lista, y hace imposible el rollout undo. Regla práctica de Luis: "una migración solo puede añadir; quitar es otro despliegue, y hay que poder deshacer el despliegue sin deshacer la migración".

Dos entornos completos e idénticos, blue (activo) y green (nuevo). Se despliega la versión nueva en green, se prueba con tráfico interno, y se cambia el enrutamiento de golpe. Si algo falla, se vuelve a blue en un segundo. En Kubernetes, dos Deployment y un Service cuyo selector decide cuál recibe tráfico:

Ventajas: cambio y rollback instantáneos y sin versiones mezcladas en el Service (aunque las peticiones en curso en blue terminan en blue). Inconvenientes: doble coste mientras conviven, y las mismas exigencias de compatibilidad de datos del apartado 3, porque green ya escribió en la base de datos antes de volver a blue. Cuando lo que se expone es un Ingress, el interruptor puede ser el backend.service.name del Ingress en lugar del selector.

Un canary envía un porcentaje pequeño de tráfico a la versión nueva, se observan sus métricas (aquí basta con dos: tasa de errores 5xx y latencia; el detalle de qué medir y cómo alertar es de 06-01 y 06-05), y si son iguales o mejores que las de la versión actual se aumenta el porcentaje hasta el 100 %; si no, se retira sin que la mayoría de usuarios lo haya notado. Tres formas de hacerlo, de más básica a más precisa:

(a) Por réplicas. El Service selecciona por app: servicio-pedidos sin mirar version (como en 05-02); un segundo Deployment con una réplica de la versión nueva entra en el mismo grupo:

Sencillo y sin ninguna pieza nueva; pero el porcentaje es aproximado (kube-proxy reparte por conexión, no por petición) y la granularidad es "una réplica": con 3 réplicas estables, el mínimo canary es el 25 %.

(b) Por peso en el Ingress NGINX. Para lo que entra por el Ingress (en TechCorp, el gateway; o un servicio si se expusiera directamente), un segundo Ingress con anotaciones canary:

Peso exacto por petición y canary por cabecera (X-Canary), que permite al equipo probar la versión nueva en producción antes de abrir el porcentaje: la misma idea que el router del gateway Express de 03-04, ahora declarativa. Limitación: solo en el borde; entre servicios internos el Ingress no interviene.

(c) Por peso entre servicios internos. Que el 10 % de las llamadas del gateway a servicio-pedidos vayan a v2, con peso exacto y sin importar cuántas réplicas hay, es lo que da un service mesh con VirtualService (05-05, donde cerramos este hilo).

En cualquiera de las tres, la parte difícil no es el YAML sino la decisión de avanzar: comparar errores y latencia de v2 con v1 durante N minutos, con suficiente tráfico para que sea significativo (a las 4 de la mañana un 10 % de casi nada no dice nada). Al principio TechCorp lo hará a mano mirando Grafana (06-01); la automatización es del apartado 10.

Las estrategias anteriores controlan qué código corre. Un feature flag (04-03: PAGO_NUEVO_PROVEEDOR, CATALOGO_REMOTO) controla qué código se ejecuta de entre el que corre. Con flags, el despliegue de la 1.1.0 puede hacerse con la funcionalidad apagada (dark launch): el código nuevo llega a producción con un rolling normal, sin riesgo, y la release (encenderla para el 1 %, el 10 %, todos) es un cambio de configuración, en segundos, sin desplegar y sin rollout undo. Comparado con el canary:

Regla: un flag tiene fecha de caducidad; cuando la funcionalidad es la única, se borra el if.

Todas comparten los cuatro requisitos del apartado 1 y la disciplina expand/contract.

Con un rolling de Pedidos, durante un rato hay pods v1 y v2 consumiendo la misma cola pedidos.saga (04-04). RabbitMQ reparte los mensajes entre todos los consumidores conectados, sin saber de versiones. Consecuencias y reglas:

• Los dos deben entender los mismos eventos: la tolerancia a campos nuevos y el versionado de eventos de 03-06 no son teoría, son lo que hace posible que un stock.reservado publicado por el Inventario nuevo lo procese un Pedidos viejo.
• Redistribución al morir un pod: cuando v1-a recibe SIGTERM a mitad de procesar un pago.confirmado, el mensaje no confirmado (ack pendiente) vuelve a la cola y lo recibe otro pod, quizá v2. La idempotencia de procesarUnaVez (04-04, tabla eventos_procesados) es lo que evita confirmar dos veces el pedido. El apagado ordenado del consumidor debe dejar de tomar mensajes (channel.cancel), terminar los que tiene, y solo entonces cerrar; el prefetch bajo (10) acota cuántos quedan a medias.
• Si v2 publica un evento nuevo (pedido.confirmado con un campo más), los consumidores de otros servicios en su versión actual deben tolerarlo: expand/contract también aplica a los eventos.
• Cambio de topología (nueva cola, nuevo binding): se declara de forma idempotente al arrancar (03-02) y antes de publicar en ella; nunca se borra un binding que la versión anterior aún usa.

Un consumidor de una cola no puede hacerse blue-green "puro" (green ya consume en cuanto conecta): o se despliega green sin arrancar el consumidor (un flag CONSUMIDOR_ACTIVO) o se acepta que consuma desde el principio, que es lo que hace TechCorp porque el consumo ya es idempotente.

• Rollback: kubectl rollout undo, cambio de selector, retirar el canary o revertir el commit de plataforma. Es la opción cuando el fallo es evidente y la versión anterior es compatible con el estado actual (por eso las migraciones solo añaden). Objetivo: minutos, y es lo que baja el MTTR de 05-03.
• Forward-fix: desplegar una versión nueva que corrige, en lugar de volver atrás. Necesario cuando la vuelta atrás es imposible (una fase contract ya aplicada, datos ya escritos en un formato nuevo) y aceptable cuando el pipeline tarda menos de 15 minutos: es más fácil justificar el forward-fix cuanto mejor es el CI/CD.
• Automatización progresiva: Argo Rollouts (recurso Rollout que sustituye al Deployment, con strategy: canary: steps: [setWeight: 10, pause: 10m, analysis: ...]) o Flagger (opera sobre el Deployment normal y crea el canary solo) consultan Prometheus, avanzan el peso si las métricas cumplen y revierten si no. Ambos necesitan un mecanismo de peso (Ingress NGINX, Istio, Linkerd) y las métricas de 06-01. Es el destino natural del canary manual de Pedidos y Pagos, cuando el equipo de Plataforma tenga el mesh o el Ingress con pesos y las métricas listas.

• maxUnavailable por defecto (25 %) con dos réplicas: durante el despliegue queda una; y con replicas: 1 el rolling es un recreate con otro nombre. maxUnavailable: 0 y al menos dos réplicas en cualquier servicio que reciba tráfico.
• Migración destructiva en el mismo despliegue que el código: el Job renombra la columna, los pods v1 empiezan a fallar antes de que v2 esté lista, y rollout undo no arregla nada. Expand/contract siempre.
• Canary sin métricas ni tráfico: "lo hemos tenido 10 minutos y no ha pasado nada" a las 3 de la mañana. Definir qué se mira, cuánto tiempo y cuánto tráfico mínimo antes de empezar.
• Blue-green con estado en el pod (sesiones, caché local): green arranca "frío". Los servicios de TechCorp son stateless precisamente por esto.
• Olvidar el readinessProbe o hacerla trivial (/health/live en ambas): Kubernetes borra pods viejos en cuanto los nuevos "arrancan", no cuando pueden atender.
• Flags eternos: cada if (flags.estaActivo(...)) es una rama que probar. Fecha de retirada en la tarjeta que lo crea.
• Consejo: ensaya el rollback en staging como parte del pipeline (rollout undo + E2E) al menos una vez por versión mayor; un rollback que nunca se ha probado no es un plan.

Ejercicio 1. servicio-pedidos tiene replicas: 2 y la configuración por defecto de RollingUpdate. Luis observa que durante cada despliegue la latencia p95 se dobla y hay algunos 502 en el gateway. Explica las dos causas más probables con lo visto y escribe el fragmento de spec que las corrige.

Ejercicio 2. El equipo de Pedidos quiere renombrar la columna precio_unitario de lineas_pedido a precio (03-06 lo dejó como ejemplo de cambio incompatible). Diseña la secuencia expand/contract completa: migraciones (numeradas a partir de 007-...), qué escribe y lee el código en cada versión (1.3.0, 1.4.0, 1.5.0) y en qué momento es seguro aplicar cada paso.

Ejercicio 3. Marta pregunta por qué el gateway va en blue-green y no en canary "como Pedidos, que es más moderno". Redacta la respuesta en cinco líneas, y añade qué se necesitaría para que el gateway pudiera ir en canary con seguridad.

Solución 1. (1) Con replicas: 2 y maxUnavailable: 25 % (redondeado a 1 pod), en algún momento hay un solo pod atendiendo todo el tráfico: la latencia se dobla. (2) Los 502 vienen de la ventana entre "el pod sale de Endpoints" y "el pod deja de aceptar": si el readinessProbe tarda 5 s en fallar tres veces (15 s) pero el proceso ya ha cerrado, o si el gateway mantiene conexiones keep-alive al pod que muere; el apagado ordenado de 04-02 (503 inmediato en /health/ready y servidor.close()) reduce la ventana, y un preStop con sleep 5 la cubre. Corrección:

terminationGracePeriodSeconds: 30 sigue siendo suficiente: 5 s de preStop + menos de 10 s de apagado.

Solución 2. v1.3.0 (expand): 007-lineas-precio-expand.sql: ALTER TABLE lineas_pedido ADD COLUMN precio NUMERIC(10,2); (nullable); el código escribe las dos columnas y sigue leyendo precio_unitario. Compatible con v1.2.x (ignora precio, que admite NULL). Migración de datos (Job aparte o dentro de 007 si la tabla es pequeña; por lotes si no): UPDATE lineas_pedido SET precio = precio_unitario WHERE precio IS NULL;. v1.4.0 (cambio de lectura): el código lee precio y sigue escribiendo ambas; se puede añadir ALTER COLUMN precio SET NOT NULL en 008-... una vez relleno. Compatible con v1.3.0 (que escribe ambas). v1.5.0 (contract): 009-lineas-precio-contract.sql: ALTER TABLE lineas_pedido DROP COLUMN precio_unitario;; el código ya no la escribe. Solo es seguro cuando ninguna réplica anterior a v1.4.0 puede volver (días después, tras confirmar que no habrá rollout undo a v1.3.0). Tres despliegues en lugar de uno, y cada uno se puede deshacer.

Solución 3. El gateway es el único punto de entrada: cualquier fallo afecta al 100 % de las peticiones de todos los servicios, y su cambio típico es de enrutamiento o de librería, difícil de "probar con el 10 %" porque un error de configuración suele ser todo o nada, no estadístico. Blue-green permite desplegar green completo, ejecutar la E2E y pruebas de rutas contra gateway-green antes de recibir tráfico, y volver a blue en un segundo con un cambio de Ingress, sin depender de métricas. Para pasar a canary con seguridad haría falta: peso exacto por petición (Ingress NGINX canary-weight, ya visto), métricas RED por ruta del gateway (06-01) con un umbral definido de errores y latencia, tráfico suficiente en la ventana de análisis, y preferiblemente la automatización de Argo Rollouts/Flagger para no depender de que alguien mire Grafana. Hasta entonces, blue-green es la opción más segura para esa pieza.

Desplegar sin cortes descansa en cuatro pilares (readinessProbe, apagado ordenado dentro de terminationGracePeriodSeconds, más de una réplica y convivencia de versiones) y se materializa en cuatro estrategias: recreate solo cuando la convivencia es imposible; rolling como valor por defecto (maxSurge: 1, maxUnavailable: 0, minReadySeconds, rollout undo); blue-green con dos Deployment (-blue/-green) y el selector.version del Service (o el Ingress) como interruptor; y canary por réplicas, por peso y cabecera X-Canary en el Ingress NGINX, o por peso exacto entre servicios internos con un mesh. La convivencia impone contratos compatibles (03-06) y migraciones expand/contract (la columna moneda de lineas_pedido en dos despliegues), también para los consumidores de eventos que comparten cola durante el rolling (idempotencia de 04-04). Los feature flags separan despliegue de release; la decisión de TechCorp es rolling para Catálogo, Inventario, Notificaciones y Clientes, canary para Pedidos y Pagos, blue-green para el gateway; y Argo Rollouts o Flagger automatizarán el canary cuando haya métricas y pesos exactos. Ese peso exacto entre servicios internos, junto con timeouts, reintentos y mTLS que hoy cada servicio resolvería en su código, es lo que promete un service mesh; la siguiente lección examina qué da Istio (y Linkerd), qué cuesta, y si TechCorp lo necesita ya.