APRENDER. PRATICAR. EVOLUIR.Começar por uma referência funcional
O laboratório executa uma API sintética que escuta em 8080 e responde com o identificador dr-synthetic-ledger. Um Pod cliente faz pedidos HTTP com timeout; ambos pertencem a um namespace descartável. Antes de provocar falhas, o guião confirma a resposta pelo IP do Pod, a condição Ready e o contador de reinícios. Esta referência permite distinguir uma falha introduzida de um ambiente que nunca funcionou. Regista também a versão efetiva do servidor e do cliente. A experiência usa um único node local: o resultado não demonstra disponibilidade entre nodes, comportamento de um load balancer externo ou capacidade para a carga de um serviço bancário.
DNS correto com selector errado
O Service ledger começa com selector app=wrong, enquanto o Deployment produz Pods com app=ledger. O nome ledger resolve para o ClusterIP atribuído ao Service, mas a lista de destinos está vazia e o pedido falha. O Pod da API permanece pronto. Estes factos são compatíveis: a existência do registo DNS do Service normal não exige um backend funcional. Compara o selector com os labels dos Pods no mesmo namespace. Não alteres CoreDNS apenas porque o utilizador descreve o sintoma como um problema de nome. Neste ensaio, a correção do selector é seguida pela criação de um destino pronto e por um pedido HTTP bem-sucedido.
Observar a convergência
Uma alteração aceite pela API e uma configuração já aplicada ao tráfego são observações diferentes. O guião espera pelo destino pronto no EndpointSlice e só depois insiste, com limite, no pedido HTTP. O controlador e o encaminhamento não têm de mudar no mesmo instante da resposta do comando patch. Define um prazo operacional e observa as transições sem declarar falha ao primeiro estado intermédio. Em produção, preserva o momento da alteração, o estado relevante e o resultado visto pelo consumidor. Se o prazo terminar, investiga o ponto onde a convergência parou. Não prolongues indefinidamente uma espera que esconde falta de progresso.
Destino pronto com porta errada
A segunda falha mantém o selector correto e altera targetPort para 9090. O EndpointSlice continua a indicar um destino pronto, agora com essa porta. A aplicação continua a escutar em 8080; o pedido direto a IP:8080 funciona e o pedido ao Service falha. O estado pronto resulta da probe configurada, não de um teste de todas as portas publicadas pelo Service. Compara o listener efetivo, a porta do Service e a porta resolvida do destino. O ensaio recupera quando targetPort volta ao nome http, associado a containerPort 8080. Declarar containerPort não inicia um listener por si só; aqui o processo Python é quem o abre.
Comparar caminhos sem exagerar a conclusão
Um pedido direto bem-sucedido ao Pod reduz a probabilidade de a aplicação estar completamente indisponível naquele instante. Não prova que todos os consumidores conseguem chegar ao Service, nem testa Ingress, TLS, autenticação ou uma transação de negócio. O cliente e a API deste ensaio estão no mesmo cluster local e usam HTTP simples. Ao transferir o método para um incidente, identifica a origem do pedido, protocolo, nome, porta e resultado esperado. Dois testes executados de origens diferentes podem ter políticas ou rotas diferentes. A equipa deve conservar estas condições no registo do incidente para que a comparação seja interpretável e repetível.
Entregar evidência útil à equipa seguinte
Num caso fictício de suporte a processamento de fundos, o responsável funcional precisa de saber se o canal usado pelo batch voltou a funcionar. Um resumo útil distingue nome resolvido, destinos selecionados, porta observada e resposta da aplicação. Acrescenta a alteração efetuada, o resultado depois da mudança e o que falta validar. O laboratório termina os recursos que criou no namespace; não opera sobre contextos pessoais ou ambientes externos. Esta disciplina permite reproduzir o diagnóstico e delimitar o impacto. O pedido sintético é um critério técnico pequeno, que deve ser complementado por uma operação funcional representativa antes de fechar um incidente real.
# Use an explicitly authorized context and namespace.
kubectl --context OWNED -n LAB get service ledger -o yaml
kubectl --context OWNED -n LAB get pods -l app=ledger --show-labels
kubectl --context OWNED -n LAB get endpointslices \
-l kubernetes.io/service-name=ledger -o yaml
# Compare Service port, resolved target port, Pod readiness and a bounded request.O DNS devolveu o ClusterIP apesar de o selector errado produzir zero destinos; corrigir o selector recuperou o pedido pelo Service.
Armadilhas comuns
Resolver o nome como prova de saúde; endpoint pronto como prova de porta correta; chamada direta ao Pod como validação de todo o percurso.
Tópicos relacionados: Tráfego e probes · Operação e recuperação
Uma comparação controlada entre caminhos reduz hipóteses; a recuperação exige repetir o pedido através do caminho usado pelo consumidor.
Referência: Debug Services · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed