Correlacione logs da aplicação, métricas de recursos, eventos do Kubernetes, estados de Pods, Services, EndpointSlices, ingresso e conectividade ponta a ponta para diagnosticar cargas de IA.
Tempo de estudo sugerido: 85 minutos • Nível intermediário • Reescrita autoral completa com versão resumida de cada tópico, avaliação comentada e laboratório guiado
Por João Ricardo Dutra••Conteúdo autoral completo
1. Observar toda a carga de IA antes de alterá-la
Uma de inferência e um worker de enriquecimento podem parecer saudáveis enquanto usuários percebem lentidão, falhas no modelo ou recomendações desatualizadas. A origem pode estar no código, em uma dependência, na configuração do Kubernetes, no roteamento do Service, na pressão de recursos ou no . Monitorar reduz o campo de busca antes que uma mudança introduza outra variável.
O reúne visões complementares. O oferece Cargas de trabalho, ao vivo, insights de contêiner, Monitoramento, Console e Diagnosticar e resolver problemas. kubectl expõe recursos, , eventos, métricas e objetos de rede. Uma investigação confiável avança de sintoma para evidência, hipótese, teste controlado, correção durável e verificação.
Identifique o caminho afetado e a janela de tempo.
Compare sinais da aplicação, do Kubernetes e da infraestrutura.
Use o portal para delimitar visualmente e kubectl para detalhar.
Altere código, configuração ou manifestos em vez do contêiner em execução.
Resumo do tópico
Comece pelo sintoma do usuário e correlacione evidências do portal e do kubectl antes de escolher uma correção reproduzível.
2. Selecionar e métricas que expliquem o comportamento da IA
Latência, vazão, 5xx, , profundidade de fila, duração de lotes, reinícios, códigos de saída, CPU e memória descrevem camadas diferentes. Compare utilização com e limits: atingir o limite de CPU causa e latência; pressão de memória pode encerrar o contêiner e reiniciá-lo.
Mapa de sinais.
Sinal
Pergunta
Ação comum
Latência e vazão
O atende à demanda?
Inspecionar dependências, escalar ou otimizar.
Erros e
Quais solicitações falham?
Correlacionar estruturados e rastros.
Reinícios e códigos de saída
O contêiner é estável?
Ver anteriores, status e eventos.
CPU e memória
Capacidade ou limite restringe o Pod?
Redimensionar ou escalar réplicas.
Fila ou lote
O trabalho em segundo plano acumula?
Ajustar concorrência e escala.
Um sinal útil liga o impacto percebido à aplicação, à orquestração ou à capacidade.
Resumo do tópico
Monitore resultado do usuário, aplicação, ciclo do Pod e capacidade juntos; uma única métrica não explica todo o incidente.
3. Inspecionar evidências atuais e históricas no
Em Recursos do Kubernetes, Cargas de trabalho exibe estado, idade, reinícios e detalhes de Deployments, Pods, ReplicaSets, StatefulSets, Jobs e CronJobs. ao vivo transmite stdout e stderr, permite pausar, pesquisar e escolher o contêiner de um Pod com . Console abre um terminal interativo pelo navegador.
A guia Monitoramento resume pools de nós e abre gráficos no explorador de métricas. Em Monitoramento, insights de contêiner correlaciona namespaces, controladores, contêineres, , eventos, CPU, memória, rede e sistema de arquivos. Dados ao vivo exigem e acesso direto à ; privados exigem alcance de rede. Histórico depende da configuração do e Analytics.
Resumo do tópico
Use Cargas de trabalho e dados ao vivo no incidente atual e insights de contêiner e para histórico e análise entre Pods.
4. Ler de contêiner com precisão usando kubectl
Liste Pods no correto, escolha a instância problemática e acompanhe enquanto reproduz a solicitação. -c seleciona o contêiner da em vez do . --previous é essencial após reinício, pois os atuais podem ocultar o processo que acabou de falhar.
Namespaces separam lógica, acesso e cotas; labels selecionam a aplicação dentro desse limite. Registre timestamp, identificador de correlação, modelo e versão, status e duração da dependência em formato estruturado. Não escreva , prompts confidenciais, strings de conexão nem credenciais.
Resumo do tópico
Escolha , Pod, contêiner e instância do ciclo corretos e correlacione estruturados à solicitação que reproduz a falha.
5. Comparar consumo com e limits
O portal mostra CPU e memória por pool e, nos insights de contêiner, por nó, controlador, Pod ou contêiner. Métricas ao vivo acrescenta CPU, memória, rede e sistema de arquivos atuais. Com Metrics Server disponível, kubectl top fornece uma fotografia rápida.
kubectl top nodes
kubectl top pods -n ai-workloads
kubectl top pod <pod-name> --containers -n ai-workloads
Fotografia não é tendência. Compare a mesma janela do erro, e limits, réplicas desejadas, capacidade do nó e evidências de ou falta de memória. CPU sustentada no limite pede teste de novos recursos, réplicas, eficiência do modelo ou distribuição da carga, não um aumento arbitrário.
Resumo do tópico
Combine histórico do portal e fotografia do kubectl, comparando consumo com , limits, réplicas e objetivos do serviço.
6. Construir telemetria de produção que favoreça a investigação
Observabilidade de produção define objetivos de latência e erro, mantém histórico útil e alerta antes de impacto amplo. estruturados e IDs de correlação conectam ,, modelo, , fila e worker. A versão do modelo e da aplicação associa regressão ao rollout.
Use Prometheus gerenciado e Grafana para métricas e painéis temporais.
Use insights de contêiner e Analytics para saída dos contêineres, inventário e pesquisa histórica.
Configure regras de coleta, retenção e filtros equilibrando evidência e custo.
Alerte sobre sintomas e esgotamento, vinculando o alerta a um runbook.
Proteja telemetria com e retire dados confidenciais.
Resumo do tópico
Projete , métricas, alertas, retenção e correlação antes do incidente para reconstruir solicitação e implantação.
7. Reconhecer estados problemáticos dos Pods
Sintomas comuns.
Estado
Causa provável
Primeira evidência
Imagem, tag, acesso ao registro ou identidade incorretos
Eventos e referência da imagem.
Processo encerra, comando, configuração ou dependência inválida
Status, anteriores e eventos.
Pending
Recurso, afinidade, volume, cota ou regra de agendamento
Eventos de agendamento e .
Reinícios frequentes
Sonda, memória, vazamento ou exceção
Contagem, motivo, e métricas.
Running sem Ready
Readiness ou dependência falha
Condições, eventos e saúde local.
O nome do estado é um sintoma; eventos e runtime revelam a causa.
Resumo do tópico
Use ,, Pending, reinícios e readiness falha como pontos de partida, não como diagnósticos.
8. Descrever Pods e examinar eventos do Kubernetes
kubectl describe pod reúne estado, último encerramento, sondas, fontes de ambiente, mounts, agendamento e eventos em ordem. Eventos mostram falhas no pull, restrições de posicionamento, falhas de sonda e ações de controladores que o da aplicação não explica.
kubectl get pods -n ai-workloads
kubectl describe pod <pod-name> -n ai-workloads
kubectl get events -n ai-workloads --sort-by=.metadata.creationTimestamp
kubectl exec -it <pod-name> -n ai-workloads -- /bin/sh
Verifique caminhos e portas de readiness e liveness, variáveis, ConfigMaps, Segredos, recursos, volumes do modelo, service account, imagem e eventos recentes. Eventos expiram; capture a saída durante o incidente. Diagnosticar e resolver problemas complementa a análise com detectores do e recomendações.
Resumo do tópico
Use describe e eventos para ligar estado a sondas, configuração, volumes, agendamento, imagem, identidade e decisões de controle.
9. Diagnosticar dentro do contêiner sem criar divergência
Console ou kubectl exec mostra arquivos, configuração montada, variáveis, e locais. O shell só existe se a imagem o inclui; caso contrário, use um fluxo aprovado com contêiner efêmero ou imagem de diagnóstico.
Confirme arquivos do modelo e de configuração.
Verifique valores não sensíveis e apenas a presença de credenciais.
Chame localhost de integridade e inferência.
Resolva e teste dependências permitidas.
Saia sem instalar ferramentas ou alterar arquivos.
Mudanças interativas desaparecem e criam drift. Corrija fonte, imagem, ConfigMap, mapeamento do Segredo, sonda, recursos ou manifesto; implante pelo processo normal e teste novamente.
Resumo do tópico
Inspecione o runtime por Console ou exec, mas faça a correção permanente em código, configuração, imagem ou manifesto versionado.
10. Validar seletores, portas e EndpointSlices do Service
Pod saudável não torna a alcançável. O Service seleciona Pods por label e o plano de controle registra prontos em EndpointSlices. Lista vazia indica, em geral, incompatibilidade seletor-label, Pods não prontos ou errado. Uma slice preenchida revela IPs, portas e condições usadas no roteamento.
kubectl get service -n ai-workloads
kubectl describe service inference-api -n ai-workloads
kubectl get pods --show-labels -n ai-workloads
kubectl get endpointslices -l kubernetes.io/service-name=inference-api -n ai-workloads
Compare seletor do Service com labels do Pod, port com targetPort, targetPort com a porta escutada, protocolo, e endereços. O objeto legado está obsoleto no Kubernetes atual; prefira EndpointSlices.
Resumo do tópico
Comprove a cadeia seletor-label-porta e confirme endereços prontos em EndpointSlices antes de investigar a exposição externa.
11. Rastrear ,, e ingresso
atende apenas o interior do . mapeia uma porta em cada nó e costuma ser peça intermediária. LoadBalancer cria o caminho pelo e um endereço externo. Ingresso acrescenta regras de host e caminho por um controlador e Services de .
No , Serviços e ingressos mostra tipo, , external , portas, seletores, , hosts, caminhos e endereços. Valide cada salto: listener do processo, Pod, EndpointSlice, Service, ingresso ou , / quando existir e cliente.
Sucesso ponta a ponta depende de todos os contratos de roteamento.
Resumo do tópico
Escolha a exposição deliberadamente e teste a porta do contêiner, Service, EndpointSlice e ingresso ou .
12. Testar conectividade interna e externa com segurança
kubectl port-forward cria um túnel local temporário para um Pod selecionado por um Service. Ele isola comportamento interno antes do ingresso ou da exposição pública. A sessão termina quando o Pod selecionado encerra e deve ser reiniciada; é ferramenta de diagnóstico, não publicação de produção.
kubectl port-forward service/inference-api 8080:80 -n ai-workloads
curl -i http://localhost:8080/api/inference
kubectl get service inference-api -n ai-workloads
kubectl get ingress -n ai-workloads
Encaminhe a porta e chame integridade ou inferência localmente.
Correlacione com , métricas e eventos.
Confirme external do Service ou endereço de ingresso.
Teste de um cliente representativo, incluindo hostname, caminho, e autenticação.
Repita após a correção e observe erro e latência.
Resumo do tópico
Use port-forward para isolar o caminho interno e depois valide o endereço real de ou ingresso externamente.
13. Laboratório guiado: diagnosticar uma aplicação no
O exercício de cerca de 30 minutos implanta uma em contêiner com e e usa kubectl para examinar status, e eventos. O aluno corrige seletor incompatível, variável de ambiente ausente e caminho inválido da readiness probe, valida a conectividade e exclui recursos.
Baixe o projeto e identifique os recursos propositalmente defeituosos.
Implante registro, , imagem e manifestos.
Reproduza cada sintoma e reúna evidências antes da edição.
Use kubectl edit ou o manifesto fonte para corrigir seletor, configuração e sonda.
Teste a , confirme Pods e saudáveis e limpe recursos faturáveis.
Pré-requisitos: assinatura do com permissões, , Python 3.12 ou posterior, CLI do atual e kubectl. ACR Tasks pode exigir pagamento conforme o uso porque créditos gratuitos talvez não cubram execuções.
Resumo do tópico
O laboratório pratica correção orientada a evidências para seletores, ambiente e readiness, mantendo a implantação reproduzível.
14. Avaliação, runbook de produção e referências
Decisões da avaliação.
Cenário
Ação correta
Motivo
500 e latência ao reproduzir
kubectl -f no Pod específico
Transmite a falha atual.
Descrever Pod e ver status e eventos
Mostra encerramento e orquestração.
Pods saudáveis sem
Descrever o Service
Expõe seletor e .
Teste antes da exposição
kubectl port-forward service/...
Cria caminho local ao Service.
CPU sustentada no limite
Ajustar recursos ou escalar réplicas
Recupera capacidade medida.
Registre sintoma, escopo, início e objetivo do serviço.
Capture versão, , métricas, status, eventos, Services e EndpointSlices.
Teste a menor hipótese e registre o resultado.
Aplique mudança versionada com .
Valide tráfego e os sinais originais após recuperar.
