Conceito e mecanismo
NotReady num nó exige observar condições, eventos, kubelet, runtime e comunicação com o plano de controlo. Uma falha localizada não justifica por si reinstalar o cluster inteiro. DiskPressure pode resultar de sistemas de ficheiros e armazenamento efémero saturados; identifica consumidores e mecanismos de recuperação antes de apagar diretórios do runtime. Logs e imagens têm ciclos de vida que precisam de gestão. A limpeza indiscriminada pode destruir dados e evidência. A mitigação deve recuperar margem e tratar a origem do crescimento para evitar repetição na próxima janela de negócio.
Aplicação guiada
kubectl top depende da Metrics API e de um pipeline funcional, frequentemente com metrics-server. A API principal responder não comprova que a API agregada de métricas esteja saudável. Static Pods são geridos pelo kubelet através de configuração local; os mirror Pods na API não são a fonte de controlo do manifest. Se um API server deixa de arrancar após uma edição, logs locais e estado do runtime podem continuar acessíveis. Para erros x509, identifica certificado, emissor, expiração e modelo de CA. kubeadm certs check-expiration ajuda a inventariar certificados geridos, mas renovação e recarga devem respeitar o contexto, incluindo CA externa.
O API server falha depois de uma alteração local. Com acesso autorizado ao nó, compara o manifest com a versão conhecida e consulta kubelet/runtime; não dependas exclusivamente de kubectl contra a API indisponível.
Armadilhas comuns
Apagar diretórios em uso; confundir API principal com Metrics API; corrigir só o mirror Pod; desativar TLS como solução para expiração.
Tópicos relacionados: Cluster, contexto e manutenção · Acesso, ferramentas e extensões
Mantém caminhos de diagnóstico locais e trata credenciais e armazenamento como dependências operacionais.
Referência: Troubleshoot clusters · CKA Kubernetes v1.35