Comparativa: estrategias de deploy zero‑downtime en Kubernetes — RollingUpdate vs Blue/Green vs Canary

Por Kevin Marcondes · Publicado el 01/10/2026 · Actualizado el 12/10/2026 · 7 min de lectura

Esta comparativa pone lado a lado las estrategias de deploy sin downtime en Kubernetes: RollingUpdate, Blue/Green y Canary. Verás cómo funcionan, cuándo usar cada una, trade‑offs, costes y ejemplos prácticos con Service, Ingress e Istio/Argo Rollouts. Usa los criterios al final para decidir con seguridad.

Qué significa zero‑downtime en Kubernetes, en la práctica

Zero‑downtime significa mantener la aplicación atendiendo sin errores percibidos durante el cambio de versión. En Kubernetes esto depende de readinessProbes, health checks, la política de actualización y de contar con capacidad adicional para solapar versiones.

Define SLOs claros: error máximo tolerado, p95 de latencia y ventana de observación. Sin métricas, no puedes validar si el rollout fue realmente “sin indisponibilidad”.

Aspectos críticos: tolerancia a conexiones largas, sesiones sticky, tiempo de warm‑up, caché y compatibilidad del esquema de base de datos.

• Readiness/liveness probes correctas y rápidas
• maxSurge/maxUnavailable ajustados al tráfico
• Capacidad de reserva para solapar versiones
• Logs y métricas por versión para comparar impacto
• Rollback claro y automatizado

RollingUpdate: simple y eficiente para la mayoría

RollingUpdate sustituye pods gradualmente dentro del mismo Deployment. Controlas cuántos pueden quedar indisponibles y cuántos pueden crearse por encima del objetivo mediante maxUnavailable y maxSurge.

Pros: sencillo, bajo coste de infraestructura y rollback rápido al restaurar la ReplicaSet anterior. Contras: el tráfico mezcla versiones, lo que complica comparaciones y puede afectar sesiones persistentes.

Funciona muy bien cuando la aplicación es stateless y compatible entre versiones. Automatiza el proceso desde el pipeline de CI/CD con triggers y validaciones de salud.

Consulta también cómo montar un pipeline en CI/CD con GitHub Actions: guía PHP/Laravel.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Blue/Green: aislamiento total con cambio de tráfico

Blue/Green mantiene dos versiones completas: Blue (actual) y Green (nueva). Pruebas la Green de forma aislada y, cuando está aprobada, conmutas el tráfico de una vez mediante Service, Ingress o balanceador.

Pros: separación fuerte y rollback instantáneo volviendo el selector. Contras: coste por duplicar capacidad durante las pruebas y la conmutación.

Es ideal cuando necesitas validar E2E con datos reales sin mezclar versiones. Atención a las migraciones de base de datos: prefiere evolucionar el esquema con compatibilidad directa y reversa. Para bases, revisa la Migración de bases sin downtime con CDC.

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  selector:
    app: api
    version: green  # mude para 'blue' no rollback
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
spec:
  replicas: 6
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2

Canary: medir impacto con tráfico parcial y promover

Canary envía una fracción del tráfico a la nueva versión y compara métricas. La promoción es gradual, por ejemplo: 5% → 25% → 50% → 100%. Puedes hacerlo con Ingresses que soporten canary o con una malla de servicio.

Herramientas como Istio o Argo Rollouts permiten división por peso, reglas y análisis automático. Combínalo con métricas de error, p95 de latencia y saturación. Integra feature flags para habilitar rutas de código de forma segura en paralelo al canary, como se explica en Feature flags en monolitos PHP.

Revisa también conceptos de enrutamiento ponderado en Istio en la documentación de los proveedores cloud (por ejemplo, el guide de Service Mesh de Google Cloud).

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-svc
            subset: v1
          weight: 95
        - destination:
            host: api-svc
            subset: v2
          weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api
spec:
  host: api-svc
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Tabla comparativa: criterios objetivos de elección

Compara por los criterios más importantes para el negocio y la operación. Abajo, un resumen práctico de las tres aproximaciones.

Enrutamiento: Service, Ingress y malla (Istio/Linkerd)

Service alterna versiones vía selectors. Ingress puede enrutar por host/path y, en algunos controladores, ofrecer canary mediante anotaciones. Las mallas añaden división de tráfico ponderada, circuit breaking y telemetría detallada.

Para ejemplos de canary y gestión de tráfico con malla, consulta la documentación de los proveedores (por ejemplo, Google Cloud sobre Service Mesh y enrutamiento ponderado). Blue/Green con balanceadores gestionados en EKS también es habitual.

• Service: cambio de selector de labels para Blue/Green
• Ingress: split por host/path y, en algunos casos, canary
• Service Mesh: pesos por subset, retries y políticas mTLS

Costes, riesgos y gobernanza del rollout

Los costes varían según réplicas necesarias, tráfico, ventanas de canary y la duplicación en Blue/Green. Tráfico alto e imágenes grandes aumentan egress y el tiempo de rollout.

Riesgos comunes: migraciones incompatibles, caídas de rendimiento en la versión nueva y sesiones perdidas. Redúcelos con pruebas E2E, smoke tests automáticos y métricas por versión.

Documenta criterios de promoción y rollback. Cronogramas, playbooks y responsabilidades claras ayudan. Si sufres incidentes frecuentes en deploys, evalúa una Auditoría de despliegues y plan de corrección.

• Define métricas‑guía: error, latencia y saturación
• Automatiza gates de promoción y rollback
• Reserva capacidad para solapamiento seguro
• Planifica migraciones compatibles y reversibles
• Valida sesiones y sticky routing cuando sea necesario

Preguntas frecuentes

¿Cuándo elegir RollingUpdate en lugar de Blue/Green o Canary?

Cuando el servicio es stateless, las versiones son compatibles y buscas simplicidad y bajo coste. RollingUpdate funciona bien como estándar. Si necesitas aislar versiones para pruebas E2E o medir impacto con precisión, considera Blue/Green o Canary.

¿Puedo hacer Canary sin service mesh?

Sí. Algunos controladores de Ingress soportan canary mediante anotaciones, redirigiendo una fracción del tráfico. Sin embargo, la observabilidad y los controles de política suelen ser más limitados que en una malla de servicio, donde dispones de pesos por subset y telemetría integrada.

¿Cómo tratar migraciones de base de datos durante el deploy?

Usa migraciones compatibles con versiones simultáneas. Primero aplica cambios aditivos y conserva campos antiguos. Haz el rollout de la aplicación y, después, elimina campos obsoletos. Para escenarios críticos, valora CDC para la transición sin interrupción.

¿Qué estrategia tiene rollback más rápido?

Blue/Green suele ofrecer rollback instantáneo, ya que basta revertir el selector o la ruta. RollingUpdate revierte a la ReplicaSet anterior. En Canary, reduces a cero el peso de la versión nueva, lo que también resulta rápido. La automatización y la preparación del sistema influyen en el tiempo.

¿Qué métricas vigilar en un canary release?

Errores por segundo, tasa de 5xx/4xx relevantes, p95/p99 de latencia, saturación de CPU/memoria, colas y timeouts. Monitoriza por versión para comparar con la baseline. Define thresholds y ventanas de observación para promoción automática o rollback.

Ver también

• Ceph vs NFS vs GlusterFS para almacenamiento compartido en VPS con contenedores
• Comparativa: Prometheus+Grafana vs Loki+Tempo para observabilidad de aplicaciones PHP
• Comparativa: Amazon SQS vs RabbitMQ gestionado para integraciones entre ERP y marketplaces
• Comparativa: Traefik vs Caddy para enrutamiento HTTPS en entornos Docker