Habilitar o reparo automático de nós e investigar os problemas de integridade de nós - Amazon EKS
Agente de monitoramento de nósReparo automático de nósProblemas de integridade de nós

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.

Habilitar o reparo automático de nós e investigar os problemas de integridade de nós

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.

Importante

O agente de monitoramento de nós e o reparo automático de nós estão disponíveis somente no Linux. Estes recursos não estão disponíveis no Windows.

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

O Amazon EKS fornece um controle mais detalhado sobre o comportamento de reparo automático de nós por meio dos seguintes itens:

  • maxUnhealthyNodeThresholdCount e da maxUnhealthyNodeThresholdPercentage

    • Com esses campos, você pode definir um limite para o número ou porcentagem de nós com problemas de integridade. Caso esse limite seja ultrapassado, as ações de reparo automático de nós são suspensas. Isso garante maior controle sobre o “raio de impacto” dos reparos automáticos.

    • É possível configurar a contagem absoluta ou a porcentagem, mas nunca as duas simultaneamente.

  • maxParallelNodesRepairedCount e da maxParallelNodesRepairedPercentage

    • Esses campos permitem especificar o número máximo de nós que podem ser reparados simultaneamente ou em paralelo, expresso como um valor absoluto ou uma porcentagem de todos os nós não íntegros. Isso proporciona um controle mais detalhado da velocidade das substituições de nós.

    • Assim como ocorre no limite de nós não íntegros, é possível configurar a contagem absoluta ou a porcentagem, mas nunca as duas simultaneamente.

  • nodeRepairConfigOverrides

    • Esta é uma estrutura complexa que permite configurar substituições granulares para ações de reparo específicas. Essas substituições controlam a ação de reparo e o tempo de espera antes que um nó seja considerado apto para o processo de reparo.

    • Os campos específicos nesta estrutura são:

      • nodeMonitoringCondition: a condição de não integridade relatada pelo agente de monitoramento do nó.

      • nodeUnhealthyReason: o motivo pelo qual o agente de monitoramento do nó identificou o nó como não íntegro.

      • minRepairWaitTimeMins: o tempo mínimo (em minutos) que a condição de reparo e o motivo da não integridade devem persistir antes que o nó seja elegível para reparo.

      • repairAction: a ação que o sistema de reparo deve realizar quando as condições acima forem atendidas.

    • Ao utilizar este campo, é necessário especificar todos os campos na estrutura. Além disso, você pode fornecer uma lista dessas substituições.

    • O nodeMonitoringCondition e o nodeUnhealthyReason são campos de entrada de texto manual que você define para indicar que deseja divergir do comportamento padrão do sistema.

    • Os campos minRepairWaitTimeMins e repairAction permitem que você especifique divergências em relação ao comportamento padrão do sistema.

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 obter 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 obter mais informações, consulte Eventos de nós.

Problemas de integridade de nós com AcceleratedHardware

Para os problemas listados na tabela abaixo com gravidade do tipo “Condição”, a condição de monitoramento utilizada é AcceleratedHardwareReady.

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 na Documentação de implantação e gerenciamento da GPU NVIDIA. Para obter mais informações sobre as mensagens individuais do XID, consulte Understanding Xid Messages na Documentação de implantação e gerenciamento da GPU NVIDIA.

Nome Gravidade Descrição

DCGMDiagnosticFailure

Condição

Um caso de teste do conjunto de testes de diagnóstico ativo do DCGM falhou.

DCGMError

Condição

Houve perda de conexão com o processo host do DCGM ou não foi possível estabelecê-la.

DCGMFieldError[Code]

Event

O DCGM detectou degradação da GPU por meio de um identificador de campo.

DCGMHealthCode[Code]

Event

Uma verificação de integridade do DCGM falhou de forma não fatal.

DCGMHealthCode[Code]

Condição

Uma verificação de integridade do DCGM falhou de forma fatal.

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.

NvidiaDeviceCountMismatch

Event

O número de GPUs visíveis por meio da biblioteca NVML é inconsistente com o número de dispositivos da NVIDIA no sistema de arquivos.

NvidiaDoubleBitError

Condição

Um erro de dois bits foi produzido pelo driver da GPU.

NvidiaNCCLError

Event

Ocorreu uma falha de segmentação na NVIDIA Collective Communications Library (libnccl).

NvidiaNVLinkError

Condição

Erros do NVLink foram relatados pelo driver da GPU.

NvidiaPCIeError

Event

As retransmissões de PCIe foram acionadas para a recuperação de erros de transmissão.

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.

NvidiaPowerError

Event

O uso de energia pelas GPUs ultrapassou os limites permitidos.

NvidiaThermalError

Event

O status térmico das GPUs ultrapassou os limites permitidos.

NvidiaXID[Code]Error

Condição

Ocorreu um erro crítico relacionado com a GPU.

NvidiaXID[Code]Warning

Event

Ocorreu um erro não crítico relacionado com a GPU.

Problemas de integridade de nós com ContainerRuntime

Para os problemas listados na tabela abaixo com gravidade do tipo “Condição”, a condição de monitoramento utilizada é ContainerRuntimeReady.

Nome Gravidade Descrição

ContainerRuntimeFailed

Event

O runtime do contêiner falhou ao criar um contêiner, provavelmente relacionado a quaisquer problemas relatados, caso tenham ocorrido repetidamente.

DeprecatedContainerdConfiguration

Event

Uma imagem de contêiner usando a versão do manifesto de imagem obsoleta (versão 2 e esquema 1) foi extraída recentemente para o nó por meio do containerd.

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.

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.

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.

[Name]RepeatedRestart

Event

Uma unidade do systemd está reiniciando com frequência.

ServiceFailedToStart

Event

Uma unidade do systemd falhou ao iniciar.

Problemas de integridade de nós do kernel

Para os problemas listados na tabela abaixo com gravidade do tipo “Condição”, a condição de monitoramento utilizada é KernelReady.

Nome Gravidade Descrição

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

A quantidade de processos está chegando ao limite máximo de PIDs permitido pela atual configuração kernel.pid_max do sistema. Se esse limite for atingido, não será possível iniciar novos processos.

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.

ForkFailedOutOfPIDs

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.

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 este processo é maior do que o esperado. Isso pode ser causado pelo excesso de serviços com a configuração enableServiceLinks definida como “verdadeira”, resultando em possíveis 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

Para os problemas listados na tabela abaixo com gravidade do tipo “Condição”, a condição de monitoramento utilizada é NetworkingReady.

Nome Gravidade Descrição

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.

IPAMDInconsistentState

Event

O arquivo de ponto de verificação do IPAMD, no disco, está inconsistente com os endereços IP registrados no runtime do contêiner.

IPAMDNoIPs

Event

O IPAMD está sem endereços IP disponíveis.

IPAMDNotReady

Condição

O IPAMD não consegue se conectar ao servidor da API.

IPAMDNotRunning

Condição

Não foi possível localizar o processo da CNI do Amazon VPC em execução no sistema.

IPAMDRepeatedlyRestart

Event

Ocorreram várias reinicializações no serviço do IPAMD.

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.

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.

MACAddressPolicyMisconfigured

Event

O valor definido para MACAddressPolicy na configuração de link do systemd-networkd está incorreto.

MissingDefaultRoutes

Event

Há regras de rota padrão ausentes.

MissingIPRoutes

Event

Existem rotas ausentes para os endereços IP dos pods.

MissingIPRules

Event

Existem regras ausentes para os endereços IP dos pods.

MissingLoopbackInterface

Condição

A interface de loopback está ausente nesta instância, causando falha nos serviços que dependem da conectividade local.

NetworkSysctl

Event

As configurações de sysctl da rede deste nó podem estar configuradas incorretamente.

PPSExceeded

Event

Os pacotes foram enfileirados ou descartados porque o PPS bidirecional excedeu o máximo para a instância.

PortConflict

Event

Se um pod usar hostPort, ele pode gravar regras de iptables que substituem as portas já vinculadas do host. Isso pode bloquear a comunicação entre o servidor de API e o kubelet.

UnexpectedRejectRule

Event

Uma regra inesperada de REJECT ou DROP foi encontrada no iptables, o que pode estar bloqueando o tráfego esperado.

Problemas de integridade do nó de armazenamento

Para os problemas listados na tabela abaixo com gravidade do tipo “Condição”, a condição de monitoramento utilizada é StorageReady.

Nome Gravidade Descrição

EBSInstanceIOPSExceeded

Event

O limite máximo de IOPS da instância foi excedido.

EBSInstanceThroughputExceeded

Event

O limite máximo de throughput da instância foi excedido.

EBSVolumeIOPSExceeded

Event

O limite máximo de IOPS de um volume do EBS específico foi excedido.

EBSVolumeThroughputExceeded

Event

O limite máximo de throughput de um volume do Amazon EBS específico foi excedido.

EtcHostsMountFailed

Event

A montagem do arquivo /etc/hosts gerado pelo kubelet falhou devido à remontagem de /var/lib/kubelet/pods via userdata durante a operação kubelet-container.

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 lentidão no uso do disco ao tentar acessar o sistema de arquivos. Isso pode indicar que as operações de entrada e de saída do disco são insuficientes ou que há problemas no sistema de arquivos.

XFSSmallAverageClusterSize

Event

O tamanho médio do cluster XFS é pequeno, indicando fragmentação excessiva do espaço livre. Isso pode impedir a criação de arquivos, mesmo que haja inodes ou espaço livre disponíveis.