O Deployment é um dos objetos mais fundamentais do Kubernetes, sendo o principal responsável por implementar a capacidade de escalonamento horizontal (scaling out/in). Desde o surgimento das plataformas como serviço (PaaS), a capacidade de gerenciar o número de instâncias de uma aplicação de forma declarativa tornou-se um requisito essencial para sistemas de orquestração.

Sempre que ocorre uma alteração no PodTemplate de um Deployment (como a atualização da versão de uma imagem), o Kubernetes inicia um processo de Rolling Update (atuallização progressiva). Para realizar essa tarefa, o Deployment utiliza um objeto intermediário chamado ReplicaSet.

O Papel do ReplicaSet

Um ReplicaSet define o número desejado de réplicas de um Pod e o template que deve ser seguido para criá-los. Na hierarquia do Kubernetes, o Deployment não gerencia os Pods diretamente; em vez disso, ele manipula múltiplos ReplicaSets para representar diferentes versões da aplicação.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-server-rs
  labels:
    tier: frontend
spec:
  replicas: 4
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: main-container
        image: httpd:2.4-alpine

Lógica de Atualização Progressiva (Rolling Update)

A estratégia de Rolling Update garante que a aplicação permaneça disponível enquanto novas versões são implantadas. Em vez de interromper todo o serviço, o controlador substitui gradualmente os Pods antigos pelos novos. Para evitar que o serviço fique instável, é recomendável utilizar mecanismos de Health Check (Liveness e Readiness Probes), garantindo que o tráfego só seja direcionado a Pods que estejam realmente prontos.

O comportamento dessa atualização é controlado por dois parâmetros principais no campo strategy:

• maxSurge: Define quantos Pods podem ser criados acima do número desejado (DESIRED) durante a atualização.
• maxUnavailable: Define o limite máximo de Pods que podem ficar indisponíveis durente o processo de transição.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 0

No exemplo acima, o controlador garante que nenhum Pod antigo seja removido antes que novos Pods estejam prontos (devido ao maxUnavailable: 0), permitindo um excedente temporário de até 2 instâncias.

Gerenciamento de Versões e Rollbacks

Uma das grandes vantagens de utilizar ReplicaSets para gerenciar versões é a facilidade de reverter alterações. Quando uma atualização falha ou apresenta bugs, o Kubernetes permite retornar ao estado anterior rapidamente.

Para desfazer a última alteração e voltar para a versão estável anterior, utiliza-se o comando:

kubectl rollout undo deployment/web-server-deployment

Caso seja necessário retornar a um ponto específico no tempo, é possível consultar o histórico de revisões mantido pelo Deployment:

kubectl rollout history deployment/web-server-deployment

Para inspecionar os detalhes de uma revisão específica (por exemplo, a revisão 2) e realizar o rollback direcionado:

kubectl rollout history deployment/web-server-deployment --revision=2
kubectl rollout undo deployment/web-server-deployment --to-revision=2

Estratégias Avançadas: Canary e Blue-Green

Embora o Rolling Update seja o padrão, outras estratégias são comuns no ecossistema Cloud-Native:

• Canary Deployment: Consiste em liberar a nova versão para um pequeno grupo de usuários ou uma parcela mínima de instâncias. Se nenhum erro for detectado, a atualização prossegue para o restante da infraestrutura.
• Blue-Green Deployment: Mantém dois ambientes idênticos. O ambiente "Blue" (Azul) roda a versão atual, enquanto o "Green" (Verde) recebe a nova versão. Após a validação total no ambiente Green, o tráfego do Load Balancer é virado integralmente para ele.