Blue-green y canary: cómo desplegar sin tumbar producción

⏱️ Lectura: 14 min

Un equipo despliega código nuevo a las tres de la tarde y en segundos el sitio empieza a devolver errores 500 a miles de usuarios. Revertir manualmente toma diez minutos de pánico mientras las quejas se acumulan en redes sociales.

📑 En este artículo

1. TL;DR
2. Qué es el despliegue canary (y qué es blue-green)
3. Cómo funciona un despliegue canary en detalle
4. Ejemplos prácticos: de un Service simple a un Rollout canary
5. Cómo empezar: instalar y correr tu primer despliegue canary
6. Casos de uso reales
7. Errores comunes y buenas prácticas
8. Comparativa: rolling update, blue-green, canary y feature flags
9. Profundizando: traffic mirroring y análisis estadístico
10. Preguntas frecuentes
    1. ¿Blue-green deployment y despliegue canary son excluyentes?
    2. ¿Necesito un service mesh como Istio para hacer despliegue canary?
    3. ¿Qué pasa con la base de datos durante un blue-green deployment?
    4. ¿Cuánto tráfico debería recibir un canary al inicio?
    5. ¿Qué herramientas open source implementan despliegue canary sobre Kubernetes?
    6. ¿El rolling update de Kubernetes ya no sirve entonces?
11. Referencias

El despliegue canary y el blue-green deployment existen exactamente para evitar ese escenario. Ambos permiten llevar código nuevo a producción sin arriesgar todo el tráfico real de golpe, y revertir en segundos si algo sale mal. La diferencia está en cómo mueven ese tráfico: blue-green lo cambia todo de una vez entre dos entornos idénticos, mientras que un despliegue canary lo desplaza de forma gradual y mide el impacto antes de completarlo.

TL;DR

• Vas a entender la diferencia real entre blue-green deployment y despliegue canary, y cuándo usar cada uno.
• Vas a poder cambiar el tráfico de un blue-green deployment con un simple selector de Kubernetes.
• Vas a poder escribir un Rollout de Argo Rollouts que despliega un canary con incrementos de tráfico controlados.
• Vas a entender por qué una migración de esquema incompatible rompe un despliegue sin downtime.
• Vas a poder comparar rolling update, blue-green, canary y feature flags en una tabla y elegir la correcta para tu caso.
• Vas a saber qué métricas mirar para automatizar un rollback antes de que un canary dañe producción.

Qué es el despliegue canary (y qué es blue-green)

Pensá en un blue-green deployment como dos escenarios de teatro idénticos: uno con la obra actual (blue) y otro con la obra nueva ya montada (green). El público, o sea el tráfico real, está sentado frente al escenario blue. Cuando el elenco de green terminó los ensayos, un único interruptor apaga las luces de blue y las enciende en green. El público nunca nota el cambio de escenario, solo ve la obra nueva desde el segundo siguiente.

Un despliegue canary funciona distinto. En vez de mover a todo el público de una vez, dejás que un grupo pequeño (por ejemplo el 10% de los espectadores) vea la función nueva mientras el resto sigue viendo la anterior. Si ese grupo reporta problemas, algo equivalente a un aumento en la tasa de error o en la latencia, cancelás la función nueva antes de que el resto del público la vea. El nombre viene de los canarios que los mineros llevaban bajo tierra: si el ave se desmayaba por un gas tóxico, el resto del equipo sabía que debía salir antes de que el peligro alcanzara a todos.

Ambas técnicas resuelven el mismo problema de fondo: el momento en que una versión nueva de software toca tráfico real por primera vez es, casi siempre, el instante más riesgoso del ciclo de vida de un sistema. Ningún entorno de staging reproduce con exactitud el volumen, la variedad de datos y el comportamiento de usuarios reales.

Cómo funciona un despliegue canary en detalle

En blue-green, la mecánica es simple: existen dos entornos completos (cómputo, y a veces base de datos), y un router, balanceador de carga, registro DNS o selector de Kubernetes apunta a uno solo de los dos. El despliegue ocurre en el entorno inactivo, se corren pruebas de humo contra él sin exponerlo al público, y luego el switch de tráfico es atómico: pasa de 0% a 100% en una sola operación. El rollback es simétrico: apuntar el router de vuelta al entorno anterior.

El despliegue canary necesita un mecanismo distinto: enrutamiento por peso. Un ingress controller, un service mesh (Istio, Linkerd) o una herramienta como Argo Rollouts dividen el tráfico entre dos grupos de pods que corren versiones distintas del mismo servicio, según un porcentaje configurado. Ese porcentaje sube en pasos definidos, casi siempre con una pausa entre cada paso para que un sistema de análisis automatizado compare las métricas del canary contra las del grupo estable antes de avanzar al siguiente paso.

flowchart LR
    U["Usuarios"] --> LB["Load Balancer"]
    LB -->|"trafico activo"| B["Entorno Blue (version actual)"]
    LB -.->|"en espera"| G["Entorno Green (version nueva)"]
    subgraph Produccion
    B
    G
    end

El diagrama anterior muestra el estado antes del swap: el load balancer envía todo el tráfico a blue mientras green espera, ya desplegado y probado, listo para recibir el 100% en una sola operación.

Ejemplos prácticos: de un Service simple a un Rollout canary

El ejemplo más simple de blue-green en Kubernetes no necesita ninguna herramienta externa: alcanza con un Service cuyo selector apunte a una etiqueta de versión.

apiVersion: v1
kind: Service
metadata:
  name: checkout-service
spec:
  selector:
    app: checkout
    version: blue
  ports:
    - port: 80
      targetPort: 8080

Este Service enruta tráfico únicamente hacia los pods etiquetados version: blue. Cuando el entorno green pasa las pruebas de humo, el único cambio necesario es editar ese selector:

kubectl patch service checkout-service \n  -p '{"spec":{"selector":{"version":"green"}}}'

Ese comando cambia el tráfico de golpe: los pods etiquetados version: green empiezan a recibir peticiones en cuanto Kubernetes actualiza los endpoints internos del Service. No hay periodo de mezcla entre versiones.

Un despliegue canary real necesita más granularidad que un selector binario. Argo Rollouts reemplaza al recurso Deployment estándar con un Rollout que define pasos explícitos de tráfico:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-rollout
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 300}
        - setWeight: 50
        - pause: {duration: 300}
        - setWeight: 100
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
        - name: checkout
          image: registry.example.com/checkout:2.4.0

Cada setWeight define el porcentaje de tráfico que ve la versión nueva; cada pause detiene el avance ese número de segundos para dar tiempo a observar métricas antes de seguir. Con 10 réplicas, un setWeight: 10 equivale aproximadamente a un pod del canary y nueve del grupo estable.

sequenceDiagram
    participant O as Operador
    participant R as Argo Rollouts
    participant C as Canary Pods
    participant S as Stable Pods
    O->>R: aplica nueva version
    R->>C: enruta 10% del trafico
    R->>S: mantiene 90% del trafico
    Note over R,C: analiza metricas de error y latencia
    R->>C: incrementa a 50% del trafico
    R->>C: promueve a 100% del trafico
    R->>S: retira version anterior

Cómo empezar: instalar y correr tu primer despliegue canary

Estos pasos asumen un clúster de Kubernetes de prueba (kind o minikube funcionan bien) y kubectl configurado.

# 1. Instalar el controlador de Argo Rollouts
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \n  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# 2. Instalar el plugin de kubectl
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# 3. Aplicar el Rollout definido arriba
kubectl apply -f checkout-rollout.yaml

# 4. Disparar un release nuevo cambiando la imagen
kubectl argo-rollouts set image checkout-rollout \n  checkout=registry.example.com/checkout:2.5.0

# 5. Observar el avance en vivo
kubectl argo-rollouts get rollout checkout-rollout --watch

Para confirmar que el canary está realmente activo y no en 0%, corré kubectl argo-rollouts status checkout-rollout: los campos de paso actual y peso de tráfico muestran el porcentaje exacto que está recibiendo el canary en ese momento, sin depender de lo que diga la configuración estática del YAML.

💡 Tip: antes de promover manualmente un paso pausado, corré kubectl argo-rollouts get rollout checkout-rollout y revisá el conteo de réplicas canary vs estable: si no coincide con el peso configurado, algo en el análisis automático lo está frenando.

Casos de uso reales

Una migración de versión de API donde un cambio de contrato podría romper a clientes viejos es un caso típico de despliegue canary: exponer el contrato nuevo a un 5% del tráfico deja ver, antes de romper a todos, si algún cliente integrado deja de funcionar.

Un cambio de proveedor de pagos en un checkout es un caso donde blue-green suele ganarle a canary: si el proveedor nuevo falla en el primer minuto, revertir instantáneamente evita dejar carritos de compra a medio procesar con dos proveedores mezclados.

El reentrenamiento de un modelo de recomendación o de scoring también se presta a canary con análisis automatizado: comparar la tasa de clics o de conversión del modelo nuevo contra el modelo estable, con tráfico real, antes de reemplazarlo por completo.

Una migración de infraestructura, como mover un servicio de una región de datacenter a otra, suele resolverse con blue-green completo: ambos entornos corren en paralelo durante la migración y el swap final de DNS o del Service evita cualquier ventana de downtime.

Errores comunes y buenas prácticas

Las sesiones con estado son la trampa más común de blue-green: si un usuario tiene su sesión guardada en la memoria de un pod de blue y el swap lo redirige a green, pierde la sesión de golpe. La solución es externalizar las sesiones (Redis, por ejemplo) en vez de guardarlas en memoria local del proceso.

Las migraciones de esquema no compatibles hacia atrás rompen tanto canary como blue-green. Si la versión nueva corre una migración que elimina una columna que la versión estable todavía lee, la versión estable empieza a fallar mientras ambas coexisten. La regla de oro: toda migración de esquema debe seguir siendo compatible con la versión anterior durante toda la ventana del despliegue.

Mantener dos entornos completos en blue-green duplica el gasto de cómputo mientras dura el despliegue. Para servicios grandes esto no es gratis, y es una de las razones por las que muchos equipos prefieren canary: nunca corre el 100% de la capacidad duplicada, solo el porcentaje del paso actual.

Un despliegue canary sin umbrales automatizados es solo decorativo. Mirar un dashboard dos minutos y decidir “se ve bien” no reemplaza un umbral configurado como el de Flagger: sin esa automatización, la decisión de rollback queda en manos de un humano que puede no notar una degradación pequeña a tiempo.

Por último, un CDN o el caché del navegador puede seguir sirviendo assets estáticos de la versión vieja después del swap, mezclando HTML nuevo con JavaScript viejo. La práctica estándar es versionar los archivos estáticos con un hash en el nombre.

⚠️ Ojo: blue-green da un rollback instantáneo, pero no protege contra bugs de lógica de negocio que solo aparecen con tráfico real, porque el 100% del tráfico ya quedó expuesto en el instante del swap. Ahí es donde el despliegue canary tiene una ventaja real: expone el riesgo a una fracción controlada antes de comprometer todo el tráfico.

Comparativa: rolling update, blue-green, canary y feature flags

Opción	Cuándo usarla	Ventaja	Limitación
Rolling update	Cambios de bajo riesgo, sin incompatibilidad esperada	Nativo en Kubernetes, sin herramientas extra	Sin rollback instantáneo; mezcla versiones durante el rollout
Blue-green deployment	Cambios grandes donde el rollback debe ser inmediato	Rollback en segundos, sin mezcla de versiones	Duplica el costo de infraestructura mientras dura el despliegue
Despliegue canary	Impacto incierto en usuarios reales que se puede medir	Expone el riesgo a una fracción controlada; rollback automatizado por métricas	Requiere infraestructura de análisis (Prometheus, service mesh)
Feature flags	Activar o desactivar funcionalidad sin redeploy	Control granular por usuario o segmento	Acumula deuda técnica si los flags viejos no se limpian

Profundizando: traffic mirroring y análisis estadístico

El siguiente nivel de sofisticación en despliegue canary es el traffic mirroring (o shadow traffic): un service mesh como Istio duplica cada request real y le envía una copia al canary, pero descarta la respuesta del canary antes de que llegue al usuario. Esto permite probar la versión nueva contra tráfico de producción real con riesgo cero, porque el usuario nunca ve la respuesta del canary.

Herramientas como Flagger van un paso más allá del simple umbral fijo: consultan métricas de Prometheus en cada intervalo y usan la comparación entre el grupo canary y el grupo estable para decidir si promover, pausar o revertir. La configuración típica define un umbral de tasa de éxito y de latencia por métrica:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: checkout
spec:
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m

Con esta configuración, Flagger consulta Prometheus cada minuto. Si la tasa de éxito cae debajo del umbral min: 99 o la duración de las peticiones supera max: 500 (en milisegundos), Flagger revierte el peso del canary a 0 automáticamente, sin esperar intervención humana.

Un matiz importante con muestras pequeñas: si el canary recibe solo el 5% del tráfico de un servicio de bajo volumen, unas pocas peticiones lentas pueden disparar una alerta falsa. Por eso el threshold en la configuración de Flagger no es un simple corte binario, sino un contador de fallos consecutivos: solo revierte después de varias mediciones consecutivas fuera de rango, no ante un único dato ruidoso.

flowchart TD
    A["Metricas degradadas detectadas"] --> B{"Error rate > umbral?"}
    B -->|"si"| C["Rollback automatico a 0% canary"]
    B -->|"no"| D["Continuar incrementando trafico"]
    C --> E["Alerta al equipo"]
    D --> F["Promocion a 100%"]

💭 Clave: el despliegue canary automatizado no elimina el riesgo de un despliegue, lo convierte en un experimento medible: cada paso de tráfico es una pregunta (“¿esta versión se comporta igual que la anterior?”) con una respuesta cuantificable antes de comprometer el resto del tráfico.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: levantá un clúster local con kind o minikube, instalá Argo Rollouts y convertí un Deployment de ejemplo en un Rollout canary con dos pasos de setWeight para ver el traffic split en vivo.

Preguntas frecuentes

¿Blue-green deployment y despliegue canary son excluyentes?

No. Muchos equipos usan blue-green para el switch final entre entornos completos y despliegue canary dentro del entorno nuevo para exponer gradualmente el tráfico antes del switch total.

¿Necesito un service mesh como Istio para hacer despliegue canary?

No es obligatorio. Herramientas como Argo Rollouts o el ingress controller de NGINX soportan traffic splitting por porcentaje sin un service mesh completo, aunque un mesh da más control a nivel de request.

¿Qué pasa con la base de datos durante un blue-green deployment?

Generalmente ambos entornos comparten la misma base de datos. Por eso toda migración de esquema debe ser compatible hacia atrás durante la transición, o hace falta una estrategia de blue-green también a nivel de base de datos.

¿Cuánto tráfico debería recibir un canary al inicio?

Depende del volumen total del servicio: cuanto menos tráfico tenga, mayor debe ser el porcentaje inicial para juntar suficientes datos y detectar una degradación real en poco tiempo.

¿Qué herramientas open source implementan despliegue canary sobre Kubernetes?

Argo Rollouts y Flagger son las dos opciones más usadas; ambas se integran con Prometheus para automatizar el análisis de métricas y el rollback.

¿El rolling update de Kubernetes ya no sirve entonces?

Sigue siendo la opción correcta para cambios de bajo riesgo donde no hace falta medir el impacto en tráfico real antes de completar el despliegue.

Referencias

• Martin Fowler, BlueGreenDeployment: la descripción original del patrón blue-green.
• Kubernetes docs, Deployments: estrategia de rolling update nativa y su configuración.
• Argo Rollouts, documentación oficial: recurso Rollout, pasos canary y análisis automatizado.
• Flagger, documentación oficial: análisis progresivo de canary con Prometheus.
• Istio, Traffic Management: enrutamiento por peso y traffic mirroring a nivel de service mesh.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Fotis Fotopoulos en Unsplash