0%
Deployments Avançados no Kubernetes: Estratégias e Boas Práticas

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.

I

InSkillCoach

· min

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.

InSkillCoach

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+
1.6k
196

Comentários

Os comentários são alimentados pelo GitHub Discussions

Conecte-se com o GitHub para participar da discussão

Link copiado!