APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Startup, liveness e readiness respondem a perguntas diferentes. A startup probe dá tempo ao arranque; liveness pode provocar restart de um container que deixou de funcionar; readiness controla aptidão para tráfego. Uma dependência remota lenta não é automaticamente motivo para reiniciar um processo local saudável. Se todas as réplicas usam essa dependência na liveness, podem reiniciar em conjunto e agravar o incidente. Desenha verificações para o contrato do serviço e avalia se existe um modo degradado útil.
Aplicação guiada
Começa por estado e eventos, depois lê logs do container e execução relevantes. --previous pode recuperar saída da instância anterior quando disponível. kubectl top depende do pipeline de métricas; a sua falha não prova que a API principal esteja indisponível. Em Pending com insufficient memory, compara requests e capacidade comprometida nos nós elegíveis. Na manutenção de manifests, consulta versões servidas e migrações de schema: mudar só apiVersion pode deixar campos incompatíveis. Regista observações e a hipótese que cada ação procura confirmar, para que a passagem entre equipas preserve o raciocínio.
Se o evento indica FailedScheduling, investiga colocação antes de probes. Se o container reiniciou, consulta logs anteriores antes de perder evidência num novo rollout.
Armadilhas comuns
Usar restart como diagnóstico universal; interpretar ausência de métricas como consumo zero; confundir autenticação com API removida.
Tópicos relacionados: Configuração, segredos e identidade · Recursos, segurança e extensões
A próxima ação deve reduzir uma incerteza concreta sobre a falha.
Referência: Container probes · CKAD Kubernetes v1.37