Identifique e resolva problemas em nós com verificações de diagnóstico e análise de causa raiz assistida por IA.
Durante a execução do diagnóstico de nós, o ACK coleta a versão do sistema, o status de workloads, docker e kubelet, além dos principais erros de logs do sistema de cada nó. Nenhum dado comercial ou informação sensível é coletado.
O diagnóstico de nós consiste em dois componentes:
Diagnostic items: diagnostica nós, componentes de nó, componentes de cluster, o gerenciador de controladores do Elastic Compute Service (ECS) e nós acelerados por GPU.
Root causes: localiza causas raízes e sugere correções ao coletar dados do cluster e dos nós, identificar anomalias e analisar detalhes.
Como funciona
Os resultados do diagnóstico passam por quatro etapas:

Anomaly identification: Coleta sinais básicos — status do nó, status do pod e fluxos de eventos do cluster — e identifica anomalias.
Data collection: Reúne dados específicos de contexto com base nas anomalias identificadas, incluindo informações de nós do Kubernetes, detalhes de instâncias ECS e status de processos docker/kubelet.
Diagnostic item check: Verifica se as métricas principais estão dentro das faixas normais. Os itens são agrupados por categoria, cada um com uma descrição.
Root cause analysis: Determina a causa raiz dos problemas com base nos dados coletados e nos resultados das verificações.
Resultados do diagnóstico
Os resultados dividem-se em dois tipos:
Root cause analysis results: incluem anomalias detectadas, a causa raiz identificada e sugestões de correção.
Diagnostic item check results: incluem resultados de verificação por item. Estes 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 sua configuração real.
Casos de uso
O diagnóstico de nós e o diagnóstico assistido por IA cobrem os seguintes cenários.
|
Categoria |
Cenário |
|
Diagnóstico de nós |
Node NotReady — rede não pronta, IDs de processo (PIDs) insuficientes, memória insuficiente, espaço em disco insuficiente, exceções de runtime ou nenhum heartbeat detectado |
|
Cota de inodes insuficiente |
|
|
Cota de PID insuficiente |
|
|
Hora incorreta no nó |
|
|
Sistema de arquivos do nó somente leitura |
|
|
Deadlocks no kernel do nó |
|
|
Diagnóstico assistido por IA |
Status anormal do nó |
|
Status anormal da instância ECS |
|
|
Erros de kubelet nos nós |
|
|
Exceções de runtime nos nós |
|
|
Espaço em disco insuficiente |
|
|
Alta utilização de CPU nos nós |
Itens de diagnóstico
|
Categoria |
O que é verificado |
|
Status do nó, status da rede, logs do kernel, processos do kernel e disponibilidade de serviços |
|
|
Status de componentes essenciais do nó, incluindo componentes de rede e armazenamento |
|
|
Disponibilidade do servidor de API, disponibilidade de dns e status do gateway NAT |
|
|
Status da instância ECS, conexões de rede, integridade do sistema operacional e E/S de disco |
|
|
Status do módulo NVIDIA e configurações de runtime de contêineres em nós acelerados por GPU |
Nó
Se um problema persistir após aplicar a correção sugerida, colete os logs do nó e envie um ticket.
|
Item de diagnóstico |
O que é detectado |
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 que o nó receba atribuições de workload. |
Verifique a configuração do cluster. Consulte Solucionar problemas de clusters ACK. |
|
Travamentos de montagem AUFS |
Se há travamentos de montagem AUFS no nó. |
|
|
Erros BufferIOError |
Se existem erros BufferIOError no kernel do nó. |
|
|
Vazamentos de cgroup |
Se há vazamentos de cgroup. Esses vazamentos 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á em execução normal. Um processo chronyd anormal interrompe a sincronização de relógio, afetando operações sensíveis ao tempo. |
Execute |
|
Pull de imagens pelo containerd |
Se o runtime containerd consegue baixar imagens conforme esperado. |
Verifique a configuração de rede do nó e as definições de imagem. |
|
Status do containerd |
Se o runtime containerd está em execução. |
|
|
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 workloads 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 da imagem |
Se as imagens estão íntegras. Imagens corrompidas impedem a inicialização dos contêineres. |
|
|
Status overlay2 das imagens |
Se o sistema de arquivos overlay2 nas imagens está corrompido. |
|
|
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. |
|
|
Pull de imagens docker |
Se o nó consegue baixar imagens docker conforme esperado. |
Verifique a configuração de rede do nó e as definições de imagem. |
|
Status do docker |
Se o runtime docker está em execução. |
|
|
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 no nó. Travamentos do docker podem fazer com que os contêineres parem de responder. |
Execute |
|
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 existem erros Ext4FsError no kernel do nó. |
|
|
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 escrita, afetando os workloads. |
Execute |
|
Hora do hardware |
Se o relógio de hardware e o relógio do sistema estão sincronizados. Uma diferença superior a 2 minutos pode causar erros nos componentes. |
Execute |
|
dns |
Se os nomes de domínio podem ser resolvidos no nó. |
Consulte Solução de problemas de DNS. |
|
Erros de kernel oops |
Se existem erros oops no kernel do nó. Estes indicam caminhos de código inesperados e podem causar instabilidade. |
|
|
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 Serviço kube-dns para usar o serviço de dns do cluster. |
Verifique o status e os logs dos pods CoreDNS. Consulte Solução de problemas de DNS. |
|
Status do Kubelet |
Se o kubelet está em execução normal. Um kubelet com falha impede que o nó gerencie 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 do workload. |
Faça login no nó e execute |
|
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. |
|
|
Utilização de CPU excessivamente alta no nó |
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ó possui 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 excessivamente alta no nó |
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) no nó. Erros OOM podem causar a eliminação de pods e processos do sistema. |
|
|
Verificação de runtime |
Se o runtime de contêineres do nó corresponde ao runtime configurado no cluster. Uma incompatibilidade pode impedir a inicialização dos pods. |
Consulte Posso alterar o runtime de contêineres 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á ativado para o cluster. Consulte Habilitar um cluster ACK existente para acessar a internet. |
|
Erros RCUStallError |
Se existem erros RCUStallError 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 travar o nó. |
|
|
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. 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 existem erros SoftLockupError no kernel do nó. Estes indicam que um núcleo de CPU não está respondendo a interrupções, o que pode causar instabilidade no nó. |
|
|
Travamentos do Systemd |
Se há travamentos do systemd. Um systemd travado pode impedir que serviços iniciem ou parem, afetando a estabilidade do nó. |
Faça login no nó e execute |
|
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ó. |
|
|
Erros unregister_netdevice |
Se existem erros unregister_netdevice no kernel do nó. Estes podem causar vazamentos de recursos do kernel e instabilidade na rede. |
NodeComponent
|
Item de diagnóstico |
O que é detectado |
Correção |
|
Status do componente CNI |
Se o plugin Container Network Interface (CNI) está em execução 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á em execução 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 é detectado |
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 segredo. |
|
Disponibilidade do Serviço de API |
Se o Serviço de API do cluster está disponível. Um Serviço de API indisponível bloqueia operações de gerenciamento de workload. |
Execute |
|
Blocos CIDR de pod disponíveis insuficientes |
Se o número de blocos CIDR de pod disponíveis em um cluster Flannel é inferior a 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. |
|
|
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 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 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 CoreDNS. Consulte Solução de problemas de DNS. |
|
Status do gateway NAT |
Se o gateway NAT do cluster está funcionando normalmente. Um gateway NAT com falha bloqueia o tráfego de saída para a internet de nós sem IP público. |
Faça login no console do NAT Gateway e verifique se o gateway está bloqueado devido a pagamentos atrasados. |
|
Taxa excessivamente alta de quedas de conexão simultânea no gateway NAT |
Se o gateway NAT 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 gateway NAT. Consulte FAQ sobre atualização de gateways NAT de Internet padrão para gateways NAT de Internet aprimorados. |
ECSControllerManager
|
Item de diagnóstico |
O que é detectado |
Correção |
|
Pagamentos atrasados relacionados a componentes da instância ECS |
Se o disco ou a largura de banda da rede da instância está restrito devido a pagamentos atrasados. Recursos restritos podem causar falhas no workload. |
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 obtenha recursos de CPU e degrade o desempenho. |
Reinicie a instância. |
|
Split locks nas CPUs da instância ECS |
Se há split locks 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 de leitura/gravação limitadas 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 de armazenamento em bloco. |
|
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. |
|
Falhas no SO da instância ECS |
Se ocorreram falhas no 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 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 na 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 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 de linha de base. |
A instância ECS só pode fornecer o desempenho de linha de base 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. |
GPUNode
|
Item de diagnóstico |
O que é detectado |
Correção |
|
Runtime de contêineres |
Se o runtime de contêineres no nó acelerado por GPU é válido. O ACK suporta apenas docker e containerd para nós acelerados por GPU. |
Verifique o status do runtime docker ou containerd no nó. |
|
Versão do NVIDIA-Container-Runtime |
Se a versão do NVIDIA-Container-Runtime é compatível com o cluster. Um NVIDIA-Container-Runtime incompatível ou ausente impede a inicialização de contêineres GPU. |
1. Verifique se a versão do NVIDIA-Container-Runtime corresponde à versão do Kubernetes do cluster. Consulte Notas de lançamento para versões do Kubernetes. 2. Se o problema persistir, colete dados de diagnóstico e envie um ticket. Consulte Coletar dados de diagnóstico de nós acelerados por GPU. |
|
Status do módulo cGPU |
Se o módulo cGPU está em execução conforme esperado em nós com compartilhamento de GPU habilitado. |
1. Verifique se o componente cGPU está instalado. Consulte Instalar o componente de compartilhamento de GPU. 2. Se o módulo ainda falhar, colete dados de diagnóstico e envie um ticket. Consulte Coletar dados de diagnóstico de nós acelerados por GPU. |
|
Configurações do runtime de contêineres |
Se o runtime de contêineres no nó acelerado por GPU está configurado corretamente. Configurações incorretas impedem a execução de contêineres GPU. |
Verifique se o campo |
|
Status do NVIDIA-Container-Runtime |
Se o NVIDIA-Container-Runtime está em execução conforme esperado. |
Colete dados de diagnóstico e envie um ticket. Consulte Coletar dados de diagnóstico de nós acelerados por GPU. |
|
Status do módulo NVIDIA |
Se o módulo de kernel NVIDIA está em execução conforme esperado no nó acelerado por GPU. Um módulo NVIDIA com falha impede a execução de todos os workloads de GPU. |
1. Diagnostique o nó acelerado por GPU. Consulte FAQ sobre GPU. 2. Colete dados de diagnóstico e envie um ticket. Consulte Coletar dados de diagnóstico de nós acelerados por GPU. |