O Container Service for Kubernetes (ACK) oferece o diagnóstico de Pods para ajudar você a investigar Pods anômalos. Cada item de verificação de diagnóstico mapeia para uma solução, permitindo que você identifique e corrija problemas com precisão.
O ACK desenvolveu um sistema de diagnóstico de falhas baseado na experiência de especialistas e treinou um modelo de diagnóstico de falhas com inteligência artificial em grandes volumes de dados. O diagnóstico de Pods combina dois modos de diagnóstico, baseado em especialistas e assistido por IA, para identificar a causa raiz de um problema. O diagnóstico de Pods inclui itens de verificação de diagnóstico e causas raiz de diagnóstico.
Itens de verificação de diagnóstico: incluem a verificação de Pod , verificação de Nó, verificação de NodeComponent, verificação de ClusterComponent , e verificação de ECSControllerManager.
Causas raiz de diagnóstico: incluem as causas raiz identificadas e as correções recomendadas. O diagnóstico de Pods coleta algumas informações do cluster e do nó para identificar anomalias. Em seguida, executa um diagnóstico aprofundado de cada anomalia.
Ao usar o recurso de diagnóstico de falhas, o sistema executa um programa de coleta de dados nos nós do seu cluster e coleta os resultados das verificações. As informações coletadas incluem a versão do sistema, o status de execução de componentes como carga, Docker e kubelet, e mensagens de erro críticas nos logs do sistema. O programa de coleta de dados não coleta suas informações comerciais ou dados confidenciais.
Cenários diagnosticáveis
A tabela a seguir lista os cenários anômalos típicos cobertos pelo diagnóstico de Pods e os cenários suportados pelos diagnósticos assistidos por IA.
|
Categoria |
Cenários anômalos suportados |
|
Diagnóstico de Pods |
O Pod não é processado pelo agendador. |
|
O Pod não pode ser agendado porque não atende às restrições de agendamento. |
|
|
O Pod é agendado, mas não é processado pelo kubelet. |
|
|
O Pod está aguardando um volume ficar pronto. |
|
|
O Pod é despejado. |
|
|
O Pod é despejado devido a espaço em disco insuficiente no nó. |
|
|
O Pod é despejado devido a memória insuficiente no nó. |
|
|
O Pod é despejado devido a inodes insuficientes no nó. |
|
|
A criação do contêiner sandbox do Pod falha. |
|
|
O Pod permanece no estado de finalização por muito tempo. |
|
|
Um contêiner no Pod encontra um erro de falta de memória (OOM). |
|
|
Um contêiner no Pod encerra inesperadamente. |
|
|
Um contêiner no Pod está no estado CrashLoopBackOff. |
|
|
Um contêiner no Pod está NotReady. |
|
|
O Pod encontra um erro ao fazer pull de uma imagem. |
|
|
O Pod atinge o tempo limite ao fazer pull de uma imagem. |
|
|
Diagnósticos assistidos por IA |
O Pod está em um estado anômalo. |
|
O Pod encontra um erro OOM. |
|
|
Um contêiner no Pod encerra inesperadamente. |
|
|
O Pod tem uma configuração inválida de ConfigMap ou Secret. |
|
|
O Pod falha em uma verificação de integridade. |
|
|
O Pod tem uma configuração inválida de Persistent Volume Claim (PVC). |
|
|
O Pod encontra um erro de pull de imagem. |
Fluxo de trabalho de diagnóstico
O diagnóstico de cluster coleta algumas informações do cluster e do nó e, em seguida, identifica anomalias. Cada anomalia passa por um diagnóstico aprofundado. O diagnóstico combina os modos baseado em especialistas e assistido por IA para identificar a causa raiz de um problema com mais precisão. Após você iniciar um diagnóstico, ele passa por quatro estágios: identificação de anomalias, coleta de dados, avaliação de itens de verificação e análise de causa raiz. Em seguida, fornece os resultados do diagnóstico.
Identificação de anomalias: coleta dados básicos, como status do nó, status do Pod e o fluxo de eventos do cluster. Em seguida, analisa rapidamente as anomalias atuais.
Coleta de dados: coleta dados relacionados ao contexto de diagnóstico com base nos resultados da identificação de anomalias. Por exemplo, o diagnóstico de nó coleta informações sobre o nó no Kubernetes, a instância ECS que corresponde ao nó e o status de execução de processos como Docker e kubelet no nó.
Avaliação de itens de verificação: determina se as métricas principais estão normais com base nos dados coletados. Por exemplo, os itens de verificação de diagnóstico de nó incluem o status do processo Docker e o status da ECS. Diferentes tipos de diagnóstico usam diferentes itens de verificação. Para cada resultado de verificação, o diagnóstico fornece a lista de itens de verificação e o significado de cada item.
Análise de causa raiz: determina automaticamente a causa de alguns problemas com base nos dados coletados e nos itens de verificação.
Resultados do diagnóstico
Os resultados se dividem 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 os resultados de verificação por item. Estes podem revelar causas que a análise de causa raiz pode não detectar.
Os itens de diagnóstico variam de acordo com a configuração do cluster e refletem a configuração real do seu cluster.
Itens de verificação para diagnóstico de Pods
|
Grupo de itens de diagnóstico |
Descrição |
|
Verifica problemas comuns de Pods. Os itens de verificação incluem status do Pod, pull de imagem e conectividade de rede. |
|
|
Verifica problemas comuns em instâncias de nó. Os itens de verificação incluem status do nó, status da rede, logs do kernel e a disponibilidade de processos e serviços principais. |
|
|
Verifica o status dos componentes principais do nó. Os itens de verificação incluem plugins de rede e armazenamento. |
|
|
Verifica problemas comuns de cluster. Os itens de verificação incluem disponibilidade do API Service, disponibilidade do DNS e status do gateway NAT. |
|
|
Verifica problemas comuns em instâncias ECS. Os itens de verificação incluem status da instância ECS, links de rede, sistema operacional e I/O de disco. |
Pod
|
Nome do item de verificação |
Descrição do item de verificação |
Solução |
|
Contagem de reinicializações de contêiner do Pod |
Conta o número de vezes que os contêineres no Pod reiniciam. |
Verifique o status e os logs do Pod. Para mais informações, consulte Pod troubleshooting. |
|
Baixe de imagem de contêiner do Pod bloqueado |
Verifica se o baixe da imagem do contêiner de outro Pod no mesmo nó está bloqueado. |
Verifique o status e os logs do Pod. Para mais informações, consulte Pod troubleshooting. |
|
Validade do Secret de pull de imagem do Pod |
Verifica se os Secrets que o Pod usa para fazer pull de imagens são válidos. |
Verifique o status e os logs do Pod. Para mais informações, consulte Pod troubleshooting. |
|
Validade de variável de ambiente de Pod GPU |
Verifica se NVIDIA_VISIBLE_DEVICES está presente nas variáveis de ambiente do Pod, pois essa variável pode entrar em conflito com o kubelet. |
Verifique o status e os logs do Pod. Para mais informações, consulte Pod troubleshooting. |
|
Conectividade entre o Pod e os Pods do CoreDNS |
Verifica a conectividade entre o Pod e os Pods do CoreDNS. |
Verifique a conectividade entre o Pod e os Pods do CoreDNS. |
|
Conectividade entre o Pod e o Service do CoreDNS |
Verifica a conectividade entre o Pod e o Service do CoreDNS. |
Verifique a conectividade entre o Pod e os Pods do CoreDNS. |
|
Conectividade entre o Pod e o servidor DNS na rede do host |
Verifica a conectividade entre o Pod e o servidor DNS na rede do host. |
Verifique a conectividade entre o Pod e o servidor DNS na rede do host. |
|
Verificação de estado D de processo de contêiner do Pod |
Verifica se um processo de contêiner no Pod está no estado D. |
Alguns processos de contêiner no Pod estão no estado D, geralmente porque estão bloqueados em I/O de disco. Tente reiniciar a instância ECS do host. |
|
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 Pod troubleshooting. |
|
Recursos de GPU solicitados pelo Pod |
Verifica se o Pod solicita recursos de GPU. Isso descarta a falta de solicitação de recursos de GPU como o motivo pelo qual o Pod não pode usar uma GPU. |
Nenhum recurso de GPU está declarado no Pod. Se necessário, verifique se a configuração do Pod está correta. |
|
Status de agendamento do Pod |
Verifica se o Pod foi agendado corretamente. |
Nenhum recurso de GPU está declarado no Pod. Se necessário, verifique se a configuração do Pod está correta. |
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 detecta |
Correção |
|
Erros de conectividade com o servidor de API do Kubernetes |
Se o nó pode alcançar o servidor de API do cluster. |
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ó. |
|
|
Erros BufferIOError |
Se há erros BufferIOError presentes no kernel do nó. |
|
|
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 pode afetar a sincronização do relógio do sistema. |
Execute |
|
Pull de imagem pelo containerd |
Se o runtime containerd pode fazer pull de 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. |
|
|
Disponibilidade do pod CoreDNS |
Se o nó pode alcançar o endereço IP do pod CoreDNS. |
Verifique se o nó pode acessar o endereço IP do pod CoreDNS. Consulte What do I do if the DNS query load is not balanced among CoreDNS pods?. |
|
Status da imagem |
Se as imagens estão intactas. |
|
|
Status overlay2 das imagens |
Se o sistema de arquivos overlay2 nas imagens está danificado. |
|
|
Hora do sistema |
Se o relógio do sistema está preciso. |
Nenhuma. |
|
Inicialização de contêiner Docker |
Se os contêineres Docker estão falhando ao iniciar. |
|
|
Pull de imagem Docker |
Se o nó pode fazer pull de 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. |
|
|
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ó. |
Execute |
|
Existência da instância ECS |
Se a instância ECS subjacente existe. |
Verifique o status da instância ECS. Consulte FAQ about nodes and node pools. |
|
Status da instância ECS |
Se a instância ECS está em um estado íntegro. |
Verifique o status da instância ECS. Consulte FAQ about nodes and node pools. |
|
Erros Ext4FsError |
Se há erros Ext4FsError presentes 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 de disco e bloqueia todas as operações de gravação, afetando as cargas de trabalho. |
Execute |
|
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 de componentes. |
Execute |
|
DNS do nó |
Se os nomes de domínio podem ser resolvidos no nó. |
Consulte DNS troubleshooting. |
|
Erros oops do kernel |
Se há erros oops presentes no kernel do nó. |
|
|
Versões do kernel |
Se a versão do kernel está desatualizada. Kernels desatualizados podem ter problemas de estabilidade conhecidos. |
Atualize o kernel do nó. Consulte FAQ about nodes and node pools. |
|
Disponibilidade do DNS do cluster |
Se o nó pode alcançar o IP do cluster do Service kube-dns para usar o service DNS do cluster. |
Verifique o status e os logs dos pods CoreDNS. Consulte DNS troubleshooting. |
|
Status do kubelet |
Se o kubelet está executando normalmente. |
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ó. |
Faça login no nó e execute |
|
Memória swap |
Se a memória swap está ativada. |
Faça login no nó e desative a memória swap. |
|
Carregamento de drivers de dispositivo de rede |
Se os drivers VirtIO em dispositivos de rede são carregados corretamente. |
|
|
Utilização de CPU excessivamente alta do nó |
Se a utilização de CPU esteve alta na última semana. Se muitos pods forem agendados em um nó com uso de CPU consistentemente alto, a contenção de recursos pode resultar em interrupções de service. |
Defina as 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. |
Remova o nó do cluster e adicione-o novamente. Não libere a instância ECS ao removê-lo. Consulte Remove a node e Add existing ECS instances. |
|
Utilização de memória excessivamente alta do nó |
Se a utilização de memória esteve alta na última semana. A alta utilização de memória combinada com agendamento pesado de pods pode causar erros de falta de memória (OOM) e interrupções de service. |
Defina as 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 about nodes and node pools. |
|
Agendabilidade do nó |
Se o nó está marcado como não agendável. |
Verifique a configuração de agendamento do nó. Consulte Node draining and scheduling status. |
|
Erros OOM |
Se erros de falta de memória (OOM) estão ocorrendo no nó. |
|
|
Verificação de runtime |
Se o runtime de contêiner do nó corresponde ao runtime configurado do cluster. |
Consulte Can I change the container runtime of a cluster from containerd to Docker?. |
|
Versões de SO desatualizadas |
Se a versão do SO do nó tem bugs conhecidos ou problemas de estabilidade. Versões de SO desatualizadas podem fazer com que os runtimes Docker e containerd funcionem mal. |
Atualize a versão do SO. |
|
Acesso à internet |
Se o nó pode acessar a internet. |
Ative o SNAT para o cluster. Consulte Enable an existing ACK cluster to access the internet. |
|
Erros RCUStallError |
Se há erros RCUStallError presentes no kernel do nó. |
|
|
Versões do SO |
A versão do SO usada pelo nó. Versões de SO desatualizadas podem impedir que o cluster opere normalmente. |
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ó. |
|
|
Travamentos do systemd |
Se há travamentos do systemd ocorrendo. |
Faça login no nó e execute |
|
Versões desatualizadas do systemd |
Se a versão do systemd tem bugs conhecidos. Versões desatualizadas podem fazer com que o Docker e o containerd funcionem mal. |
Atualize a versão do systemd. Consulte systemd. |
|
Processos travados |
Se existem processos travados no nó. |
|
|
Erros unregister_netdevice |
Se há erros unregister_netdevice presentes no kernel do nó. |
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. |
Verifique o status do componente de rede do cluster. Consulte FAQ about network management. |
|
Status do componente CSI |
Se o plugin Container Storage Interface (CSI) está executando conforme esperado. |
Verifique o status do componente de armazenamento do cluster. Consulte FAQ about 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 Use the aliyun-acr-credential-helper component to pull images without using a secret. |
|
Disponibilidade do API Service |
Se o API Service do cluster está disponível. |
Execute |
|
Blocos CIDR de pod disponíveis insuficientes |
Se restam menos de cinco blocos CIDR de pod em um cluster Flannel. Cada nó usa um bloco, então, quando acabam, novos nós não podem funcionar corretamente. |
|
|
Endpoints do CoreDNS |
O número de endpoints ativos do CoreDNS. |
Verifique o status e os logs dos pods CoreDNS. Consulte DNS troubleshooting. |
|
Endereços IP de cluster do CoreDNS |
Se o Service DNS do cluster tem um ClusterIP atribuído. Sem ele, o DNS do cluster falha e as cargas de trabalho são afetadas. |
Verifique o status e os logs dos pods CoreDNS. Consulte DNS troubleshooting. |
|
Status do gateway NAT |
Se o gateway NAT do cluster está funcionando normalmente. |
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ões simultâneas no gateway NAT |
Se o gateway NAT está derrubando uma taxa anormalmente alta de conexões simultâneas. |
Faça o upgrade do gateway NAT. Consulte FAQ sobre o upgrade de gateways NAT de Internet padrão para gateways NAT 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 da rede da instância está restrito devido a pagamentos atrasados. | 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, em seguida, 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. | 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. Reinicie a instância. |
Split locks nas CPUs da instância ECS | Se há split locks ocorrendo nas CPUs da instância ECS. | Há split locks ocorrendo nas CPUs da instância ECS. |
Status da mitigação de DDoS para a instância ECS | Se o endereço IP público da instância está sob um ataque DDoS. | Adquira um service anti-DDoS. Consulte Comparison of Alibaba Cloud Anti-DDoS solutions. |
Capacidades de leitura/gravação limitadas do disco em cloud | Se o throughput de leitura/gravação do disco em cloud está sendo limitado. | Reduza a frequência de leitura/gravação do disco ou faça o upgrade para um tipo de disco em cloud de maior desempenho. Para mais informações sobre as métricas de desempenho de leitura/gravação de discos em cloud, consulte Block storage performance. |
Carregamento do disco da instância ECS | Se o disco em cloud 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 de assinatura expirou. | Renove a instância. Consulte Renovar uma instância de 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 View system logs and screenshots. |
Status do host da instância ECS | Se o servidor físico que hospeda a instância tem 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 pode carregar sua imagem durante a inicialização. | Reinicie a instância. |
Travamentos de I/O no disco da instância ECS | Se há travamentos de I/O ocorrendo no disco do sistema. | Verifique as métricas do disco. Consulte View the monitoring data of a cloud disk. Para Alibaba Cloud Linux 2, consulte Detect I/O hangs of file systems and block layers. |
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. | Faça o upgrade para um tipo de instância com maior largura de banda. Consulte Overview of instance configuration changes. |
Limite superior da largura de banda de burst da instância ECS | Se a largura de banda de burst da instância excedeu o máximo permitido para seu tipo de instância. | Faça o upgrade para um tipo de instância com maior largura de banda. Consulte Overview of instance configuration changes. |
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 as sessões podem ser estabelecidas na NIC. | Se a NIC não puder 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 principais na instância ECS | Se as operações recentes na instância — como iniciar, parar ou fazer upgrade — 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. | 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 View historical system events. |
Desempenho comprometido da instância ECS | Se o desempenho da instância está reduzido. | A instância ECS pode fornecer apenas 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 SO falhou ao redimensionar o sistema de arquivos após o redimensionamento do disco, portanto, o espaço adicionado não está disponível. Redimensione o disco 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. | Recursos físicos insuficientes impedem que a instância inicie. Aguarde alguns minutos e tente iniciar a instância novamente. Se o problema persistir, crie uma instância em uma região ou zona diferente. |
Status do SO da instância ECS | Se ocorreram kernel panics, erros OOM ou falhas internas no SO da instância. | Essas falhas são frequentemente causadas por configurações de instância incorretas ou programas de usuário. Reinicie a instância. |
Status de virtualização da instância ECS | Se há exceções na camada de virtualização subjacente. | Essas exceções podem fazer com que a instância pare de responder ou seja suspensa inesperadamente. Reinicie a instância. |