Estrategias de despliegue: rolling, blue-green y canary

Qué es

Rolling (progresivo): la documentación de Kubernetes sobre Deployments describe la estrategia por defecto así: se crean Pods nuevos y se eliminan los antiguos, y maxUnavailable y maxSurge (25 % cada uno por defecto) fijan el mínimo de Pods disponibles y el máximo de Pods adicionales; los Pods antiguos solo se terminan cuando hay suficientes nuevos en ejecución. progressDeadlineSeconds marca un rollout que no avanza, y kubectl rollout undo vuelve a la revisión anterior. Mientras dura el proceso, ambas versiones atienden peticiones.

Blue-green: existen dos entornos completos y el tráfico cambia en un solo paso. Argo Rollouts lo implementa con un servicio activo y otro de vista previa opcional: en cuanto el nuevo ReplicaSet está disponible, el controlador apunta el servicio activo hacia él y reduce la escala del antiguo tras scaleDownDelaySeconds. Mientras el antiguo sigue en ejecución, revertir consiste simplemente en volver a apuntar el servicio.

Canary: la nueva versión recibe un pequeño porcentaje del tráfico de producción. En Argo Rollouts es una lista de pasos formada por setWeight (porcentaje) y pause (tiempo de espera o aprobación manual), opcionalmente respaldada por un análisis automático de métricas. Sin un enrutador de tráfico, el controlador aproxima el porcentaje mediante el número de réplicas: con diez réplicas y un diez por ciento, eso es un Pod nuevo y nueve antiguos.

Por qué importa

Las tres estrategias intercambian capacidad por riesgo. Rolling apenas necesita reserva, pero obliga a la aplicación a tolerar versiones mezcladas durante varios minutos. Blue-green necesita temporalmente el doble de capacidad y a cambio ofrece un cambio y una reversión inmediatos. Canary limita cuántos usuarios ven un error, pero exige poder dividir el tráfico y contar con una señal de medición que distinga bien lo bueno de lo malo dentro de la ventana de observación.

Cómo aplicarlo

• Primero lo básico: comprobaciones de disponibilidad (readiness) que fallen mientras la inicialización no haya terminado; cierre limpio al recibir SIGTERM; cambios en la base de datos con el patrón expand-contract, para que la versión antigua y la nueva puedan ejecutarse a la vez.
• Rolling para servicios sin estado con versiones compatibles entre sí; maxUnavailable: 0 si la capacidad no puede bajar.
• Blue-green cuando no se admite una mezcla de versiones (conexiones de larga duración, cachés incompatibles) o cuando se quiere un ensayo general sobre infraestructura real.
• Canary cuando un error solo se manifiesta con tráfico real y existe una señal medible; fije el umbral de aborto antes de empezar.
• Feature flags como complemento: la estrategia de rollout decide qué binario se ejecuta; el flag decide qué comportamiento está activo.

Trampas

La afinidad de sesión, las cachés de los clientes y los TTL de DNS hacen que «cambiar todo de una vez» sea más lento de lo previsto. Un canary con un pequeño porcentaje del tráfico rara vez detecta errores poco frecuentes, por lo que la ventana debe ser lo bastante larga. Las migraciones de base de datos no se revierten junto con el binario. En un único host sin orquestador, las tres estrategias solo pueden reproducirse con herramientas auxiliares; sobre ello hay una pregunta abierta en la wiki.

Qué no separa blue-green

Cambiar el puntero del servicio solo separa los procesos. La base de datos, las cachés, las colas y los clientes son comunes a ambos entornos: durante scaleDownDelaySeconds (30 segundos por defecto en Argo Rollouts), blue aún procesa peticiones en curso mientras green ya escribe, y los navegadores y las apps móviles conservan la interfaz antigua mucho tiempo después del cambio. Blue-green, por tanto, no excluye la mezcla de versiones, sino que la traslada de los procesos del servidor a la capa de datos y a los clientes. Expand-contract para los cambios de esquema y respuestas de API retrocompatibles siguen siendo obligatorios en las tres estrategias; blue-green compensa cuando el propio estado del proceso no tolera una mezcla: conexiones de larga duración, cachés en memoria con un formato modificado, un cambio de protocolo entre componentes que solo se entregan juntos. La reversión inmediata solo es válida mientras el ReplicaSet antiguo siga en ejecución; después, volver atrás es un rollout corriente.