Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
A integridade do nó refere-se ao status operacional e à capacidade de um nó executar workloads com eficiência. Um nó íntegro mantém a conectividade esperada, tem recursos suficientes e pode executar pods com sucesso sem interrupções. Para obter informações sobre como obter detalhes sobre os nós, consulte Visualizar o status de integridade dos nós e Recuperar logs de nós de um nó gerenciado usando kubectl e S3.
Para ajudar a manter os nós íntegros, o Amazon EKS oferece o agente de monitoramento de nós e o reparo automático de nós.
Agente de monitoramento de nós
O agente de monitoramento de nós lê automaticamente os logs dos nós para detectar determinados problemas de integridade. Ele analisa os logs dos nós para detectar falhas e apresenta várias informações de status sobre os nós de processamento. Uma NodeCondition dedicada é aplicada nos nós de processamento para cada categoria de problemas detectados, como problemas de armazenamento e rede. As descrições dos problemas de integridade detectados são disponibilizadas no painel de observabilidade. Para ter mais informações, consulte Problemas de integridade de nós.
O agente de monitoramento de nós está incluído como um recurso para todos os clusters do Modo Automático do Amazon EKS. Para outros tipos de cluster, você pode adicionar o agente de monitoramento como um complemento do Amazon EKS. Para ter mais informações, consulte Criar um complemento do Amazon EKS.
Reparo automático de nós
O reparo automático de nós é um recurso adicional que monitora continuamente a integridade dos nós, reagindo automaticamente aos problemas detectados e substituindo os nós quando possível. Isso ajuda na disponibilidade geral do cluster com o mínimo de intervenção manual. Se uma verificação de integridade falhar, o nó será automaticamente isolado para que nenhum novo pod seja programado no nó.
Por si só, o reparo automático de nós pode reagir à condição Ready do kubelet e a quaisquer objetos de nós que sejam excluídos manualmente. Quando combinado com o agente de monitoramento de nós, o reparo automático de nós pode reagir a mais condições que não seriam detectadas de outra forma. Essas condições adicionais incluem KernelReady, NetworkingReady e StorageReady.
Essa recuperação automatizada de nós resolve automaticamente problemas de nós intermitentes, como falhas na união ao cluster, kubelets que não respondem e aumento de erros no acelerador (dispositivo). A confiabilidade aprimorada ajuda a reduzir o tempo de inatividade da aplicação e a melhorar as operações do cluster. O reparo automático de nós não pode lidar com certos problemas relatados, como DiskPressure, MemoryPressure e PIDPressure. O Amazon EKS espera dez minutos antes de agir nas NodeConditions AcceleratedHardwareReady, e 30 minutos para todas as outras condições.
Os grupos de nós gerenciados também desabilitarão automaticamente os reparos de nós por motivos de segurança em dois cenários. Quaisquer operações de reparo que estejam previamente em andamento continuarão em ambas as situações.
-
Se uma mudança de zona para o cluster tiver sido acionada por meio do Application Recovery Controller (ARC), todas as operações de reparo subsequentes serão interrompidas.
-
Se o grupo de nós tiver mais de cinco nós, e mais de 20% dos nós no grupo de nós estiverem em um estado não íntegro, as operações de reparo serão interrompidas.
Você pode habilitar o reparo automático de nós ao criar ou editar um grupo de nós gerenciados.
-
Ao usar o console do Amazon EKS, ative a caixa de seleção Habilitar reparo automático de nós para o grupo de nós gerenciados. Para ter mais informações, consulte Criar um grupo de nós gerenciados para seu cluster.
-
Ao usar a AWS CLI, adicione
--node-repair-config enabled=trueao comandoeks create nodegroupoueks update-nodegroup-config. -
Para ver um exemplo do
ClusterConfigeksctlque usa um grupo de nós gerenciados com reparo automático de nós, consulte 44-node-repair.yamlno GitHub.
Problemas de integridade de nós
As tabelas a seguir descrevem problemas de integridade de nós que podem ser detectados pelo agente de monitoramento de nós. Há dois tipos de problemas:
-
Condição: um problema terminal que justifica uma ação de remediação, como a substituição ou reinicialização de uma instância. Quando o reparo automático estiver habilitado, o Amazon EKS executará uma ação de reparo, seja uma substituição ou uma reinicialização do nó. Para ter mais informações, consulte Condições de nós.
-
Evento: um problema temporário ou uma configuração de nós abaixo do ideal. Nenhuma ação de reparo automático ocorrerá. Para ter mais informações, consulte Eventos de nós.
Problemas de integridade de nós do kernel
| Name | Gravidade | Descrição |
|---|---|---|
|
ForkFailedOutOfPID |
Condição |
Uma chamada fork ou exec falhou porque o sistema ficou sem IDs de processo ou memória, o que pode ser causado por processos zumbis ou esgotamento da memória física. |
|
AppBlocked |
Event |
A tarefa foi bloqueada da programação por um longo período, o que geralmente ocorre devido a um bloqueio na entrada ou na saída. |
|
AppCrash |
Event |
Uma aplicação no nó falhou. |
|
ApproachingKernelPidMax |
Event |
O número de processos está se aproximando do número máximo de PIDs disponíveis, de acordo com a configuração atual de kernel.pid_max, após o qual nenhum outro processo poderá ser iniciado. |
|
ApproachingMaxOpenFiles |
Event |
O número de arquivos abertos está se aproximando do número máximo de arquivos abertos possíveis, de acordo com as configurações atuais do kernel, após o qual a abertura de novos arquivos falhará. |
|
ConntrackExceededKernel |
Event |
O rastreamento de conexões excedeu o máximo para o kernel e novas conexões não puderam ser estabelecidas, o que pode resultar em perda de pacotes. |
|
ExcessiveZombieProcesses |
Event |
Processos que não podem ser totalmente recuperados estão se acumulando em grandes números, o que indica problemas na aplicação e pode levar a atingir os limites de processos do sistema. |
|
KernelBug |
Event |
Um bug do kernel foi detectado e relatado pelo próprio Kernel Linux, embora às vezes isso possa ser causado por nós com alto uso de CPU ou memória, levando ao atraso no processamento de eventos. |
|
LargeEnvironment |
Event |
O número de variáveis de ambiente para esse processo é maior do que o esperado, provavelmente causado por muitos serviços com enableServiceLinks definido como true, o que pode causar problemas de performance. |
|
RapidCron |
Event |
Um cron job está sendo executado com uma frequência maior que a cada cinco minutos neste nó, o que poderá afetar a performance se o trabalho consumir recursos significativos. |
|
SoftLockup |
Event |
A CPU ficou paralisada por um determinado período de tempo. |
Problemas de integridade de nós de rede
| Name | Gravidade | Descrição |
|---|---|---|
|
InterfaceNotRunning |
Condição |
Esta interface parece não estar funcionando ou há problemas de rede. |
|
InterfaceNotUp |
Condição |
Esta interface parece não estar ativa ou há problemas de rede. |
|
IPAMDNotReady |
Condição |
O IPAMD não consegue se conectar ao servidor da API. |
|
IPAMDNotRunning |
Condição |
O processo |
|
MissingLoopbackInterface |
Condição |
A interface de loopback está ausente nesta instância, causando falha nos serviços que dependem da conectividade local. |
|
BandwidthInExceeded |
Event |
Os pacotes foram enfileirados ou descartados porque a largura de banda agregada de entrada excedeu o máximo para a instância. |
|
BandwidthOutExceeded |
Event |
Os pacotes foram enfileirados ou descartados porque a largura de banda agregada de saída excedeu o máximo para a instância. |
|
ConntrackExceeded |
Event |
O rastreamento de conexões excedeu o máximo para a instância e novas conexões não puderam ser estabelecidas, o que pode resultar em perda de pacotes. |
|
IPAMDNoIPs |
Event |
O IPAM-D está sem endereços IP. |
|
IPAMDRepeatedlyRestart |
Event |
Ocorreram várias reinicializações no serviço do IPAMD. |
|
KubeProxyNotReady |
Event |
O kube-proxy falhou ao observar ou listar recursos. |
|
LinkLocalExceeded |
Event |
Os pacotes foram descartados porque o PPS do tráfego para os serviços de proxy local excedeu o máximo para a interface da rede. |
|
MissingDefaultRoutes |
Event |
Há regras de rota padrão ausentes. |
|
MissingIPRules, MissingIPRoutes |
Event |
Há regras de rota ausentes para os IPs de pods a seguir na tabela de rotas. |
|
NetworkSysctl |
Event |
As configurações de sysctl da rede deste nó estão provavelmente incorretas. |
|
PortConflict |
Event |
Caso um pod use hostPort, ele pode escrever regras de iptables que substituem as portas já vinculadas do host, o que pode impedir o acesso do servidor de API ao |
|
PPSExceeded |
Event |
Os pacotes foram enfileirados ou descartados porque o PPS bidirecional excedeu o máximo para a instância. |
|
UnexpectedRejectRule |
Event |
Uma regra |
Problemas de integridade do nó Neuron
| Name | Gravidade | Descrição |
|---|---|---|
|
NeuronDMAError |
Condição |
Um mecanismo de DMA encontrou um erro irrecuperável. |
|
NeuronHBMUncorrectableError |
Condição |
Um HBM encontrou um erro incorrigível e produziu resultados incorretos. |
|
NeuronNCUncorrectableError |
Condição |
Foi detectado um erro de memória incorrigível do Neuron Core. |
|
NeuronSRAMUncorrectableError |
Condição |
Uma SRAM no chip encontrou um erro de paridade e produziu resultados incorretos. |
Problemas de integridade do nó NVIDIA
Se o reparo automático estiver habilitado, as ações de reparo listadas serão iniciadas dez minutos após a detecção do problema. Para obter mais informações sobre erros do XID, consulte Xid Errors
| Name | Gravidade | Descrição | Ação de reparo |
|---|---|---|---|
|
NvidiaDoubleBitError |
Condição |
Um erro de dois bits foi produzido pelo driver da GPU. |
Substituir |
|
NvidiaNVLinkError |
Condição |
Erros do NVLink foram relatados pelo driver da GPU. |
Substituir |
|
NvidiaXID13Error |
Condição |
Há uma exceção no mecanismo gráfico. |
Reinicializar |
|
NvidiaXID31Error |
Condição |
Há suspeitas de problemas de hardware. |
Reinicializar |
|
NvidiaXID48Error |
Condição |
Erros de ECC de dois bits foram relatados pelo driver. |
Reinicializar |
|
NvidiaXID63Error |
Condição |
Há uma inativação da página ou um remapeamento da linha. |
Reinicializar |
|
NvidiaXID64Error |
Condição |
Há falhas ao tentar inativar uma página ou realizar um remapeamento de nós. |
Reinicializar |
|
NvidiaXID74Error |
Condição |
Há um problema com a conexão da GPU com outra GPU ou NVSwitch via NVLink. Isso pode indicar uma falha de hardware no próprio link ou um problema com o dispositivo na extremidade remota do link. |
Substituir |
|
NvidiaXID79Error |
Condição |
O driver da GPU tentou acessar a GPU pela conexão PCI Express e descobriu que a GPU não está acessível. |
Substituir |
|
NvidiaXID94Error |
Condição |
Há erros de memória ECC. |
Reinicializar |
|
NvidiaXID95Error |
Condição |
Há erros de memória ECC. |
Reinicializar |
|
NvidiaXID119Error |
Condição |
O GSP atingiu o tempo limite de resposta às solicitações RPC de outros bits no driver. |
Substituir |
|
NvidiaXID120Error |
Condição |
O GSP respondeu a tempo, mas com um erro. |
Substituir |
|
NvidiaXID121Error |
Condição |
O C2C é uma interconexão de chips. Ele permite compartilhar memória entre CPUs, aceleradores e muito mais. |
Substituir |
|
NvidiaXID140Error |
Condição |
O driver da GPU pode ter observado erros incorrigíveis na memória da GPU, o que levou a interromper a capacidade do driver da GPU de marcar as páginas para desativação dinâmica de páginas ou remapeamento de linhas. |
Substituir |
|
NvidiaPageRetirement |
Event |
O driver da GPU marcou uma página de memória para retirada. Isso poderá ocorrer se houver um único erro de bit duplo ou se dois erros de bit único forem encontrados no mesmo endereço. |
Nenhum |
|
NvidiaXID[Code]Warning |
Event |
Qualquer ocorrência de XIDs diferente das definidas nesta lista resultará nesse evento. |
Nenhum |
Problemas de integridade do nó de runtime
| Name | Gravidade | Descrição |
|---|---|---|
|
PodStuckTerminating |
Condição |
Um pod está ou estava preso no encerramento por um tempo excessivo, o que pode ser causado por erros de CRI impedindo a progressão do estado do pod. |
|
%sRepeatedRestart |
Event |
Reinicializações de qualquer serviço do systemd no nó (formatado usando o nome da unidade em formato title case). |
|
ContainerRuntimeFailed |
Event |
O runtime do contêiner falhou ao criar um contêiner, provavelmente relacionado a quaisquer problemas relatados, caso tenham ocorrido repetidamente. |
|
KubeletFailed |
Event |
O kubelet entrou em um estado de falha. |
|
LivenessProbeFailures |
Event |
Uma falha na sonda de liveness foi detectada, possivelmente indicando problemas no código da aplicação ou valores de tempo limite insuficientes, caso tenham ocorrido repetidamente. |
|
ReadinessProbeFailures |
Event |
Uma falha na sonda de readiness foi detectada, possivelmente indicando problemas no código da aplicação ou valores de tempo limite insuficientes, caso tenham ocorrido repetidamente. |
|
ServiceFailedToStart |
Event |
Uma unidade do systemd falhou ao iniciar. |
Problemas de integridade do nó de armazenamento
| Name | Gravidade | Descrição |
|---|---|---|
|
XFSSmallAverageClusterSize |
Condição |
O tamanho médio do cluster do XFS é pequeno, indicando uma fragmentação excessiva do espaço livre que pode impedir a criação de arquivos, apesar dos inodes ou do espaço livre disponíveis. |
|
EtcHostsMountFailed |
Event |
A montagem do kubelet gerado |
|
IODelays |
Event |
Atraso de entrada ou saída detectado em um processo, possivelmente indicando provisionamento insuficiente de entrada-saída, se excessivo. |
|
KubeletDiskUsageSlow |
Event |
O Kubelet está relatando um uso lento do disco ao tentar acessar o sistema de arquivos, possivelmente indicando problemas de entrada-saída insuficiente do disco ou problemas no sistema de arquivos. |
