Fazer rollback de um deploy

Iniciante8 min de leiturakubernetes

Durante um incidente causado por deploy, a ordem certa é voltar primeiro, entender depois. Diagnóstico com o sistema saudável é mais rápido e não custa impacto ao usuário. Este guia é curto de propósito: você pode estar lendo às 3h.

1. Veja o histórico

kubectl rollout history deployment/loja -n prod
kubectl rollout history deployment/loja -n prod --revision=7   # o que tem nessa revisão

Se a coluna CHANGE-CAUSE estiver vazia, confirme a imagem em execução:

kubectl get deployment loja -n prod \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

2. Reverta

kubectl rollout undo deployment/loja -n prod                 # volta uma revisão
kubectl rollout undo deployment/loja -n prod --to-revision=7 # volta para uma específica

Se o rollout novo ainda estiver em andamento e travado, pause antes para estancar o avanço:

kubectl rollout pause deployment/loja -n prod

Em GitOps, não use kubectl: o controlador vai reconciliar de volta para o que está no Git em minutos. Reverta o commit no repositório de ambiente e deixe o Argo CD ou o Flux sincronizar. Se a urgência não permitir, desabilite a sincronização automática enquanto atua — e registre para religar depois.

3. Verifique que voltou mesmo

kubectl rollout status deployment/loja -n prod --timeout=5m
kubectl get pods -n prod -l app=loja                     # todos READY e sem restart novo
kubectl get deployment loja -n prod \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

E confirme pelo sintoma, não pelo estado do cluster: a taxa de erro e a latência precisam voltar ao normal no painel. Rollout concluído com o serviço ainda quebrado significa que a causa não era o deploy.

4. Congele o pipeline antes de investigar

Sem isso, o próximo merge republica a versão com defeito.

# desabilite o workflow de deploy enquanto investiga
gh workflow disable deploy.yml

Avise no canal do incidente: qual revisão está no ar, que o pipeline está congelado e quem está investigando.

5. Depois: transforme em aprendizado

Com o serviço estável, responda no postmortem: por que a verificação automática não pegou? O canário existia? Quanto tempo entre o deploy e a detecção? A reversão foi rápida o suficiente?

Rollback que vira rotina sem investigação é um sistema que aprendeu a conviver com defeito.

Se der errado

Sintoma	O que fazer
`no rollout history found`	O `revisionHistoryLimit` apagou; faça `set image` com a tag/digest anterior
Reverteu e o problema continua	A causa não era o deploy: veja configuração, dependência, dado
Volta sozinho para a versão ruim	GitOps reconciliando — reverta no Git
Pods antigos não morrem	`PodDisruptionBudget` bloqueando, ou finalizer preso
Reversão quebra pior	Incompatibilidade de esquema: avance com correção em vez de voltar

Checklist de pronto

Impacto no usuário normalizado, confirmado por métrica.
Revisão em execução conferida pela imagem.
Pipeline congelado.
Incidente comunicado com o estado atual.
Postmortem agendado com dono.