Despliegues rolling, blue-green y canary comparados

Qué es

Actualización rolling: la documentación de Kubernetes Deployment (citada) describe la estrategia por defecto como la creación de Pods nuevos y la eliminación de los antiguos dentro de dos límites, maxUnavailable y maxSurge (ambos del 25 por ciento por defecto); no elimina los Pods antiguos hasta que ha aparecido un número suficiente de Pods nuevos, y progressDeadlineSeconds marca un rollout que se estanca. Ambas versiones sirven tráfico durante el rollout.

Blue-green: existen dos pilas completas; el tráfico se conmuta de la activa a la nueva en un único paso. La documentación de Argo Rollouts (citada) implementa esto dirigiendo un Service activo y un Service de vista previa opcional hacia distintos ReplicaSets y, una vez que el nuevo ReplicaSet está disponible, modificando el service activo para que apunte a él, y reduciendo después la escala del conjunto antiguo tras un retraso.

Canary: la nueva versión recibe un pequeño porcentaje del tráfico de producción, que se incrementa por pasos. La estrategia canary de Argo (citada) expresa esto como una lista de pasos setWeight y pause, condicionados opcionalmente por un análisis automatizado de métricas.

Por qué importa

Las estrategias intercambian capacidad por riesgo. Rolling necesita poca capacidad adicional, pero obliga a la aplicación a tolerar versiones mixtas durante varios minutos; blue-green necesita brevemente el doble de capacidad, pero ofrece una conmutación instantánea y una reversión instantánea mientras la pila antigua sigue en marcha; canary limita el número de usuarios expuestos a un defecto, pero necesita división de tráfico y una métrica que distinga con fiabilidad lo bueno de lo malo dentro de la ventana de observación.

Cómo aplicarlo

• Hacer posible primero cualquier estrategia: comprobaciones de disponibilidad (readiness) que fallen antes de que el proceso esté listo, apagado ordenado ante SIGTERM, y cambios de base de datos y respuestas de API retrocompatibles para que convivan las versiones antigua y nueva.
• Usar rolling para servicios sin estado con versiones compatibles; ajustar maxUnavailable: 0 cuando la capacidad no deba disminuir.
• Usar blue-green cuando la mezcla de versiones sea inaceptable (conexiones de larga duración, cachés incompatibles) o cuando se desee un ensayo contra infraestructura real antes de la conmutación.
• Usar canary cuando un defecto solo se manifestaría con tráfico real y existe una señal medible (tasa de error, latencia, métrica de negocio); definir el umbral de cancelación antes de empezar.
• Combinar con feature toggles: una estrategia de despliegue controla qué binario se ejecuta, un toggle controla qué comportamiento está activo.

Trampas

La afinidad de sesión, las cachés de cliente y los TTL de DNS hacen que «conmutar el tráfico de una vez» sea más lento de lo esperado. Un canary que recibe una parte pequeña del tráfico observa los errores poco frecuentes con poca frecuencia, por lo que su ventana debe ser lo bastante larga como para ser concluyente. Las migraciones de base de datos no se revierten junto con el binario.

Blue-green no aísla el estado compartido

Blue y green comparten la base de datos, la cola y cualquier otro servicio de respaldo, de modo que desde el momento en que arranca la pila nueva (comprobaciones de salud, calentamiento, tráfico de ensayo) ambas versiones leen y escriben los mismos datos, y tras la conmutación la pila antigua permanece conectada durante la ventana de reversión. La mezcla de versiones que blue-green elimina es, por tanto, solo del tipo local al proceso: cachés en memoria, sesiones con afinidad, conexiones de larga duración, formatos en disco incompatibles dentro de la instancia. Los cambios de esquema y de formato de mensajes necesitan la misma disciplina de expandir y contraer que una actualización rolling, y la reversión instantánea solo se mantiene hasta que la nueva versión ha escrito algo que la antigua no puede leer. Conviene elegir blue-green para incompatibilidades locales al proceso o para un ensayo contra infraestructura real; no elegirlo para evitar cambios de datos retrocompatibles.