Diagnosticar e reparar problemas em pods - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O Container Intelligence Service combina conhecimento especializado com modelos de IA para diagnosticar problemas e identificar suas causas raiz. O diagnóstico de pods inclui verificações de diagnóstico e análises de causa raiz.

Verificações de diagnóstico: Inspeciona Pods , nós, componentes de nó, componentes do cluster e o ECS controller manager.
Causa raiz: Apresenta a causa raiz identificada e recomendações de reparo. O diagnóstico de pods coleta informações de clusters e nós para detectar anomalias e, em seguida, realiza diagnósticos aprofundados com base nessas descobertas.

Importante

O recurso de diagnóstico executa um programa de coleta de dados nos nós do seu cluster para obter os resultados das verificações. As informações coletadas incluem a versão do sistema, o status das cargas de trabalho, Docker, kubelet e principais mensagens de erro dos logs do sistema. O programa de coleta não captura informações comerciais nem dados sensíveis.

Cenários anormais suportados

As tabelas a seguir listam os cenários anormais típicos cobertos pelo diagnóstico de pods e pelo diagnóstico assistido por IA.

Categoria	Cenário anormal
Diagnóstico de pods	O scheduler não processa o Pod.
	O Pod não pode ser agendado porque viola restrições de agendamento.
	O Kubelet não processa o Pod agendado.
	O Pod está aguardando um volume ficar pronto.
	O Pod foi removido (evicted).
	O Pod foi removido devido a espaço insuficiente em disco no nó.
	O Pod foi removido devido a memória insuficiente no nó.
	O Pod foi removido devido a inodes insuficientes no nó.
	Falha ao criar o contêiner sandbox para o Pod.
	O Pod está travado no estado Terminating.
	Um contêiner no Pod apresentou erro OOM.
	Um contêiner no Pod encerrou inesperadamente.
	Um contêiner no Pod está no estado CrashLoopBackOff.
	Um contêiner no Pod está NotReady.
	O Pod falhou ao baixar uma imagem.
	O Pod atingiu o tempo limite ao baixar uma imagem.
Diagnóstico assistido por IA	O status do Pod é anormal.
	O Pod sofreu um evento OOM.
	Um contêiner no Pod encerrou inesperadamente.
	O Pod apresenta erro de configuração de ConfigMap ou Secret.
	O Pod falhou em uma verificação de integridade.
	O Pod apresenta erro de configuração de PersistentVolumeClaim (PVC).
	O Pod falhou ao baixar uma imagem.

Processo de diagnóstico

O recurso de diagnóstico do cluster coleta informações de clusters e nós para identificar anomalias e, em seguida, executa diagnósticos aprofundados. Esse recurso integra o expert mode e o AI mode para determinar a root cause dos problemas. Cada diagnóstico passa por quatro etapas — anomaly identification, data collection, diagnostic item check e root cause analysis — para gerar os resultados.

Identificação de anomalias: Coleta dados básicos, como node status, pod status e cluster event streams, para analisar rapidamente as anomalias atuais.
Data Collection: Reúne dados contextuais com base nos resultados da anomaly identification. Por exemplo, em um diagnóstico de node, isso inclui informações do node obtidas do Kubernetes, as informações correspondentes da ECS e o status de processos como Docker e kubelet.
Verificação de itens de diagnóstico: Avalia métricas essenciais com base nos dados coletados. Por exemplo, os diagnostic items de um diagnóstico de node incluem o status do processo Docker e o status da ECS. Os diagnostic items específicos variam conforme o tipo de diagnóstico, e os resultados listam cada item verificado com sua descrição.
Root Cause Analysis: Para alguns problemas, o sistema analisa automaticamente a root cause com base nos dados coletados e nos resultados da diagnostic item check.

Resultados do diagnóstico

Os resultados dividem-se em dois tipos:

Resultados da análise de causa raiz: incluem anomalias detectadas, causa raiz identificada e sugestões de correção.
Resultados da verificação de itens de diagnóstico: apresentam os resultados individuais de cada item. Esses resultados podem revelar causas que a análise de causa raiz não detectou.

Os itens de diagnóstico variam conforme a configuração do cluster e refletem a configuração real do seu ambiente.

Categorias de diagnóstico

Categoria	Descrição
Pod	Diagnostica problemas comuns de Pod, incluindo status do Pod, download de imagens e conectividade de rede.
Nó	Diagnostica problemas comuns de nó, incluindo status do nó, status da rede, logs do kernel, status de processos principais e disponibilidade de serviços.
NodeComponent	Diagnostica o status de componentes essenciais do nó, incluindo plugins de rede e armazenamento.
ClusterComponent	Diagnostica problemas comuns do cluster, incluindo disponibilidade do serviço de API, disponibilidade de DNS e status do NAT gateway.
ECSControllerManager	Diagnostica problemas comuns de instâncias ECS, incluindo status, conectividade de rede, sistema operacional e E/S de disco.

Pod

Parâmetro	Descrição	Solução
Contagem de reinicializações de contêineres	Verifica quantas vezes os contêineres do Pod foram reinicializados.	Verifique o status e os logs do Pod. Para mais informações, consulte Solução de problemas de Pod.
Downloads de imagens de contêiner bloqueados	Verifica se os downloads de imagens de contêiner estão bloqueados para outros Pods no mesmo nó.
Validade do Secret de download de imagem	Verifica se os Secrets que o Pod usa para baixar uma imagem são válidos.
Conectividade do Pod aos Pods do CoreDNS	Verifica a conectividade do Pod aos Pods do CoreDNS.	Verifique a conectividade de rede do Pod ao CoreDNS.
Conectividade do Pod ao Service do CoreDNS	Verifica a conectividade do Pod ao Service do CoreDNS.	Verifique a conectividade de rede do Pod ao CoreDNS.
Conectividade do Pod ao servidor DNS da rede do host	Verifica a conectividade do Pod ao servidor DNS na rede do host.	Verifique a conectividade do Pod ao servidor DNS na rede do host.
Processo de contêiner no estado D	Verifica se os processos de contêiner no Pod estão no estado D (sleep ininterrupto).	Um processo de contêiner no estado D geralmente está travado em operações de E/S de disco. Tente reiniciar a instância ECS. Se o problema persistir, abra um ticket.
Status de inicialização do Pod	Verifica se o Pod foi inicializado corretamente.	Verifique o status e os logs do Pod. Para mais informações, consulte Solução de problemas de Pod.
Status de agendamento do Pod	Verifica se o Pod foi agendado corretamente.	Verifique o status e os logs do Pod. Para mais informações, consulte Solução de problemas de Pod.

Nó

Se o problema persistir após aplicar a correção sugerida, colete os logs do nó e abra um ticket.

Item de diagnóstico	O que detecta	Correção
Erros de conectividade com o servidor de API do Kubernetes	Se o nó consegue alcançar o servidor de API do cluster. A perda de conectividade impede o nó de receber atribuições de carga de trabalho.	Verifique a configuração do cluster. Consulte Solucionar problemas de clusters ACK.
Travamentos de montagem AUFS	Se há travamentos de montagem AUFS ocorrendo no nó.	Abra um ticket.
Erros BufferIOError	Se há erros BufferIOError presentes no kernel do nó.	Abra um ticket.
Vazamentos de cgroup	Se há vazamentos de cgroup ocorrendo. Vazamentos de cgroup podem interromper a coleta de dados de monitoramento e causar falhas na inicialização de contêineres.	Faça login no nó e exclua os diretórios cgroup afetados.
Status anormal do processo chronyd	Se o processo chronyd está executando normalmente. Um processo chronyd anormal interrompe a sincronização de relógio, afetando operações sensíveis ao tempo.	Execute `systemctl restart chronyd` para reiniciar o processo.
Download de imagens pelo containerd	Se o runtime containerd consegue baixar imagens conforme esperado.	Verifique a configuração de rede do nó e as configurações de imagem.
Status do containerd	Se o runtime containerd está em execução.	Abra um ticket.
Disponibilidade do pod CoreDNS	Se o nó consegue alcançar o endereço IP do pod CoreDNS. Pods CoreDNS inacessíveis causam falhas na resolução de DNS para cargas de trabalho neste nó.	Verifique se o nó consegue acessar o endereço IP do pod CoreDNS. Consulte O que fazer se a carga de consulta DNS não estiver balanceada entre os pods do CoreDNS?.
Status das imagens	Se as imagens estão íntegras. Imagens danificadas impedem a inicialização de contêineres.	Abra um ticket.
Status overlay2 das imagens	Se o sistema de arquivos overlay2 nas imagens está danificado.	Abra um ticket.
Hora do sistema	Se o relógio do sistema está preciso.	Nenhuma.
Inicialização de contêineres Docker	Se há falhas na inicialização de contêineres Docker.	Abra um ticket.
Download de imagens Docker	Se o nó consegue baixar imagens Docker conforme esperado.	Verifique a configuração de rede do nó e as configurações de imagem.
Status do Docker	Se o runtime Docker está em execução.	Abra um ticket.
Tempo de inicialização do Docker	O tempo de inicialização do Dockerd.	Nenhuma.
Erros de travamento do Docker	Se há erros de travamento do Docker ocorrendo no nó. Travamentos do Docker podem fazer com que os contêineres parem de responder.	Execute `systemctl restart docker` para reiniciar o Docker.
Existência da instância ECS	Se a instância ECS subjacente existe.	Verifique o status da instância ECS. Consulte FAQ sobre nós e pools de nós.
Status da instância ECS	Se a instância ECS está em um estado saudável.	Verifique o status da instância ECS. Consulte FAQ sobre nós e pools de nós.
Erros Ext4FsError	Se há erros Ext4FsError presentes no kernel do nó.	Abra um ticket.
Sistema de arquivos do nó somente leitura	Se o sistema de arquivos do nó tornou-se somente leitura. Isso geralmente indica falha no disco e bloqueia todas as operações de gravação, afetando as cargas de trabalho.	Execute `fsck` para reparar o sistema de arquivos e, em seguida, reinicie o nó.
Hora do hardware	Se o relógio de hardware e o relógio do sistema estão sincronizados. Uma diferença maior que 2 minutos pode causar erros nos componentes.	Execute `hwclock --systohc` para sincronizar a hora do sistema com o relógio de hardware.
DNS	Se os nomes de domínio podem ser resolvidos no nó.	Consulte Solução de problemas de DNS.
Erros oops do kernel	Se há erros oops presentes no kernel do nó. Eles indicam caminhos de código inesperados e podem causar instabilidade.	Abra um ticket.
Versões do kernel	Se a versão do kernel está desatualizada. Kernels desatualizados podem ter problemas conhecidos de estabilidade.	Atualize o kernel do nó. Consulte FAQ sobre nós e pools de nós.
Disponibilidade de DNS	Se o nó consegue alcançar o IP do cluster do Service kube-dns para usar o serviço de DNS do cluster.	Verifique o status e os logs dos pods do CoreDNS. Consulte Solução de problemas de DNS.
Status do kubelet	Se o kubelet está executando normalmente. Um kubelet com falha impede o nó de gerenciar pods.	Verifique os logs do kubelet. Consulte Solucionar problemas de clusters ACK.
Tempo de inicialização do kubelet	O tempo de inicialização do kubelet.	Nenhuma.
Utilização de CPU	Se a utilização de CPU do nó está excessivamente alta.	Nenhuma.
Utilização de memória	Se a utilização de memória do nó está excessivamente alta.	Nenhuma.
Fragmentação de memória	Se existe fragmentação de memória no nó. A fragmentação reduz a memória contígua e pode degradar o desempenho das cargas de trabalho.	Faça login no nó e execute `echo 3 \> /proc/sys/vm/drop_caches` para limpar o cache.
Memória swap	Se a memória swap está ativada. O Kubernetes exige que o swap esteja desativado; ativá-lo pode fazer com que o kubelet apresente comportamento inesperado.	Faça login no nó e desative a memória swap.
Carregamento de drivers de dispositivos de rede	Se os drivers VirtIO nos dispositivos de rede foram carregados corretamente.	Abra um ticket.
Utilização de CPU do nó excessivamente alta	Se a utilização de CPU esteve alta na última semana. Se muitos pods forem agendados em um nó com uso consistentemente alto de CPU, a contenção de recursos pode resultar em interrupções de serviço.	Defina solicitações e limites de recursos adequadamente para evitar sobrecarregar o nó.
Existência de IP privado do nó	Se o nó tem um endereço IP privado atribuído. Sem um IP privado, o nó não consegue se comunicar dentro do cluster.	Remova o nó do cluster e adicione-o novamente. Não libere a instância ECS ao removê-la. Consulte Remover um nó e Adicionar instâncias ECS existentes.
Utilização de memória do nó excessivamente alta	Se a utilização de memória esteve alta na última semana. Alta utilização de memória combinada com agendamento intenso de pods pode causar erros de falta de memória (OOM) e interrupções de serviço.	Defina solicitações e limites de recursos adequadamente para evitar sobrecarregar o nó.
Status do nó	Se o nó está no estado Ready.	Reinicie o nó. Consulte FAQ sobre nós e pools de nós.
Agendabilidade do nó	Se o nó está marcado como não agendável. Um nó não agendável não recebe novas atribuições de pods.	Verifique a configuração de agendamento do nó. Consulte Drenagem de nó e status de agendamento.
Erros OOM	Se há erros de falta de memória (OOM) ocorrendo no nó. Erros OOM podem causar a eliminação de pods e processos do sistema.	Abra um ticket.
Verificação de runtime	Se o runtime de contêiner do nó corresponde ao runtime configurado no cluster. Uma incompatibilidade pode causar falha na inicialização de pods.	Consulte Posso alterar o runtime de contêiner de um cluster de containerd para Docker?.
Versões desatualizadas do SO	Se a versão do SO do nó possui bugs conhecidos ou problemas de estabilidade. Versões desatualizadas do SO podem causar mau funcionamento dos runtimes Docker e containerd.	Atualize a versão do SO.
Acesso à internet	Se o nó consegue acessar a internet.	Verifique se o SNAT está habilitado para o cluster. Consulte Habilitar um cluster ACK existente a acessar a internet.
Erros RCUStallError	Se há erros RCUStallError presentes no kernel do nó. Esses erros indicam que um núcleo de CPU está preso em uma seção crítica de read-copy-update (RCU), o que pode causar o travamento do nó.	Abra um ticket.
Versões do SO	A versão do SO usada pelo nó. Versões desatualizadas do SO podem impedir o funcionamento normal do cluster.	Nenhuma.
Vazamentos de processo runc	Se há vazamentos de processo runc ocorrendo. Vazamentos de processo runc podem fazer com que o nó entre periodicamente no estado NotReady.	Identifique os processos runc vazados e encerre-os manualmente.
Erros SoftLockupError	Se há erros SoftLockupError presentes no kernel do nó. Eles indicam que um núcleo de CPU não está respondendo a interrupções, o que pode causar instabilidade no nó.	Abra um ticket.
Travamentos do systemd	Se há travamentos do systemd ocorrendo. Um systemd travado pode impedir que serviços iniciem ou parem, afetando a estabilidade do nó.	Faça login no nó e execute `systemctl daemon-reexec` para reiniciar o systemd.
Versões desatualizadas do systemd	Se a versão do systemd possui bugs conhecidos. Versões desatualizadas podem causar mau funcionamento do Docker e do containerd.	Atualize a versão do systemd. Consulte systemd.
Processos travados	Se existem processos travados no nó. Processos travados consomem recursos sem progresso e degradam o desempenho do nó.	Abra um ticket.
Erros unregister_netdevice	Se há erros unregister_netdevice presentes no kernel do nó. Eles podem causar vazamentos de recursos do kernel e instabilidade de rede.	Abra um ticket.

NodeComponent

Item de diagnóstico	O que detecta	Correção
Status do componente CNI	Se o plugin Container Network Interface (CNI) está executando conforme esperado. Um plugin CNI com falha interrompe a rede dos pods no nó.	Verifique o status do componente de rede do cluster. Consulte FAQ sobre gerenciamento de rede.
Status do componente CSI	Se o plugin Container Storage Interface (CSI) está executando conforme esperado. Um plugin CSI com falha impede que os pods montem volumes.	Verifique o status do componente de armazenamento do cluster. Consulte FAQ sobre CSI.

ClusterComponent

Item de diagnóstico	O que detecta	Correção
Versão do aliyun-acr-credential-helper	Se a versão do componente aliyun-acr-credential-helper está desatualizada.	Atualize o aliyun-acr-credential-helper. Consulte Usar o componente aliyun-acr-credential-helper para baixar imagens sem usar um secret.
Disponibilidade do API Service	Se o API Service do cluster está disponível. Um API Service indisponível bloqueia operações de gerenciamento de carga de trabalho.	Execute `kubectl get apiservice` para verificar a disponibilidade. Se estiver indisponível, execute `kubectl describe apiservice` para identificar a causa.
Blocos CIDR de pod disponíveis insuficientes	Se o número de blocos CIDR de pod disponíveis em um cluster Flannel é menor que cinco. Cada nó requer um bloco CIDR de pod; se todos os blocos forem usados, novos nós não poderão ingressar no cluster.	Abra um ticket.
Endpoints do CoreDNS	O número de endpoints ativos do CoreDNS. Poucos endpoints reduzem a disponibilidade do DNS.	Verifique o status e os logs dos pods do CoreDNS. Consulte Solução de problemas de DNS.
Endereços IP de cluster do CoreDNS	Se endereços IP de cluster estão atribuídos aos pods do CoreDNS. Sem um IP de cluster, as solicitações de DNS não chegam ao CoreDNS, causando falhas de DNS em todo o serviço.	Verifique o status e os logs dos pods do CoreDNS. Consulte Solução de problemas de DNS.
Status do NAT gateway	Se o NAT gateway do cluster está funcionando normalmente. Um NAT gateway com falha bloqueia o tráfego de saída para a internet a partir de nós sem IP público.	Acesse o console do NAT Gateway e verifique se o gateway está bloqueado devido a pagamentos atrasados.
Taxa excessivamente alta de quedas de conexões simultâneas no NAT gateway	Se o NAT gateway está descartando uma taxa anormalmente alta de conexões simultâneas. Altas taxas de descarte indicam que o gateway atingiu sua capacidade de conexão.	Atualize o NAT gateway. Consulte FAQ sobre atualização de NAT gateways de internet padrão para NAT gateways de internet aprimorados.

ECSControllerManager

Item de diagnóstico	O que detecta	Correção
Pagamentos atrasados relacionados a componentes da instância ECS	Se o disco ou a largura de banda de rede da instância está restrito devido a pagamentos atrasados. Recursos restritos podem causar falhas na carga de trabalho.	Recarregue sua conta para restaurar o acesso.
Pagamentos atrasados relacionados à instância ECS	Se a instância ECS de pagamento conforme o uso foi suspensa devido a pagamentos atrasados.	Recarregue sua conta e reinicie a instância.
Status da NIC da instância ECS	Se a placa de interface de rede (NIC) da instância está funcionando normalmente. Uma NIC anormal causa perda de conectividade de rede.	Reinicie a instância.
Status de inicialização da instância ECS	Se a instância pode ser inicializada normalmente.	Se a inicialização falhar, crie uma nova instância.
Status do sistema de gerenciamento de backend da instância ECS	Se o sistema de gerenciamento de backend da instância está operando normalmente.	Reinicie a instância.
Status das CPUs da instância ECS	Se há contenção de CPU ou falhas de vinculação de CPU na camada subjacente da instância. A contenção de CPU pode impedir que a instância adquira recursos de CPU e degrade o desempenho.	Reinicie a instância.
Split locks nas CPUs da instância ECS	Se há split locks ocorrendo nas CPUs da instância ECS. Split locks podem degradar severamente o desempenho da CPU.	Consulte Detectando e tratando split locks.
Status da mitigação de DDoS para a instância ECS	Se o endereço IP público da instância está sob ataque DDoS.	Adquira um serviço anti-DDoS. Consulte Comparação das soluções Anti-DDoS da Alibaba Cloud.
Capacidades limitadas de leitura/gravação do disco em nuvem	Se o throughput de leitura/gravação do disco em nuvem está sendo limitado. A limitação ocorre quando o IOPS máximo é atingido, fazendo com que as operações de E/S fiquem lentas ou enfileiradas.	Consulte Desempenho do Block Storage.
Carregamento do disco da instância ECS	Se o disco em nuvem pode ser anexado quando a instância inicia.	Pare a instância e inicie-a novamente.
Expiração da instância ECS	Se a instância por assinatura expirou. Uma instância expirada é parada e seus recursos ficam indisponíveis.	Renove a instância. Consulte Renovar uma instância por assinatura.
Travamentos do SO da instância ECS	Se ocorreram travamentos do SO nas últimas 48 horas.	Revise os logs do sistema para identificar a causa. Consulte Visualizar logs e capturas de tela do sistema.
Status do host da instância ECS	Se o servidor físico que hospeda a instância apresenta falhas. Falhas no host podem degradar o desempenho da instância.	Reinicie a instância.
Carregamento da imagem da instância ECS	Se a instância consegue carregar sua imagem durante a inicialização.	Reinicie a instância.
Travamentos de E/S no disco da instância ECS	Se há travamentos de E/S ocorrendo no disco do sistema. Travamentos de E/S de disco podem tornar o sistema operacional irresponsivo.	Verifique as métricas do disco. Consulte Visualizar os dados de monitoramento de um disco em nuvem. Para Alibaba Cloud Linux 2, consulte Detectar travamentos de E/S de sistemas de arquivos e camadas de bloco.
Limite superior de largura de banda da instância ECS	Se a largura de banda total da instância atingiu o máximo para seu tipo de instância. Quando o limite é atingido, o throughput de rede é limitado e pacotes podem ser descartados.	Atualize para um tipo de instância com maior largura de banda. Consulte Visão geral das alterações de configuração de instância.
Limite superior da largura de banda burst da instância ECS	Se a largura de banda burst da instância excedeu o máximo permitido para seu tipo de instância.	Atualize para um tipo de instância com maior largura de banda. Consulte Visão geral das alterações de configuração de instância.
Carregamento da NIC da instância ECS	Se a NIC pode ser carregada na instância. Se a NIC falhar ao carregar, a instância perde a conectividade de rede.	Reinicie a instância.
Estabelecimento de sessão da NIC na instância ECS	Se sessões podem ser estabelecidas para a NIC. Se a NIC não conseguir estabelecer sessões ou tiver atingido seu limite de sessões, a conectividade ou o throughput da rede será afetado.	Reinicie a instância.
Operações chave na instância ECS	Se operações recentes na instância — como iniciar, parar ou atualizar — foram concluídas com sucesso.	Tente novamente a operação que falhou.
Perda de pacotes na NIC da instância ECS	Se há perda de pacotes de entrada ou saída ocorrendo na NIC. A perda de pacotes causa erros de rede e pode interromper serviços.	Reinicie a instância.
Degradação de desempenho da instância ECS	Se o desempenho da instância foi temporariamente degradado devido a problemas de software ou hardware.	Visualize os eventos históricos ou logs do sistema da instância para identificar a causa. Consulte Visualizar eventos históricos do sistema.
Desempenho comprometido da instância ECS	Se o desempenho da instância está reduzido. Créditos de CPU insuficientes fazem com que instâncias burstable retornem ao desempenho básico.	A instância ECS só pode fornecer o desempenho básico devido a créditos de CPU disponíveis insuficientes.
Redimensionamento de disco da instância ECS	Se o disco foi redimensionado, mas o SO ainda não expandiu o sistema de arquivos. O espaço adicional em disco fica indisponível até que o sistema de arquivos seja redimensionado.	O SO não redimensiona automaticamente o sistema de arquivos após o redimensionamento do disco. Se o disco permanecer inutilizável, redimensione-o novamente.
Aplicação de recursos da instância ECS	Se há recursos físicos de CPU e memória suficientes disponíveis para a instância. Se os recursos forem insuficientes, a instância não poderá iniciar.	Aguarde alguns minutos e tente iniciar a instância novamente. Se o problema persistir, crie uma instância em outra região.
Status do SO da instância ECS	Se ocorreram kernel panics, erros OOM ou falhas internas no SO da instância. Estes são frequentemente causados por configurações incorretas ou programas do usuário.	Reinicie a instância.
Status de virtualização da instância ECS	Se há exceções na camada de virtualização subjacente. Estas podem fazer com que a instância pare de responder ou seja suspensa inesperadamente.	Reinicie a instância.