titulo: "Estratégias de Deploy no Kubernetes: Rolling, Blue-Green e Canary" descricao: "Entenda as diferentes estratégias de deployment no Kubernetes, suas vantagens, desvantagens e quando utilizar cada uma em produção." data: "2025-12-02" autor: "Rany" tags: ["Kubernetes", "DevOps", "CI/CD", "Deploy"] tempoLeitura: "8 min"
Introdução
Uma das decisões mais importantes ao trabalhar com Kubernetes é escolher a estratégia de deployment adequada. Neste artigo, vamos explorar três das estratégias mais populares e quando utilizar cada uma.
Rolling Update (Atualização Gradual)
A estratégia de Rolling Update é a padrão do Kubernetes. Ela substitui gradualmente as versões antigas dos pods pela nova versão.
Como Funciona
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:v2.0
ports:
- containerPort: 8080
Parâmetros Importantes
- maxUnavailable: Número máximo de pods que podem estar indisponíveis durante a atualização
- maxSurge: Número máximo de pods que podem ser criados acima do número desejado
Vantagens
✅ Zero downtime em caso de sucesso ✅ Rollback automático em caso de falha ✅ Uso eficiente de recursos ✅ É a estratégia padrão do Kubernetes
Desvantagens
❌ Período de transição com duas versões rodando simultaneamente ❌ Pode causar problemas se houver incompatibilidade entre versões
Blue-Green Deployment
O Blue-Green Deployment mantém dois ambientes idênticos: um ativo (Blue) e outro preparado (Green).
Como Implementar
# Deployment Green (nova versão)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
spec:
replicas: 5
selector:
matchLabels:
app: myapp
version: green
template:
metadata:
labels:
app: myapp
version: green
spec:
containers:
- name: myapp
image: myapp:v2.0
ports:
- containerPort: 8080
---
# Service que pode alternar entre Blue e Green
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
version: green # Altere para 'blue' para fazer rollback
ports:
- protocol: TCP
port: 80
targetPort: 8080
Processo de Deploy
- Deploy da nova versão (Green) em paralelo
- Teste a nova versão
- Alterne o tráfego do Blue para o Green
- Mantenha o Blue por segurança
- Remova o Blue após confirmar estabilidade
Vantagens
✅ Rollback instantâneo (apenas mude o selector do Service) ✅ Testes completos antes de direcionar tráfego ✅ Zero downtime ✅ Uma única versão ativa por vez
Desvantagens
❌ Requer o dobro de recursos durante o deploy ❌ Complexidade adicional na orquestração ❌ Possíveis problemas com bancos de dados e migrações
Canary Deployment
O Canary Deployment libera a nova versão gradualmente para uma pequena porcentagem de usuários antes do rollout completo.
Implementação com Istio
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: app-virtualservice
spec:
hosts:
- myapp.example.com
http:
- match:
- headers:
user-type:
exact: beta-tester
route:
- destination:
host: app-service
subset: v2
- route:
- destination:
host: app-service
subset: v1
weight: 90
- destination:
host: app-service
subset: v2
weight: 10
Processo Gradual
# Fase 1: 10% de tráfego para v2
kubectl apply -f canary-10.yaml
# Monitore métricas por algumas horas
kubectl top pods
kubectl logs -l version=v2
# Fase 2: 50% de tráfego
kubectl apply -f canary-50.yaml
# Fase 3: 100% de tráfego
kubectl apply -f canary-100.yaml
Vantagens
✅ Reduz risco de impacto em toda a base de usuários ✅ Permite testes em produção com tráfego real ✅ Detecção precoce de problemas ✅ Rollback afeta apenas pequena porcentagem
Desvantagens
❌ Requer service mesh (Istio, Linkerd) ou ferramentas adicionais ❌ Monitoramento e observabilidade robustos são essenciais ❌ Complexidade na configuração ❌ Dificuldade em controlar qual usuário recebe qual versão
Comparação das Estratégias
| Critério | Rolling | Blue-Green | Canary | |----------|---------|------------|--------| | Complexidade | Baixa | Média | Alta | | Recursos necessários | Baixo | Alto | Médio | | Velocidade de rollback | Média | Instantânea | Rápida | | Risco | Médio | Baixo | Muito Baixo | | Ferramentas extras | Não | Não | Sim (Istio/Linkerd) |
Quando Usar Cada Estratégia
Use Rolling Update quando:
- Você tem recursos limitados
- A aplicação tolera pequenos períodos de inconsistência
- Quer simplicidade e a solução nativa do Kubernetes
Use Blue-Green quando:
- Precisa de rollback instantâneo
- Pode arcar com recursos duplicados
- Quer testes completos antes de liberar
- Tem aplicações críticas que não podem ter inconsistências
Use Canary quando:
- Quer minimizar riscos ao máximo
- Tem infraestrutura e observabilidade robustas
- Pode investir em ferramentas de service mesh
- Quer validação em produção com tráfego real
Monitoramento é Essencial
Independente da estratégia escolhida, você PRECISA de:
# Exemplo de Health Checks
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
E ferramentas de observabilidade:
- Prometheus para métricas
- Grafana para visualização
- Jaeger para tracing
- ELK Stack para logs
Conclusão
Não existe uma "melhor" estratégia de deployment. A escolha depende de:
- Requisitos de disponibilidade
- Recursos disponíveis
- Complexidade aceitável
- Maturidade da equipe
- Criticidade da aplicação
Para a maioria dos casos, Rolling Update é suficiente. Para aplicações críticas com requisitos rigorosos de disponibilidade, considere Blue-Green ou Canary.
O importante é entender as opções e escolher conscientemente com base nas necessidades do seu negócio.
Dúvidas? Experimente cada estratégia em um cluster de desenvolvimento antes de implementar em produção!