
Curso Kubernetes 28 — DR e capstone: provar que o cluster volta
Um plano de DR não é um documento. É um procedimento que alguém já executou — com tempo medido.
Último capítulo do curso: cenários de desastre, o drill que prova o restore e o capstone para fechar tudo.
Selo do curso: validado com drill de restore em 85 segundos e failover de Postgres real.
O que é desastre
Nem todo incidente é desastre. A distinção importa porque a resposta muda:
| Cenário | Impacto | Resposta |
|---|---|---|
| Pod reinicia | nenhum (HA) | automático |
| Nó cai | carga redistribui | automático |
| Primário do banco cai | failover | automático + validação |
| Namespace apagado | serviço fora | restore de objetos |
| Cluster perdido | tudo fora | rebuild + restore |
| Região/zona perdida | tudo fora | DR site |
| Dados corrompidos | perda parcial | restore lógico com PITR |
Os três últimos exigem procedimento escrito. Os três primeiros, automação.
RPO e RTO por camada
| Camada | RPO | RTO | Mecanismo |
|---|---|---|---|
| etcd | 24h | 1–2h | snapshot agendado |
| Objetos do cluster | 24h | 1–4h | Velero |
| Postgres | minutos | 30–60 min | WAL + base backup |
| Dump lógico | 24h | 1h | pg_dump |
| Object storage | 24h | horas | replicação/backup |
| Configuração | 0 | minutos | Git |
Se o negócio exige RPO de 5 minutos e o backup é diário, o problema não é Kubernetes. É o desenho.
Quatro drills que valem a pena
1. Restore de namespace (Velero)
velero backup create drill-ns --include-namespaces portal --wait
velero restore create --from-backup drill-ns --namespace-mappings portal:drill
kubectl -n drill get all
Meça: tempo do restore, pods prontos, dados acessíveis.
2. Restore lógico do banco
pg_dump -Fc -h portal-postgres-rw -U portal -d portal -f /tmp/portal.dump
createdb -h portal-postgres-rw -U portal portal_drill
pg_restore -h portal-postgres-rw -U portal -d portal_drill /tmp/portal.dump
psql -h portal-postgres-rw -U portal -d portal_drill -c "select count(*) from tickets;"
Meça o tempo e compare as contagens com produção.
3. Snapshot e restore do etcd
Em ambiente descartável, restaure o snapshot e valide que a API responde com os objetos esperados. Em HA, o procedimento é cirúrgico — tenha runbook e ensaie.
4. Rebuild de um serviço do zero
Apague o Deployment e o Service, e reconstrua apenas com Git + Helm/GitOps:
kubectl -n drill delete deploy portal-backend
argocd app sync portal-drill
kubectl -n drill rollout status deploy/portal-backend
Se isso não funciona, seu "backup" de configuração é ilusório.
Runbook de DR: o que precisa estar escrito
- Quem decide declarar desastre e quem executa.
- Como acessar o cluster/console com credenciais que não estão no cluster.
- Ordem de recuperação: rede → storage → banco → apps → ingress.
- Comandos exatos, não "restaure o backup".
- Critério de validação por etapa.
- Comunicação para usuários e stakeholders.
- Como registrar o incidente e o tempo de cada etapa.
Regra: o runbook tem que ser executável por alguém cansado às 3h, sem o autor original disponível.
O que derruba o DR na prática
- Backup no mesmo storage do cluster.
- Credencial de restore só na cabeça de uma pessoa.
- Snapshot que nunca foi restaurado.
- DNS/TLS com validade curta não renovado no ambiente novo.
- Imagem fora do registry (build local).
- Secret que não foi incluído no backup.
- Runbook desatualizado após mudança de arquitetura.
Capstone
Objetivo: provar que você consegue perder e recuperar o ambiente.
Entregáveis:
- Inventário: aplicações, dependências, dados e donos.
- Matriz RPO/RTO por serviço, acordada com o negócio.
- Backups automatizados: etcd, Velero, banco, object storage.
- Drill executado com tempos medidos e evidência (logs, prints, contagens).
- Runbook de DR revisado por outra pessoa.
- Dashboard de SLO + painel de backups.
- Postmortem do drill: o que falhou no ensaio.
Critério de aceite: restaurar o ambiente em ambiente limpo, dentro do RTO declarado, com dados conferidos.
Roteiro do drill completo
# 1. Estado inicial
kubectl -n portal get pods,pvc
psql -h portal-postgres-rw -U portal -d portal -c "select count(*) from tickets;"
# 2. Backup
velero backup create capstone --include-namespaces portal --wait
pg_dump -Fc -h portal-postgres-rw -U portal -d portal -f /tmp/capstone.dump
# 3. Destruir (ambiente de teste)
kubectl delete namespace portal-drill --ignore-not-found
kubectl create namespace portal-drill
# 4. Restaurar
velero restore create --from-backup capstone --namespace-mappings portal:portal-drill
pg_restore -h portal-postgres-rw -U portal -d portal_drill /tmp/capstone.dump
# 5. Validar
kubectl -n portal-drill get pods
psql -h portal-postgres-rw -U portal -d portal_drill -c "select count(*) from tickets;"
Cronometre cada etapa. O número que entra no relatório é o tempo real, não o estimado.
Erros comuns
| Sintoma | Causa |
|---|---|
| Restore “ok” sem dados | backup parcial/exclusões |
| PVC não recriado | storageClass ausente no destino |
| App sobe e não conecta | secret/DNS não restaurado |
| RTO estourado | restore nunca medido |
| Backup corrompido | storage sem verificação |
| Runbook inútil | escrito por quem nunca executou |
| Drill esquecido | sem calendário e dono |
Checklist final do curso
- [ ] Cluster HA com etcd, VIP e PDBs.
- [ ] Workloads com probes, resources e HPA.
- [ ] Storage, banco, filas, cache e busca operados por operador.
- [ ] Backup por camada e restore testado.
- [ ] GitOps como fonte de verdade.
- [ ] CI/CD com imagem imutável, SBOM e assinatura.
- [ ] RBAC, PSA e NetworkPolicy aplicados.
- [ ] Capacidade medida com teste de carga.
- [ ] SLO, alertas por burn rate e on-call.
- [ ] DR com RPO/RTO e drill executado.
Glossário
- RPO: perda máxima de dados aceita.
- RTO: tempo máximo de recuperação.
- drill: ensaio de recuperação.
- PITR: point-in-time recovery.
- runbook: procedimento operacional.
- capstone: projeto final integrador.
Encerramento
Você começou com um cluster vazio e chega aqui com: HA, dados, observabilidade, GitOps, segurança, capacidade medida, SLO e um plano de recuperação testado.
O que separa um cluster que funciona de um cluster confiável não é a ferramenta. É ter procedimento, medir e ensaiar antes de precisar.
Volte ao índice do curso para revisar qualquer capítulo — e mantenha os drills no calendário. Confiabilidade é prática, não certificado.
Próximo: revisite o Capítulo 19 — Backup e restore e rode o drill de novo. Agora com cronômetro.
Continuar a ler
Leia também
KubernetesKubernetes de Verdade — do zero ao cluster em produção
Uma trilha prática para entender, montar e operar um cluster Kubernetes — do primeiro pod ao failover do Postgres.
4 min de leitura
KubernetesCurso Kubernetes 27 — SLO/SLI, on-call e postmortem blameless
O que prometer, como medir e o que fazer quando o erro estoura: SLI, SLO, error budget, alertas que acordam alguém e postmortem sem caça às bruxas.
4 min de leitura
KubernetesCurso Kubernetes 26 — Capacidade e carga: HPA, k6 e rate limit
Teste de carga que mede o que importa: p95, taxa de erro e o ponto exato em que o banco — não a CPU — vira o gargalo.
5 min de leitura
Comentários
Ainda sem comentários
Seja o primeiro a compartilhar sua opinião sobre este artigo.
Deixe um comentário