APRENDER. PRATICAR. EVOLUIR.Começar pelo contrato afetado
Uma API de fundos pode ter todos os Pods Running e continuar a falhar para o cliente. Define primeiro a operação afetada, o cliente de origem, o destino e a janela temporal. Separa quatro perguntas: o processo iniciou, o Pod está pronto, o Service aponta para o destino correto e a operação de negócio termina com o resultado esperado? Guarda contexto, namespace, revisão e evidências antes de alterar a configuração. Num incidente com operações financeiras, uma resposta técnica positiva não dispensa verificar resultados e duplicados. As observações desta aula são fictícias; os comandos são propostas de leitura para um laboratório autorizado, não registos de execução num cluster.
Da porta pública ao listener
No exemplo, o cliente usa 443 e o processo escuta em 8443. Um targetPort=8080 deixa um destino errado mesmo que o Service tenha um endereço e o Pod esteja pronto. Compara o contrato do cliente, a configuração do Service, portas nas EndpointSlices e a escuta observada no processo. O campo containerPort não cria um listener. Durante uma migração, targetPort com nome api permite que versões distintas declarem números diferentes. A ferramenta de diagnóstico deve conservar a associação de cada slice às suas portas; escolher apenas o primeiro número perde informação. A conclusão exige um pedido pelo caminho do cliente após a correção.
Ler condições sem confundir presença e prontidão
Um IP presente não é uma confirmação de saúde. No fixture normal, publishNotReadyAddresses=false e um Pod que não termina tem ready=false: o endereço pode continuar representado, mas não é um backend pronto para seleção normal. Outra captura mostra serving=true, terminating=true e ready=false durante encerramento. Essa combinação não prova corrupção; separa capacidade de servir de fase do ciclo de vida. Não deduzas o destino de todas as ligações existentes apenas dessas condições. Com publishNotReadyAddresses=true, ready no slice deixa de servir como prova da prontidão do Pod. Verifica a opção do Service e a semântica do consumidor antes de alimentar um dashboard de disponibilidade.
Probes com objetivos diferentes
Startup dá espaço à inicialização antes de executar readiness e liveness. Depois, readiness responde à capacidade de aceitar trabalho; liveness trata situações em que reiniciar o processo pode ajudar. Numa aplicação que aquece durante 95 segundos, define margem com medições representativas e mantém deteção adequada em regime normal. Não uses a prontidão como suposto bloqueio automático de liveness. Se ambas consultam uma base externa, uma falha dessa base pode provocar reinícios que não a reparam e repetem trabalho pesado. Revê o contrato, limites de falhas e recuperação gradual. Uma configuração proposta só ganha evidência operacional depois de ensaios de arranque, sobrecarga e falha de dependência.
PVC Pending: consumidor e topologia
Com WaitForFirstConsumer, uma claim sem consumidor pode aguardar legitimamente. Quando o consumidor existe, lê a configuração e eventos de Pod, PVC e StorageClass em conjunto. nodeName evita o scheduler; nodeSelector mantém restrições de colocação sem saltar a sua decisão. No caso proposto, trocar um pelo outro é necessário mas insuficiente: a zona pedida continua incompatível com o armazenamento permitido. Compara os conjuntos e justifica uma alteração aprovada dos requisitos. Binding não comprova montagem nem leitura e escrita. Não elimines a claim para apagar o sintoma antes de saber se referencia dados necessários; planeia a recriação controlada do consumidor quando a alteração do seu desenho a exigir.
Uma prova local tem um âmbito limitado
Um pedido por port-forward que termina em HTTP 200 mostra que aquele pedido alcançou a aplicação pelo túnel. Não prova que o cliente habitual chega ao ClusterIP nem que a operação completa funciona. Regista separadamente: resolução do nome, pedido a PodIP na porta esperada, pedido ao Service e operação através do cliente representativo. Cada passo restringe hipóteses, mas um sucesso num caminho não substitui o seguinte. Se o pedido direto ao ClusterIP continua em timeout, não atribuas automaticamente a causa a DNS. Compara política de rede, seleção de endpoints, portas e encaminhamento, com acesso autorizado e preservação de evidência.
Exercício guiado de recuperação
Considera seis Pods prontos: A1–A3 escutam em 8080; B1–B3 em 9090; todos declaram api corretamente. O destino numérico 8080 funciona apenas para o primeiro grupo. Num ensaio que força dez pedidos a cada Pod, 30 de 60 funcionam. Este denominador foi definido no exercício e não descreve a distribuição real de qualquer balanceador. Explica a hipótese, o pedido de mudança para targetPort=api e a evidência posterior exigida para ambos os grupos. Define também alternativa de rollback, capacidade mínima e reconciliação. A folha de diagnóstico deve distinguir factos observados, inferências e critérios por confirmar, em vez de escrever apenas “Kubernetes resolvido”.
Resumo e entrega à operação
Fecha o exercício com cinco evidências: destino e contexto corretos, mapeamento de portas observado, condições dos endpoints interpretadas, dependências disponíveis e resultado da operação representativa. Para storage, acrescenta binding, montagem e validação dos dados. Guarda alterações aprovadas, critérios de retorno, sinais de regressão e responsável pelo acompanhamento. Os modelos locais fornecidos verificam apenas contas e regras explícitas dos fixtures. Não executam kubelet, scheduler, CSI ou proxies, não medem timings nem confirmam disponibilidade de um cluster. Relaciona esta aula com serviços, armazenamento, diagnóstico de workloads e gestão de incidentes antes de avançar para prática real supervisionada.
kubectl --context=lab -n funds get service fund-api -o yaml
kubectl --context=lab -n funds get endpointslices -l kubernetes.io/service-name=fund-api -o yaml
kubectl --context=lab -n funds get pods -l app=fund-api -o wide
kubectl --context=lab -n funds describe pod recon-b
kubectl --context=lab -n funds describe pvc recon-data
kubectl --context=lab get storageclass funds-zonal -o yamlSeis Pods recebem dez pedidos cada num ensaio controlado. Três têm listener 8080 e três 9090; com destino 8080, 30 de 60 pedidos funcionam. A mudança para um nome de porta comum exige confirmação em ambos os grupos.
Armadilhas comuns
Confundir Running com serviço recuperado; usar a primeira porta de todas as slices; eliminar claims sem diagnóstico; inferir tráfego real a partir do fixture.
Tópicos relacionados: Serviços e rede · Volumes e dados · Incidentes e recuperação
O diagnóstico termina quando a operação afetada volta a funcionar com integridade, evidência e estabilidade.
Referência: Diagnose Service connectivity · CKA Kubernetes v1.35