Comparativo: estratégias de deploy zero‑downtime em Kubernetes — RollingUpdate vs Blue/Green vs Canary

Por Kevin Marcondes · Publicado em 01/10/2026 · Atualizado em 10/10/2026 · 7 min de leitura

Este comparativo coloca lado a lado estratégias de deploy zero‑downtime em Kubernetes: RollingUpdate, Blue/Green e Canary. Você verá como funcionam, quando usar cada uma, trade‑offs, custos e exemplos práticos com Service, Ingress e Istio/Argo Rollouts. Use os critérios ao final para decidir com segurança.

O que significa zero‑downtime no Kubernetes, na prática

Zero‑downtime é manter a aplicação atendendo sem erros percebidos durante a troca de versão. No Kubernetes, isso depende de readinessProbes, health checks, política de atualização e capacidade extra para sobrepor versões.

Defina SLOs claros: erro máximo tolerado, p95 de latência e janela de observação. Sem métricas, você não valida se o rollout foi realmente "sem indisponibilidade".

Aspectos críticos: tolerância a conexões longas, sticky sessions, tempo de warm‑up, cache e compatibilidade de esquema de banco de dados.

• Readiness/liveness probes corretas e rápidas
• maxSurge/maxUnavailable ajustados ao tráfego
• Capacidade reserva para sobrepor versões
• Logs e métricas por versão para comparar impacto
• Rollback claro e automatizado

RollingUpdate: simples e eficiente para a maioria

RollingUpdate substitui pods gradualmente dentro do mesmo Deployment. Você controla quantos podem ficar indisponíveis e quantos podem surgir além do desejado via maxUnavailable e maxSurge.

Prós: simples, baixo custo de infraestrutura e rollback rápido alterando a ReplicaSet anterior. Contras: tráfego mistura versões, o que dificulta comparações e pode afetar sessões persistentes.

Funciona muito bem quando a aplicação é stateless e compatível entre versões. Automatize via pipeline de CI/CD com gatilhos e validações de saúde.

Veja também como montar um pipeline em CI/CD com GitHub Actions: guia 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: isolamento total com troca de tráfego

Blue/Green mantém duas versões completas: Blue (atual) e Green (nova). Você testa Green isoladamente e, quando aprovada, alterna o tráfego de uma vez, via Service, Ingress ou load balancer.

Prós: separação forte e rollback instantâneo voltando o seletor. Contras: custo de capacidade duplicada durante o teste e a troca.

É ideal quando você precisa validar E2E com dados reais sem misturar versões. Atenção a migrações de banco: prefira evoluir esquema com compatibilidade direta e reversa. Para bancos, veja a abordagem de CDC em Estratégia de migração de banco de dados com zero-downtime usando 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 com tráfego parcial e promover

Canary envia uma fração do tráfego para a nova versão e compara métricas. A promoção é gradual, ex.: 5% → 25% → 50% → 100%. Você pode fazer isso com Ingress que suporta canary ou malha de serviço.

Ferramentas como Istio ou Argo Rollouts permitem divisão por peso, regras e análise automática. Combine com métricas de erro, latência p95 e saturação. Integre feature flags para liberar caminhos de código com segurança em paralelo a canary, como discutido em Feature flags em monólitos PHP: rollout seguro.

Veja conceitos de roteamento ponderado em Istio na documentação do provedor de nuvem, como no guia de tráfego do Service Mesh da 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

Tabela comparativa: critérios objetivos de escolha

Compare pelos critérios mais importantes ao negócio e à operação. Abaixo, um resumo prático das três abordagens.

Roteamento: Service, Ingress e malha (Istio/Linkerd)

Service alterna versões via selectors. Ingress pode rotear por host/path e, em alguns controladores, oferecer canary por anotação. Malhas adicionam divisão de tráfego ponderada, circuit breaking e telemetria detalhada.

Para exemplos de canary e gestão de tráfego com malha, consulte documentação de provedores: Google Cloud sobre Service Mesh e roteamento ponderado. Blue/Green com balanceadores gerenciados em EKS também é comum.

• Service: troca seletor de labels para Blue/Green
• Ingress: split por host/path e, em alguns casos, canary
• Service Mesh: pesos por subset, retries e políticas mTLS

Custos, riscos e governança do rollout

Custos variam por réplicas necessárias, tráfego, janelas de canary e duplicação de ambientes em Blue/Green. Tráfego alto e imagens grandes elevam egress e tempo de rollout.

Riscos comuns: migrações incompatíveis, quedas de performance na versão nova e sessões perdidas. Reduza com testes E2E, smoke tests automáticos e métricas por versão.

Documente critérios de promoção e rollback. Cronogramas, playbooks e responsabilidades claras ajudam. Se você sofre com incidentes frequentes em deploys, avalie uma Auditoria de processos de deploy e plano de correção.

• Defina métricas‑guia: erro, latência e saturação
• Automatize gates de promoção e rollback
• Reserve capacidade para sobreposição segura
• Planeje migrações compatíveis e reversíveis
• Valide sessões e sticky routing quando necessário

Perguntas frequentes

Quando escolher RollingUpdate em vez de Blue/Green ou Canary?

Quando o serviço é stateless, as versões são compatíveis e você quer simplicidade e baixo custo. RollingUpdate funciona muito bem como padrão. Se precisa isolar versões para testes E2E ou medir impacto com precisão, considere Blue/Green ou Canary.

Posso fazer Canary sem service mesh?

Sim. Alguns controladores de Ingress suportam canary por anotação, redirecionando uma fração do tráfego. Porém, a observabilidade e os controles de política tendem a ser mais limitados que em uma malha de serviço, onde há pesos por subset e telemetria integrada.

Como tratar migrações de banco durante o deploy?

Use migrações compatíveis com versões simultâneas. Primeiro, aplique mudanças aditivas e preserve campos antigos. Faça o rollout da aplicação. Só depois remova campos obsoletos. Para cenários críticos, avalie CDC para transicionar sem interrupção.

Qual estratégia tem rollback mais rápido?

Blue/Green tende a ter rollback instantâneo, pois basta reverter o seletor ou rota. RollingUpdate reverte para a ReplicaSet anterior. Em Canary, você zera o peso da versão nova, o que também é rápido. A prontidão do sistema e automação influenciam o tempo.

Quais métricas observar em um canary release?

Erros por segundo, taxa de 5xx/4xx relevantes, p95/p99 de latência, saturação de CPU/memória, filas e timeouts. Monitore por versão para comparar com a baseline. Defina thresholds e janelas de observação para promoção automática ou rollback.

Veja também

• Ceph vs NFS vs GlusterFS para storage compartilhado em VPS com containers
• Comparativo: Prometheus+Grafana vs Loki+Tempo para observabilidade de aplicações PHP
• Comparativo: Amazon SQS vs RabbitMQ gerenciado para integrações entre ERP e marketplaces
• comparativo: Traefik vs Caddy para roteamento HTTPS em ambientes Docker