O que são Deployments e ReplicaSets, e como funcionam rolling updates e rollbacks?

Question

IT Interview Practice · Accepted Answer

Um **Deployment** é o controller padrão para rodar apps stateless. Ele gerencia **ReplicaSets**, e um ReplicaSet mantém um número especificado de Pods idênticos rodando. Você edita o Deployment; ele orquestra **rolling updates** e **rollbacks** para você.

## A hierarquia

```text
Deployment  → declara o desired state + a estratégia de update (o que VOCÊ gerencia)
   └── ReplicaSet  → garante que N Pods idênticos existam (um por versão do app)
          └── Pod  → Pod → Pod ...  (as cópias realmente em execução)

A cada nova versão, o Deployment cria um NOVO ReplicaSet e migra os Pods para ele.
```

## Um manifest de Deployment

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels: { app: web }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # no máximo 1 Pod fora do ar durante o update
      maxSurge: 1            # no máximo 1 Pod extra acima da contagem desejada
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: myapp:1.0
          ports:
            - containerPort: 8080
```

## Rolling update: mudança de versão com zero downtime

```bash
kubectl set image deployment/web web=myapp:2.0   # dispara um rolling update
kubectl rollout status deployment/web            # acompanha o progresso
```

```text
maxSurge=1, maxUnavailable=1, replicas=4:
  v1: ████        (início: 4 Pods antigos)
      █████       sobe 1 novo (v2), agora 5 no total (surge)
      ███ █       os antigos caem para 3, o novo está Ready
      ...migra gradualmente...
  v2: ████        (fim: 4 Pods novos, ReplicaSet antigo escalado para 0)
O tráfego só vai para Pods que passam no readiness probe → sem downtime.
```

## Rollback quando um release dá errado

```bash
kubectl rollout history deployment/web       # lista as revisions
kubectl rollout undo deployment/web          # volta para a revision anterior
kubectl rollout undo deployment/web --to-revision=3
```

Como o ReplicaSet antigo é mantido (escalado para 0), um rollback é rápido: o Kubernetes apenas escala o ReplicaSet anterior de volta para cima e o novo para baixo.

## Scaling

```bash
kubectl scale deployment/web --replicas=10   # muda a contagem desejada
```

## Por que isso importa

Os Deployments são o "cavalo de batalha" para rodar aplicações stateless no Kubernetes, então entendê-los e à sua relação com os ReplicaSets é conhecimento essencial e do dia a dia. A estratificação é o insight-chave: você gerencia um **Deployment**, que possui **ReplicaSets** (um por versão), e cada ReplicaSet garante que um número especificado de Pods idênticos esteja rodando — uma cadeia de reconciliation loops que, juntos, entregam self-healing e uma contagem de replicas estável. O poder real está em como o Deployment lida com a mudança: um **rolling update** cria um novo ReplicaSet e migra os Pods do antigo para o novo gradualmente, regido por `maxSurge` e `maxUnavailable`, de modo que a capacidade seja preservada e — combinado com readiness probes que decidem quais Pods recebem tráfego — o release acontece com **zero downtime**. Como o ReplicaSet anterior é retido (escalado para zero em vez de deletado), um **rollback** é rápido e seguro: `kubectl rollout undo` simplesmente escala a versão antiga de volta para cima e a ruim para baixo, que é exatamente o que você usa quando um release se comporta mal. Entender essas mecânicas — mais como escalar (`kubectl scale`) e inspecionar o progresso (`kubectl rollout status/history`) — é fundamental para entregar software com segurança no Kubernetes, e reflete o modelo declarativo, orientado a controllers, que define como a plataforma opera em produção.

A hierarquia

Um manifest de Deployment

Rolling update: mudança de versão com zero downtime

Rollback quando um release dá errado

Scaling

Por que isso importa

Perguntas relacionadas