Postmortem — O deploy que passou no build e morreu no cluster

Nem todo incidente começa com um apagão. Este começou com um deploy “verde” no build e um rollout que nunca terminou.

Resumo

O pipeline construiu a imagem nova, importou nos nós e atualizou o Deployment. Os pods novos entraram em CrashLoopBackOff. Os pods antigos continuaram servindo, então o site não caiu — mas o deploy ficou pela metade por 40 minutos, até o timeout do Jenkins.

Causa: o secret do cluster tinha APP_STORAGE_S3_ACCESSKEY/SECRETKEY = minioadmin. A imagem nova incluía o guard ProdDefaultCredentialsGuard, que recusa credenciais default no profile prod. A imagem antiga não tinha o guard (ou havia arrancado antes da mudança).

Pior: a imagem nova já tinha aplicado a migration Flyway 3.5. Voltar para a imagem antiga passou a falhar na validação do Flyway. O caminho era fix forward.

Linha do tempo

Hora	Evento
T+0	Pipeline inicia; build e import de imagens nos 3 workers
T+40 min	Rollout do backend atinge timeout de 900 s
T+41 min	Pods novos em CrashLoopBackOff; pods antigos 2/2 servindo
T+45 min	Logs mostram INF-SEC-01 (S3 default)
T+50 min	Tentativa de rollback falha: Flyway 3.5 aplicada
T+55 min	Criado usuário MinIO dedicado; secret atualizado
T+60 min	Imagem nova promovida; rollout conclui
T+65 min	Validação: readiness UP, /api/fornecedores 200, CNPG healthy

Causa raiz

1. Drift de configuração. O secret do cluster tinha credenciais default do MinIO (minioadmin), enquanto a aplicação já tinha um guard que as rejeita em produção.
2. Build não valida runtime. O build passou; o guard só roda no arranque.
3. Rollout sem preflight de credenciais. O pipeline não checou o secret antes de trocar a imagem.
4. Migration aplicada antes do guard. O Flyway rodou, aplicou 3.5 e só depois o guard derrubou o processo. Isso tornou o rollback inviável.

O que funcionou

• Pods antigos continuaram servindo durante o rollout (estratégia RollingUpdate).
• O guard fez o trabalho dele: recusou credencial default em produção.
• Os logs apontaram a causa em uma linha.
• O fix forward foi possível sem perda de dados.

O que não funcionou

• O pipeline não tinha preflight de credenciais.
• O rollback foi tentado antes de perceber a migration aplicada.
• O alerta de deploy não diferenciou “build ok” de “rollout ok”.
• A credencial default estava no cluster há meses, sem rotação.

Correção

1. Criar um usuário MinIO dedicado (não-default) com policy de leitura/escrita.
2. Atualizar o secret portal-secrets com o novo access/secret.
3. Promover a imagem nova (fix forward).
4. Validar readiness, endpoint crítico e banco.

O passo a passo está no runbook docs/RUNBOOK-K8S-DEPLOY-INF-SEC-01.md do repositório.

Lições

1. Credencial default é dívida técnica com juros. Rotacione antes de o guard te obrigar.
2. Preflight no pipeline: falhe antes do build se o secret tiver valor default.
3. Migration é forward-only. Se a imagem nova aplicou migração, rollback de imagem não é seguro.
4. Rollout precisa de timeout e alerta. 40 minutos é tempo demais para descobrir um CrashLoop.
5. Build verde não é deploy verde. Valide readiness e um endpoint de negócio, não só o /health.
6. Tenha um runbook de fix forward. O caminho de volta pode não existir.

Checklist para o seu pipeline

• [ ] O pipeline valida credenciais/segredos antes de trocar a imagem.
• [ ] O rollout tem timeout e alerta.
• [ ] A validação pós-deploy inclui um endpoint de negócio.
• [ ] Sei se a imagem aplica migrations.
• [ ] Tenho plano de fix forward e rollback de dados.
• [ ] Credenciais default estão rotacionadas.

Próximo

No capítulo 09 vamos expor a aplicação com Services, Ingress, DNS e TLS — e entender por que o caminho real de tráfego importa até no teste de carga.

Próximo: Curso Kubernetes 09 — Services, Ingress, DNS e TLS (em breve). Enquanto isso, volte ao índice do curso.