Todos os produtos
Search
Central de documentação

Container Service for Kubernetes:Diagnóstico de nós

Última atualização: Jun 27, 2026

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:

Node diagnostics

  1. Anomaly identification: Coleta sinais básicos — status do nó, status do pod e fluxos de eventos do cluster — e identifica anomalias.

  2. 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.

  3. 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.

  4. 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

NodeComponent

Status de componentes essenciais do nó, incluindo componentes de rede e armazenamento

ClusterComponent

Disponibilidade do servidor de API, disponibilidade de dns e status do gateway NAT

ECSControllerManager

Status da instância ECS, conexões de rede, integridade do sistema operacional e E/S de disco

GPUNode

Status do módulo NVIDIA e configurações de runtime de contêineres em nós acelerados por GPU

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ó.

Envie um ticket.

Erros BufferIOError

Se existem erros BufferIOError no kernel do nó.

Envie um ticket.

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 systemctl restart chronyd para reiniciar o processo.

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.

Envie 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 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.

Envie um ticket.

Status overlay2 das imagens

Se o sistema de arquivos overlay2 nas imagens está corrompido.

Envie 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.

Envie um ticket.

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.

Envie 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 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 existem erros Ext4FsError no kernel do nó.

Envie 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 escrita, afetando os workloads.

Execute fsck para reparar o sistema de arquivos e reinicie o nó.

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 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 de kernel oops

Se existem erros oops no kernel do nó. Estes indicam caminhos de código inesperados e podem causar instabilidade.

Envie 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 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 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.

Envie um ticket.

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.

Envie um ticket.

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ó.

Envie 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. 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ó.

Envie um ticket.

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 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ó.

Envie um ticket.

Erros unregister_netdevice

Se existem erros unregister_netdevice no kernel do nó. Estes podem causar vazamentos de recursos do kernel e instabilidade na rede.

Envie um ticket.

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 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 é 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.

Envie 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 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 nvidia-container-runtime está especificado no arquivo de configuração do runtime: docker — /etc/docker/daemon.json; containerd — /etc/containerd/config.toml.

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.