DEV Community

Cover image for Estratégias de Deploy no Kubernetes: Rolling Update, Canary Deployment e Blue-Green
Kauê Matos
Kauê Matos

Posted on

Estratégias de Deploy no Kubernetes: Rolling Update, Canary Deployment e Blue-Green

#webdev #programming #kubernetes #productivity

Realizar o deploy de uma nova versão de uma aplicação em produção é uma das etapas mais críticas de um processo de entrega de software. Mesmo quando uma aplicação possui testes automatizados, pipelines de CI/CD, ambientes de homologação e validações de qualidade, ainda existe um risco associado à execução da nova versão em produção.

Problemas de performance, incompatibilidades com serviços externos, falhas de integração, consumo excessivo de memória, aumento de latência e erros não previstos podem aparecer apenas quando a aplicação está submetida ao tráfego real.

Nesse contexto, estratégias de deployment são utilizadas para reduzir o risco de uma nova versão. Em vez de simplesmente desligar a aplicação antiga e iniciar a nova, podemos controlar como a nova versão será introduzida no ambiente produtivo.

No Kubernetes, existem estratégias nativas, principalmente o Rolling Update, e estratégias mais avançadas de Progressive Delivery, como Canary Deployment e Blue-Green Deployment, normalmente implementadas com ferramentas como o Argo Rollouts.

As três abordagens possuem objetivos semelhantes: disponibilizar novas versões de forma segura. Entretanto, cada uma controla de maneira diferente aspectos como:

  • Quantidade de usuários expostos à nova versão;
  • Velocidade do deployment;
  • Capacidade de rollback;
  • Consumo de infraestrutura;
  • Controle do tráfego;
  • Validação por métricas;
  • Impacto de uma falha em produção.

1. O que é uma estratégia de deployment?

Uma estratégia de deployment define como uma versão nova substitui a versão atualmente executada.

Imagine uma aplicação em produção na versão:

Aplicação v1
Enter fullscreen mode Exit fullscreen mode

Uma nova versão é desenvolvida:

Aplicação v2
Enter fullscreen mode Exit fullscreen mode

A principal questão passa a ser:

Como migrar os usuários da versão v1 para a versão v2 com o menor risco possível?

Existem diferentes respostas para esse problema.

Rolling Update 

v1 → v1 + v2 → v2
Enter fullscreen mode Exit fullscreen mode

Os Pods antigos são substituídos gradualmente.

Blue-Green 

Blue (v1) → validação da Green (v2) → troca de tráfego → Green (v2)
Enter fullscreen mode Exit fullscreen mode

As duas versões coexistem, mas normalmente apenas uma recebe o tráfego produtivo.

Canary 

90% v1 + 10% v2
        ↓
70% v1 + 30% v2
        ↓
50% v1 + 50% v2
        ↓
0% v1 + 100% v2
Enter fullscreen mode Exit fullscreen mode

A nova versão recebe uma pequena parcela do tráfego e sua exposição aumenta progressivamente após validação.

2. Rolling Update: a estratégia nativa do Kubernetes

O Rolling Update é a estratégia mais comum e padrão para objetos Deployment no Kubernetes.

O Kubernetes substitui gradualmente os Pods pertencentes à versão antiga pelos Pods da nova versão. Durante o processo, ambas as versões podem coexistir temporariamente. A estratégia RollingUpdate é o padrão do Deployment, enquanto a alternativa nativa é Recreate.

Imagine uma aplicação com cinco réplicas:

Versão atual:

Pod 1 - v1
Pod 2 - v1
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1
Enter fullscreen mode Exit fullscreen mode

Após iniciar o deployment da versão v2:

Pod 1 - v2
Pod 2 - v1
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1
Enter fullscreen mode Exit fullscreen mode

Depois:

Pod 1 - v2
Pod 2 - v2
Pod 3 - v1
Pod 4 - v1
Pod 5 - v1
Enter fullscreen mode Exit fullscreen mode

O processo continua até:

Pod 1 - v2
Pod 2 - v2
Pod 3 - v2
Pod 4 - v2
Pod 5 - v2
Enter fullscreen mode Exit fullscreen mode

A velocidade e o comportamento dessa substituição são controlados principalmente por:

  • maxSurge
  • maxUnavailable

2.1 maxSurge

O parâmetro maxSurge define quantos Pods adicionais podem ser criados temporariamente durante o deployment.

Considere:

replicas: 10
Enter fullscreen mode Exit fullscreen mode

Com:

maxSurge: 2
Enter fullscreen mode Exit fullscreen mode

O Kubernetes pode executar temporariamente até:

10 Pods desejados + 2 Pods extras = 12 Pods
Enter fullscreen mode Exit fullscreen mode

Isso permite criar novos Pods antes de remover todos os Pods antigos.

Também é possível utilizar porcentagem:

maxSurge: 25%
Enter fullscreen mode Exit fullscreen mode

A documentação do Kubernetes permite valores absolutos ou percentuais; percentuais para maxSurge são arredondados para cima. O padrão é 25%.

2.2 maxUnavailable

O parâmetro maxUnavailable define quantos Pods podem ficar indisponíveis durante a atualização.

Exemplo:

replicas: 10
Enter fullscreen mode Exit fullscreen mode 
maxUnavailable: 1
Enter fullscreen mode Exit fullscreen mode

Durante o processo, o Kubernetes tentará garantir que no mínimo nove Pods permaneçam disponíveis.

Também é possível utilizar porcentagem:

maxUnavailable: 20%
Enter fullscreen mode Exit fullscreen mode

Nesse caso, até 20% das réplicas desejadas podem estar indisponíveis durante a atualização. Para porcentagens, o Kubernetes arredonda maxUnavailable para baixo; o padrão também é 25%.

2.3 Exemplo de Rolling Update 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: application
spec:
  replicas: 5

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0
          ports:
            - containerPort: 8080

          readinessProbe:
            httpGet:
              path: /health
              port: 8080
Enter fullscreen mode Exit fullscreen mode

Com essa configuração:

Replicas desejadas: 5
maxSurge: 1
maxUnavailable: 0
Enter fullscreen mode Exit fullscreen mode

O Kubernetes pode criar um Pod adicional temporariamente, chegando a seis Pods, enquanto busca manter os cinco Pods disponíveis.

Um fluxo simplificado seria:

[ v1 ][ v1 ][ v1 ][ v1 ][ v1 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v1 ][ v1 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v1 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v1 ][ v2 ][ v2 ]

        ↓

[ v1 ][ v1 ][ v2 ][ v2 ][ v2 ]

        ↓

[ v1 ][ v2 ][ v2 ][ v2 ][ v2 ]

        ↓

[ v2 ][ v2 ][ v2 ][ v2 ][ v2 ]
Enter fullscreen mode Exit fullscreen mode

2.4 Vantagens do Rolling Update

Simplicidade

Não exige necessariamente ferramentas adicionais.

O próprio Kubernetes gerencia o processo através do recurso Deployment.

Menor consumo de infraestrutura

Normalmente não é necessário manter duas versões completas da aplicação durante todo o deployment.

Ausência de downtime em configurações adequadas

Com probes, réplicas suficientes e valores corretos de maxSurge e maxUnavailable, é possível atualizar a aplicação gradualmente sem interromper o serviço.

Integração nativa

Funciona diretamente com:

Deployment
ReplicaSet
Service
Readiness Probe
Liveness Probe
HPA
Enter fullscreen mode Exit fullscreen mode

2.5 Limitações do Rolling Update

O maior problema é que o Rolling Update não fornece controle preciso sobre qual percentual dos usuários recebe cada versão.

Por exemplo, se existem:

10 Pods
Enter fullscreen mode Exit fullscreen mode

e durante o deployment temos:

9 Pods v1
1 Pod v2
Enter fullscreen mode Exit fullscreen mode

isso não significa necessariamente que exatamente 10% dos usuários receberão a nova versão.

O tráfego dependerá de fatores como:

  • Balanceamento do Service;
  • Conexões persistentes;
  • Distribuição de requisições;
  • Número de réplicas;
  • Comportamento do cliente;
  • Ingress;
  • Service Mesh.

Além disso, o Kubernetes Deployment não realiza, por conta própria, análise de métricas de negócio para decidir se uma versão deve continuar ou sofrer rollback. Ferramentas de progressive delivery adicionam esse tipo de capacidade.

3. Canary Deployment

O Canary Deployment é uma estratégia na qual uma pequena parcela dos usuários recebe inicialmente a nova versão da aplicação.

O objetivo é limitar o chamado blast radius, ou seja, limitar o número de usuários potencialmente impactados caso exista um problema.

O conceito vem da ideia de validar uma mudança em pequena escala antes de expô-la completamente.

Imagine:

Versão estável: v1
Nova versão: v2
Enter fullscreen mode Exit fullscreen mode

Em vez de migrar todos os usuários:

100% → v2
Enter fullscreen mode Exit fullscreen mode

podemos fazer:

95% → v1
5%  → v2
Enter fullscreen mode Exit fullscreen mode

Após análise:

90% → v1
10% → v2
Enter fullscreen mode Exit fullscreen mode

Depois:

75% → v1
25% → v2
Enter fullscreen mode Exit fullscreen mode

E assim sucessivamente:

50% → v1
50% → v2

↓

25% → v1
75% → v2

↓

0% → v1
100% → v2
Enter fullscreen mode Exit fullscreen mode

O Argo Rollouts define Canary como uma estratégia em que a nova versão é liberada para uma pequena porcentagem do tráfego de produção e permite configurar etapas específicas para controlar essa progressão.

4. Canary Deployment com Argo Rollouts

O Kubernetes padrão não possui um objeto Deployment com Canary completo baseado em porcentagem de tráfego e análise progressiva de métricas.

Para esse cenário, uma solução comum é utilizar o Argo Rollouts, que adiciona um controlador e CRDs para estratégias como Canary e Blue-Green. Ele também pode integrar o rollout com Ingress Controllers, Service Meshes e provedores de métricas.

Em vez de:

kind: Deployment
Enter fullscreen mode Exit fullscreen mode

podemos utilizar:

kind: Rollout
Enter fullscreen mode Exit fullscreen mode

Exemplo:

apiVersion: argoproj.io/v1alpha1
kind: Rollout

metadata:
  name: application

spec:
  replicas: 10

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0
          ports:
            - containerPort: 8080

  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause:
            duration: 5m

        - setWeight: 25
        - pause:
            duration: 10m

        - setWeight: 50
        - pause:
            duration: 15m

        - setWeight: 100
Enter fullscreen mode Exit fullscreen mode

Nesse cenário, a estratégia é:

Etapa 1
10% do tráfego → nova versão

        ↓

Aguardar 5 minutos

        ↓

Etapa 2
25% do tráfego → nova versão

        ↓

Aguardar 10 minutos

        ↓

Etapa 3
50% do tráfego → nova versão

        ↓

Aguardar 15 minutos

        ↓

Etapa final
100% → nova versão
Enter fullscreen mode Exit fullscreen mode

O Argo Rollouts permite etapas como setWeight e pause, inclusive pausas manuais ou com duração configurada.

5. O papel do Traffic Routing no Canary

Existe uma diferença importante entre:

Quantidade de Pods
Enter fullscreen mode Exit fullscreen mode

e:

Quantidade de tráfego
Enter fullscreen mode Exit fullscreen mode

Suponha que existam:

9 Pods v1
1 Pod v2
Enter fullscreen mode Exit fullscreen mode

Podemos pensar inicialmente:

1 Pod de 10 = 10% do tráfego
Enter fullscreen mode Exit fullscreen mode

Porém, isso é apenas uma aproximação.

Sem um mecanismo avançado de roteamento, a distribuição pode ser aproximada pela proporção de Pods. A própria documentação do Argo Rollouts destaca essa limitação e explica que, para um controle mais fino de pesos, é necessário utilizar um Ingress Controller ou Service Mesh com capacidade de traffic shaping.

Com um sistema de traffic routing, é possível definir:

95% → Stable
5%  → Canary
Enter fullscreen mode Exit fullscreen mode

mesmo que a quantidade de Pods não represente exatamente essa mesma proporção.

Exemplo conceitual:

                   ┌──────────────────┐
Usuários ────────► │ Ingress / Gateway│
                   └────────┬─────────┘
                            │
                  ┌─────────┴─────────┐
                  │                   │
                90%                 10%
                  │                   │
                  ▼                   ▼
          ┌─────────────┐     ┌─────────────┐
          │ Stable v1   │     │ Canary v2   │
          └─────────────┘     └─────────────┘
Enter fullscreen mode Exit fullscreen mode

Dependendo da arquitetura, o roteamento pode ser integrado com tecnologias como:

  • NGINX;
  • Istio;
  • Linkerd;
  • AWS ALB;
  • App Mesh;
  • SMI e outros provedores suportados.

O Argo Rollouts possui integrações específicas para diferentes mecanismos de traffic routing.

6. Canary baseado em métricas

Um dos maiores benefícios do Canary é a possibilidade de tomar decisões baseadas em dados reais.

Durante uma etapa:

90% Stable
10% Canary
Enter fullscreen mode Exit fullscreen mode

podemos monitorar indicadores como:

Taxa de erro 

HTTP 5xx
Exceptions
Falhas de API
Enter fullscreen mode Exit fullscreen mode

Latência 

p95
p99
Tempo médio de resposta
Enter fullscreen mode Exit fullscreen mode

Consumo de recursos 

CPU
Memória
Network
Enter fullscreen mode Exit fullscreen mode

Métricas de negócio 

Pedidos concluídos
Logins realizados
Pagamentos aprovados
Taxa de conversão
Enter fullscreen mode Exit fullscreen mode

Suponha que a nova versão apresente:

v1
Error Rate: 0.2%
p95: 150ms
Enter fullscreen mode Exit fullscreen mode

E o Canary:

v2
Error Rate: 4.8%
p95: 1200ms
Enter fullscreen mode Exit fullscreen mode

O rollout pode ser interrompido antes que a nova versão seja entregue para toda a base de usuários.

O Argo Rollouts oferece integração com provedores de métricas e análise para apoiar promoções ou rollbacks automatizados.

7. Fluxo completo de um Canary Deployment

Um fluxo de produção pode funcionar assim:

                    CI/CD Pipeline
                          │
                          ▼
                    Build da imagem
                          │
                          ▼
                  Testes automatizados
                          │
                          ▼
                 Publicação no Registry
                          │
                          ▼
                   Atualização do Rollout
                          │
                          ▼
                Nova versão é criada
                          │
                          ▼
                   5% do tráfego
                          │
                          ▼
                  Análise de métricas
                     │            │
                  Sucesso       Falha
                     │            │
                     ▼            ▼
                10% tráfego    Rollback
                     │
                     ▼
                  25% tráfego
                     │
                     ▼
                  50% tráfego
                     │
                     ▼
                 100% tráfego
                     │
                     ▼
                 Deploy concluído
Enter fullscreen mode Exit fullscreen mode

8. Blue-Green Deployment

O Blue-Green Deployment trabalha com dois ambientes ou duas versões da aplicação.

Tradicionalmente:

Blue  = versão atual
Green = nova versão
Enter fullscreen mode Exit fullscreen mode

Exemplo:

BLUE
my-application:1.0.0
Enter fullscreen mode Exit fullscreen mode 
GREEN
my-application:2.0.0
Enter fullscreen mode Exit fullscreen mode

Inicialmente:

Usuários
    │
    ▼
BLUE - v1
Enter fullscreen mode Exit fullscreen mode

A nova versão é criada:

                 ┌──────────────┐
                 │ BLUE - v1    │
Usuários ───────►│ Produção     │
                 └──────────────┘

                 ┌──────────────┐
                 │ GREEN - v2   │
                 │ Preview/Test │
                 └──────────────┘
Enter fullscreen mode Exit fullscreen mode

A versão Green pode ser validada antes de receber o tráfego principal.

Após a aprovação:

Antes:

Usuários → BLUE v1
Enter fullscreen mode Exit fullscreen mode

Depois:

Usuários → GREEN v2
Enter fullscreen mode Exit fullscreen mode

A troca pode ser muito rápida porque, em vez de substituir Pods progressivamente, o roteamento de produção passa a apontar para a nova versão.

A documentação do Argo Rollouts descreve Blue-Green como uma estratégia na qual a versão antiga e a nova podem coexistir, enquanto a nova é validada antes da troca do tráfego de produção.

9. Blue-Green no Kubernetes com Argo Rollouts

O Argo Rollouts pode utilizar dois Services:

Active Service
Preview Service
Enter fullscreen mode Exit fullscreen mode

A arquitetura pode ser representada assim:

                         ┌──────────────────────┐
                         │      Usuários        │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │   Active Service     │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │      BLUE v1         │
                         │     Produção         │
                         └──────────────────────┘


                         ┌──────────────────────┐
                         │   Preview Service    │
                         └──────────┬───────────┘
                                    │
                                    ▼
                         ┌──────────────────────┐
                         │      GREEN v2        │
                         │      Preview         │
                         └──────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Exemplo:

apiVersion: argoproj.io/v1alpha1
kind: Rollout

metadata:
  name: application

spec:
  replicas: 5

  selector:
    matchLabels:
      app: application

  template:
    metadata:
      labels:
        app: application

    spec:
      containers:
        - name: application
          image: my-application:2.0.0

  strategy:
    blueGreen:
      activeService: application-active
      previewService: application-preview

      autoPromotionEnabled: false

      scaleDownDelaySeconds: 30
Enter fullscreen mode Exit fullscreen mode

Nesse modelo, o activeService continua direcionando o tráfego normal para a versão atual, enquanto o previewService pode direcionar tráfego de validação para a nova versão. O Argo Rollouts permite pausar antes da promoção usando autoPromotionEnabled: false e possui configurações adicionais para análise antes ou depois da promoção.

10. Fluxo do Blue-Green Deployment

Podemos dividir o processo em etapas.

Etapa 1 — Produção 

Active Service
       │
       ▼
BLUE - v1
Enter fullscreen mode Exit fullscreen mode

A versão atual atende os usuários.

Etapa 2 — Criação da nova versão 

Active Service                Preview Service
       │                             │
       ▼                             ▼
BLUE - v1                      GREEN - v2
Produção                       Nova versão
Enter fullscreen mode Exit fullscreen mode

A nova versão é iniciada.

Etapa 3 — Validação

A equipe pode testar:

GREEN - v2
Enter fullscreen mode Exit fullscreen mode

Por meio de:

  • Smoke tests;
  • Testes automatizados;
  • Testes de integração;
  • Testes manuais;
  • Testes de performance;
  • Análise de métricas.

Etapa 4 — Promoção

Após a aprovação:

Antes:

Active Service → BLUE v1
Enter fullscreen mode Exit fullscreen mode

A promoção altera o direcionamento:

Depois:

Active Service → GREEN v2
Enter fullscreen mode Exit fullscreen mode

O tráfego produtivo é transferido para a nova versão.

Etapa 5 — Período de segurança

A versão anterior pode continuar disponível temporariamente.

GREEN - v2 → Produção

BLUE - v1 → Mantida temporariamente
Enter fullscreen mode Exit fullscreen mode

Isso facilita uma reversão rápida caso um problema seja identificado.

11. Rollback no Blue-Green

O Blue-Green possui uma característica muito importante: a versão anterior pode continuar pronta para uso.

Imagine:

BLUE = v1
GREEN = v2
Enter fullscreen mode Exit fullscreen mode

Após a promoção:

Usuários → GREEN v2
Enter fullscreen mode Exit fullscreen mode

Se for identificado um problema crítico:

Usuários → BLUE v1
Enter fullscreen mode Exit fullscreen mode

O rollback pode ser baseado na reversão do roteamento, desde que a versão anterior ainda esteja disponível e compatível com o estado do sistema.

Porém, existe um ponto fundamental: rollback de aplicação não significa automaticamente rollback de banco de dados.

Imagine que a versão v2 execute uma migration:

ALTER TABLE users ADD COLUMN new_field;
Enter fullscreen mode Exit fullscreen mode

Isso pode ser compatível com a versão antiga.

Mas imagine uma migration destrutiva:

ALTER TABLE users DROP COLUMN old_field;
Enter fullscreen mode Exit fullscreen mode

Caso a versão v1 dependa dessa coluna:

Rollback da aplicação → v1
Banco de dados → incompatível
Enter fullscreen mode Exit fullscreen mode

Portanto, estratégias de deployment devem ser combinadas com estratégias seguras de evolução de banco de dados.

Uma abordagem muito utilizada é:

Expand
   ↓
Deploy
   ↓
Migrate
   ↓
Contract
Enter fullscreen mode Exit fullscreen mode

Por exemplo:

Expand

Adicionar a nova estrutura sem remover a antiga.

Banco v1 + novas estruturas
Enter fullscreen mode Exit fullscreen mode

Deploy

Publicar a aplicação nova.

Aplicação v1 + Aplicação v2 compatíveis
Enter fullscreen mode Exit fullscreen mode

Migrate

Migrar gradualmente dados ou comportamento.

Contract

Somente após a estabilização remover estruturas antigas.

12. Comparação entre Rolling Update, Canary e Blue-Green

Característica Rolling Update Canary Blue-Green
Estratégia nativa no Kubernetes Sim Não de forma completa Não de forma completa
Ferramenta adicional Não necessariamente Geralmente sim Geralmente sim
Duas versões simultâneas Temporariamente Sim Sim
Controle percentual de tráfego Limitado Excelente com traffic routing Geralmente troca de ambiente
Validação gradual Limitada Excelente Pré/pós-promoção
Rollback Possível Excelente Muito rápido
Consumo de infraestrutura Baixo/Médio Médio Alto
Complexidade Baixa Alta Média
Ideal para Aplicações comuns Sistemas críticos e alto tráfego Sistemas que exigem troca controlada

13. Comparação visual

Rolling Update 

v1 v1 v1 v1 v1

↓ Deploy

v2 v1 v1 v1 v1

↓

v2 v2 v1 v1 v1

↓

v2 v2 v2 v1 v1

↓

v2 v2 v2 v2 v1

↓

v2 v2 v2 v2 v2
Enter fullscreen mode Exit fullscreen mode

Canary 

Produção

95% → v1
5%  → v2

↓

90% → v1
10% → v2

↓

75% → v1
25% → v2

↓

50% → v1
50% → v2

↓

0% → v1
100% → v2
Enter fullscreen mode Exit fullscreen mode

Blue-Green 

Fase inicial

100% → BLUE v1
0%   → GREEN v2


Validação

100% → BLUE v1
GREEN v2 → Preview/Test


Promoção

0%   → BLUE v1
100% → GREEN v2
Enter fullscreen mode Exit fullscreen mode

14. Quando utilizar Rolling Update?

O Rolling Update é uma excelente escolha quando:

  • A aplicação possui múltiplas réplicas;
  • Existe uma boa estratégia de readiness probes;
  • As versões podem coexistir;
  • Não existe necessidade de controle preciso do tráfego;
  • O sistema possui risco moderado;
  • A equipe deseja simplicidade operacional.

Exemplo:

API interna
5 réplicas
Baixo risco
Boa cobertura de testes
Enter fullscreen mode Exit fullscreen mode

Uma configuração como:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
Enter fullscreen mode Exit fullscreen mode

pode ser suficiente.

O Kubernetes também permite acompanhar o andamento do rollout e detectar falta de progresso através de progressDeadlineSeconds; a documentação indica que o padrão é 600 segundos.

15. Quando utilizar Canary Deployment?

O Canary é recomendado quando:

  • A aplicação possui grande volume de usuários;
  • Uma falha pode causar grande impacto;
  • Existem métricas confiáveis;
  • A equipe possui observabilidade madura;
  • Existe necessidade de limitar o impacto de uma nova versão;
  • O sistema permite múltiplas versões executando simultaneamente.

Exemplo:

API de pagamentos
Milhões de requisições
SLA crítico
Prometheus + Grafana + Alerting
Enter fullscreen mode Exit fullscreen mode

Uma estratégia possível:

1%
↓
5%
↓
10%
↓
25%
↓
50%
↓
100%
Enter fullscreen mode Exit fullscreen mode

Entre cada etapa:

Analisar:
- Error rate
- p95
- p99
- CPU
- Memory
- Métricas de negócio
Enter fullscreen mode Exit fullscreen mode

Se algo falhar:

Abortar
↓
Retornar tráfego para Stable
↓
Investigar
Enter fullscreen mode Exit fullscreen mode

16. Quando utilizar Blue-Green?

O Blue-Green é recomendado quando:

  • É necessário validar a aplicação inteira antes da promoção;
  • A troca precisa ser rápida;
  • O rollback precisa ser simples;
  • A infraestrutura suporta temporariamente duas versões;
  • Não é necessário fazer uma liberação progressiva por percentual.

Exemplo:

Sistema corporativo crítico
Enter fullscreen mode Exit fullscreen mode

Fluxo:

Produção → BLUE v1

Nova versão → GREEN v2

Testes → GREEN v2

Aprovação → troca Active Service

Produção → GREEN v2
Enter fullscreen mode Exit fullscreen mode

Caso ocorra uma falha:

GREEN v2 → problema

↓

Retornar tráfego

↓

BLUE v1
Enter fullscreen mode Exit fullscreen mode

17. O que é Progressive Delivery?

Progressive Delivery é um conceito que evolui a ideia de Continuous Delivery.

Em um pipeline tradicional:

Code
 ↓
Build
 ↓
Test
 ↓
Deploy
 ↓
Produção
Enter fullscreen mode Exit fullscreen mode

No Progressive Delivery:

Code
 ↓
Build
 ↓
Test
 ↓
Deploy
 ↓
Pequena exposição
 ↓
Análise de métricas
 ↓
Aumentar exposição
 ↓
Nova análise
 ↓
Produção completa
Enter fullscreen mode Exit fullscreen mode

A diferença fundamental é que o deployment deixa de ser apenas uma ação técnica e passa a ser um processo controlado por feedback real do ambiente de produção.

O Argo Rollouts descreve Progressive Delivery justamente como uma liberação controlada e gradual, com exposição limitada da nova versão, observação contínua e promoção ou rollback com base na validação.

18. A importância da observabilidade

Canary e Blue-Green ficam muito mais eficientes quando combinados com observabilidade.

Uma arquitetura pode ser:

                    ┌───────────────┐
                    │   Kubernetes  │
                    └───────┬───────┘
                            │
                 ┌──────────┴──────────┐
                 │                     │
                 ▼                     ▼
           Stable v1              Canary v2
                 │                     │
                 └──────────┬──────────┘
                            │
                            ▼
                      Prometheus
                            │
                            ▼
                       Grafana
                            │
                            ▼
                    Argo Rollouts
                            │
                  ┌─────────┴─────────┐
                  │                   │
                Sucesso             Falha
                  │                   │
                  ▼                   ▼
              Promover             Rollback
Enter fullscreen mode Exit fullscreen mode

Métricas importantes incluem:

HTTP 5xx
Latency p95
Latency p99
CPU
Memory
Restarts
OOMKilled
Saturation
Request rate
Business KPIs
Enter fullscreen mode Exit fullscreen mode

A pergunta não deve ser apenas:

Os Pods estão rodando?

Mas também:

A nova versão está funcionando melhor ou pelo menos dentro dos limites aceitáveis?

Um Pod pode estar:

Running
Enter fullscreen mode Exit fullscreen mode

e ainda assim a aplicação pode estar apresentando:

Latência alta
Erros de negócio
Falhas de integração
Timeouts
Enter fullscreen mode Exit fullscreen mode

Por isso, readiness probes são importantes, mas não substituem análise mais profunda de métricas. Essa é uma das diferenças importantes entre o Rolling Update tradicional e soluções de progressive delivery.

19. Readiness Probe e estratégias de deploy

Independentemente da estratégia escolhida, a aplicação deve informar corretamente quando está pronta para receber tráfego.

Exemplo:

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080

  initialDelaySeconds: 10
  periodSeconds: 5
Enter fullscreen mode Exit fullscreen mode

Enquanto o Pod não estiver pronto:

Pod criado
   ↓
Aplicação iniciando
   ↓
Readiness = false
   ↓
Não recebe tráfego
   ↓
Aplicação pronta
   ↓
Readiness = true
   ↓
Pode receber tráfego
Enter fullscreen mode Exit fullscreen mode

Isso é fundamental especialmente em Rolling Updates.

Uma estratégia segura não depende apenas do controller de deployment. Ela depende também da qualidade da configuração da aplicação.

20. Exemplo de estratégia para diferentes níveis de criticidade

Aplicação de baixo risco 

Rolling Update
Enter fullscreen mode Exit fullscreen mode

Configuração:

maxSurge: 1
maxUnavailable: 0
Enter fullscreen mode Exit fullscreen mode

Aplicação de médio risco 

Rolling Update
+
Readiness Probe
+
Liveness Probe
+
Observabilidade
+
Rollback automático ou manual via pipeline
Enter fullscreen mode Exit fullscreen mode

Aplicação de alto risco 

Canary
+
Traffic Routing
+
Prometheus
+
Grafana
+
Alerting
+
Análise automática
+
Rollback automático
Enter fullscreen mode Exit fullscreen mode

Aplicação crítica com necessidade de reversão rápida 

Blue-Green
+
Preview Environment
+
Smoke Tests
+
Pre-Promotion Analysis
+
Post-Promotion Monitoring
Enter fullscreen mode Exit fullscreen mode

21. Arquitetura recomendada para Progressive Delivery

Uma arquitetura moderna pode utilizar:

Developer
    │
    ▼
Git Repository
    │
    ▼
CI Pipeline
    │
    ├── Testes
    ├── Lint
    ├── Security Scan
    └── Build Docker Image
    │
    ▼
Container Registry
    │
    ▼
GitOps Repository
    │
    ▼
Argo CD
    │
    ▼
Kubernetes
    │
    ▼
Argo Rollouts
    │
    ├── Canary
    │       │
    │       ▼
    │   Traffic Routing
    │       │
    │       ▼
    │   Métricas
    │       │
    │       ▼
    │   Promote/Rollback
    │
    └── Blue-Green
            │
            ▼
      Preview + Active
Enter fullscreen mode Exit fullscreen mode

Nesse modelo:

  • CI constrói e valida o software;
  • Container Registry armazena a imagem;
  • GitOps controla o estado desejado;
  • Argo CD sincroniza o cluster;
  • Argo Rollouts controla a estratégia de entrega;
  • Prometheus/Grafana fornecem observabilidade.

22. Conclusão

Não existe uma única estratégia de deployment ideal para todas as aplicações.

O Rolling Update é simples, eficiente e faz parte do Kubernetes. É uma ótima escolha para aplicações que podem coexistir entre versões e não precisam de um controle detalhado sobre a distribuição do tráfego.

O Blue-Green Deployment é especialmente útil quando é necessário preparar e validar completamente uma nova versão antes de realizar uma troca rápida do tráfego. Sua principal vantagem é a simplicidade de promoção e a possibilidade de reversão rápida, embora normalmente exija mais recursos de infraestrutura.

O Canary Deployment oferece o maior nível de controle sobre a exposição da nova versão. Ele permite liberar a aplicação progressivamente para uma parcela dos usuários, analisar métricas reais e interromper o rollout antes que uma falha atinja toda a base de usuários.

Podemos resumir as estratégias da seguinte maneira:

Rolling Update
→ Simplicidade e eficiência
→ Atualização gradual de Pods
→ Estratégia nativa do Kubernetes
Enter fullscreen mode Exit fullscreen mode 
Blue-Green
→ Validação completa antes da promoção
→ Troca rápida entre versões
→ Excelente para rollback rápido
Enter fullscreen mode Exit fullscreen mode 
Canary
→ Exposição gradual ao tráfego
→ Redução do blast radius
→ Métricas e análise progressiva
→ Ideal para ambientes críticos
Enter fullscreen mode Exit fullscreen mode

Para ambientes modernos de produção, especialmente aplicações de alto impacto, a evolução natural é sair de um modelo baseado apenas em:

Deploy → Torcer para funcionar
Enter fullscreen mode Exit fullscreen mode

para um modelo de Progressive Delivery:

Deploy
   ↓
Expor parcialmente
   ↓
Medir
   ↓
Validar
   ↓
Promover
ou
Rollback
Enter fullscreen mode Exit fullscreen mode

Dessa forma, o Kubernetes deixa de ser apenas uma plataforma para executar containers e passa a fazer parte de uma estratégia completa de entrega segura, automatizada, observável e resiliente.

Top comments (0)