Deployments Avançados no Kubernetes: Estratégias e Boas Práticas
Explore as estratégias de deployment avançadas no Kubernetes, as atualizações progressivas e os rollbacks, além das melhores práticas para deployments robustos.
InSkillCoach
Estratégias de Deployment no Kubernetes
Os Deployments do Kubernetes oferecem diferentes estratégias para atualizar suas aplicações. Escolher a estratégia certa é crucial para minimizar interrupções de serviço e garantir uma transição tranquila.
Estratégia de Substituição (Recreate)
A estratégia de substituição encerra todas as instâncias da versão antiga antes de iniciar as novas. É a estratégia padrão.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
replicas: 3
strategy:
type: Recreate
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:1.0
Vantagens:
- Simples de entender e de depurar
- Garante que apenas uma versão esteja em execução por vez
Desvantagens:
- Tempo de indisponibilidade durante o deployment
- Sem rollback automático em caso de falha
Casos de uso:
- Aplicações que não suportam várias versões simultâneas
- Ambientes de desenvolvimento ou de teste
- Aplicações com dependências críticas de banco de dados
Estratégia de Rolling Update (RollingUpdate)
A estratégia de atualização progressiva substitui gradualmente as instâncias antigas por novas, mantendo um número mínimo de instâncias disponíveis.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Número máximo de pods adicionais permitidos
maxUnavailable: 0 # Número máximo de pods indisponíveis durante a atualização
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:1.0
Vantagens:
- Sem tempo de indisponibilidade
- Rollback automático em caso de falha
- Controle preciso sobre o processo de atualização
Desvantagens:
- Mais complexa de configurar
- Pode exigir mais recursos durante a atualização
Casos de uso:
- Aplicações em produção
- Serviços que exigem alta disponibilidade
- Aplicações que suportam várias versões simultâneas
Estratégia de Blue/Green Deployment
Embora o Kubernetes não ofereça nativamente o deployment blue/green, você pode implementá-lo usando Services e Deployments.
# Deployment "Blue" (versão atual)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: blue
template:
metadata:
labels:
app: myapp
version: blue
spec:
containers:
- name: myapp
image: myapp:1.0
---
# Deployment "Green" (nova versão)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
version: green
template:
metadata:
labels:
app: myapp
version: green
spec:
containers:
- name: myapp
image: myapp:1.1
---
# Service que aponta para a versão ativa
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
version: blue # Altere para "green" para alternar para a nova versão
ports:
- port: 80
targetPort: 8080
Vantagens:
- Troca instantânea entre as versões
- Sem degradação do serviço durante a atualização
- Rollback simples, bastando alterar o seletor do Service
Desvantagens:
- Exige o dobro de recursos durante o deployment
- Configuração mais complexa
- Exige gerenciamento manual ou um script para a troca
Casos de uso:
- Aplicações críticas com janelas de manutenção rígidas
- Serviços que exigem uma troca rápida em caso de problema
- Aplicações com dependências complexas entre versões
Estratégia de Canary Deployment
Um deployment canary expõe uma pequena parte do tráfego à nova versão antes de fazer o deployment completo.
# Deployment principal (versão atual)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-main
spec:
replicas: 9
selector:
matchLabels:
app: myapp
version: main
template:
metadata:
labels:
app: myapp
version: main
spec:
containers:
- name: myapp
image: myapp:1.0
---
# Deployment canary (nova versão)
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-canary
spec:
replicas: 1
selector:
matchLabels:
app: myapp
version: canary
template:
metadata:
labels:
app: myapp
version: canary
spec:
containers:
- name: myapp
image: myapp:1.1
---
# Service que distribui o tráfego
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
ports:
- port: 80
targetPort: 8080
Vantagens:
- Teste em produção com risco mínimo
- Detecção precoce de problemas
- Possibilidade de coletar métricas antes do deployment completo
Desvantagens:
- Configuração mais complexa
- Exige monitoramento atento durante a fase canary
- Pode exigir ferramentas adicionais para o roteamento do tráfego
Casos de uso:
- Aplicações com um grande número de usuários
- Serviços que exigem validação em produção
- Deployments de alto risco
Gerenciamento de Rollbacks
Os rollbacks são essenciais para manter a disponibilidade da sua aplicação em caso de problema com uma nova versão.
Rollback Automático com Health Checks
Configure probes de saúde (liveness e readiness) para que o Kubernetes possa detectar automaticamente os problemas e realizar um rollback.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:1.0
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Rollback Manual com kubectl
Você pode realizar um rollback manual para uma versão anterior usando o comando kubectl rollout undo:
# Rollback para a versão anterior
kubectl rollout undo deployment/app-deployment
# Rollback para uma versão específica
kubectl rollout undo deployment/app-deployment --to-revision=2
Boas Práticas para Deployments
1. Use Tags de Imagem Específicas
Evite usar latest como tag de imagem, pois isso dificulta o acompanhamento das versões e pode levar a deployments não reproduzíveis.
# Evitar
image: myapp:latest
# Recomendado
image: myapp:1.0.2
2. Defina Limites de Recursos
Especifique os limites de recursos para evitar que um pod consuma recursos demais e afete os outros pods.
spec:
containers:
- name: myapp
image: myapp:1.0
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
3. Use Regras de Anti-Affinity
Distribua os pods em diferentes nós para melhorar a disponibilidade.
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- myapp
topologyKey: kubernetes.io/hostname
4. Implemente Estratégias de Escalabilidade
Configure o autoscaling horizontal (HPA) para ajustar automaticamente o número de réplicas de acordo com a carga.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: app-deployment
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
5. Use ConfigMaps e Secrets
Separe a configuração da aplicação do código para facilitar as alterações sem precisar reconstruir a imagem.
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
APP_ENV: production
LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
DB_PASSWORD: base64encodedpassword
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
spec:
template:
spec:
containers:
- name: myapp
image: myapp:1.0
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: app-secrets
Exemplo de Deployment Completo
Aqui está um exemplo completo de um Deployment do Kubernetes com as melhores práticas:
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
labels:
app: myapp
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:1.0.2
ports:
- containerPort: 8080
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: app-secrets
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- myapp
topologyKey: kubernetes.io/hostname
---
apiVersion: v1
kind: Service
metadata:
name: app-service
spec:
selector:
app: myapp
ports:
- port: 80
targetPort: 8080
type: LoadBalancer
Conclusão
Os deployments avançados no Kubernetes oferecem grande flexibilidade para gerenciar as atualizações das suas aplicações. Escolhendo a estratégia de deployment certa e seguindo as melhores práticas, você pode garantir uma transição tranquila entre as versões, mantendo a disponibilidade do seu serviço.
No próximo artigo, vamos explorar o gerenciamento de secrets e configurações no Kubernetes, um aspecto crucial para proteger suas aplicações.
Sobre InSkillCoach
Especialista em treinamento e tecnologias
Coach especializado em tecnologias avançadas e IA, apoiado pela GNeurone Inc.
Certificações:
- AWS Certified Solutions Architect – Professional
- Certificações Google Cloud
- Microsoft Certified: DevOps Engineer Expert
- Certified Kubernetes Administrator (CKA)
- CompTIA Security+
Comentários
Os comentários são alimentados pelo GitHub Discussions
Conecte-se com o GitHub para participar da discussão