**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.
# Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós
A integridade do nó refere-se ao estado operacional e à capacidade de um nó do Kubernetes de executar workloads de forma eficaz. Um nó em bom estado mantém a conectividade de rede esperada, dispõe de recursos suficientes de computação e armazenamento e consegue executar workloads com êxito, sem interrupções.
Para ajudar a manter os nós em estado íntegro nos clusters do EKS, o EKS oferece o *agente de monitoramento de nós* e o *reparo automático de nós*. Esses recursos são habilitados automaticamente com computação no Modo automático do EKS. Você também pode utilizar o reparo automático de nós com grupos de nós gerenciados pelo EKS e o Karpenter, e pode utilizar o agente de monitoramento de nós do EKS com qualquer tipo de computação do EKS, exceto o AWS Fargate. O agente de monitoramento de nós do EKS e o reparo automático de nós são mais eficazes quando utilizados em conjunto, mas também podem ser utilizados individualmente em clusters do EKS.
**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 do EKS analisa os logs dos nós para detectar problemas de integridade. Ele analisa os logs para detectar falhas e exibe informações sobre o estado de integridade dos nós. Para cada categoria de problemas detectados, o agente aplica um `NodeCondition` dedicado aos nós de processamento. Para obter informações detalhadas sobre os problemas de integridade dos nós detectados pelo agente de monitoramento de nós do EKS, consulte [Detecte problemas de integridade dos nós com o agente de monitoramento de nós do EKS](node-health-nma.md).
O recurso de computação no Modo automático do EKS inclui o agente de monitoramento de nós. Para outros tipos de computação do EKS, é possível adicionar o agente de monitoramento de nós como um complemento do EKS ou gerenciá-lo com ferramentas do Kubernetes, como o Helm. Para obter mais informações, consulte [Configure o agente de monitoramento de nós](node-health-nma.md#node-monitoring-agent-configure).
Com o agente de monitoramento de nós do EKS, as seguintes categorias de problemas de integridade dos nós são apresentadas como condições de nós. Observe que, `Ready`, `DiskPressure` e `MemoryPressure` são condições padrão do nó Kubernetes que surgem mesmo sem o agente de monitoramento do nó EKS.
| Condição do nó | Descrição |
| --- | --- |
| AcceleratedHardwareReady | O parâmetro `AcceleratedHardwareReady` indica se o hardware acelerado (GPU, Neuron) no nó está funcionando corretamente. |
| ContainerRuntimeReady | ContainerRuntimeReady indica se o runtime de contêineres (containerd, etc.) está funcionando corretamente e é capaz de executar contêineres. |
| DiskPressure | DiskPressure é uma condição padrão do Kubernetes que indica que o nó está enfrentando pressão no disco (espaço em disco insuficiente ou alta carga de E/S). |
| KernelReady | KernelReady indica se o kernel está funcionando corretamente, sem erros críticos, falhas graves ou esgotamento de recursos. |
| MemoryPressure | MemoryPressure é uma condição padrão do Kubernetes que indica que o nó está enfrentando pressão de memória (baixa disponibilidade de memória). |
| NetworkingReady | NetworkingReady indica se a pilha de rede do nó está funcionando corretamente (interfaces, roteamento, conectividade). |
| StorageReady | O StorageReady indica se o subsistema de armazenamento do nó está funcionando corretamente (discos, sistemas de arquivos, E/S). |
| Ready | Ready é a condição padrão do Kubernetes que indica que o nó está íntegro e pronto para aceitar pods. |
## Reparo automático de nós
O reparo automático de nós do EKS monitora continuamente a integridade dos nós, reage aos problemas detectados e realiza a troca ou reinicialização dos nós sempre que possível. Isso aumenta a confiabilidade do cluster com intervenção manual mínima e ajuda a reduzir o tempo de inatividade das aplicações.
Por si só, o reparo automático de nós do EKS reage às condições `Ready` do kubelet, a quaisquer objetos de nó excluídos manualmente e às instâncias de grupos de nós gerenciados pelo EKS que não conseguem ingressar no cluster. Quando o reparo automático de nós do EKS está habilitado e o agente de monitoramento de nós está instalado, o reparo automático de nós do EKS reage a condições adicionais dos nós: `AcceleratedHardwareReady`, `ContainerRuntimeReady`, `KernelReady`, `NetworkingReady` e `StorageReady`.
O reparo automático de nós do EKS não reage às condições padrão do Kubernetes de nós `DiskPressure`, `MemoryPressure` ou `PIDPressure`. Essas condições geralmente indicam problemas com o comportamento da aplicação, configuração da workload ou limites de recursos, em vez de falhas no nível do nó, dificultando a determinação de uma ação de reparo padrão apropriada. Nesses cenários, as workloads estão sujeitas ao [comportamento de expulsão por pressão nos nós Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction).
Para obter mais informações sobre o reparo automático de nós do EKS, consulte [Reparar automaticamente nós em clusters do EKS](node-repair.md).
**Topics**
# Detecte problemas de integridade dos nós com o agente de monitoramento de nós do EKS
Este tópico descreve em detalhes os problemas de integridade dos nós detectados pelo agente de monitoramento de nós do EKS, como esses problemas são apresentados como condições ou eventos dos nós e como configurar o agente de monitoramento de nós.
O agente de monitoramento de nós do EKS pode ser utilizado com ou sem o reparo automático de nós do EKS. Para obter mais informações sobre o reparo automático de nós do EKS, consulte [Reparar automaticamente nós em clusters do EKS](node-repair.md).
O código-fonte do agente de monitoramento de nós do EKS está publicado no GitHub no repositório [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent).
## 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](learn-status-conditions.md#status-node-conditions).
+ 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](learn-status-conditions.md#status-node-events).
## 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`. Os eventos e condições apresentados na tabela abaixo referem-se a problemas de integridade dos nós relacionados ao NVIDIA e ao Neuron.
| Nome | Gravidade | Descrição | Ação de reparo |
| --- | --- | --- | --- |
| DCGMDiagnosticFailure | Condição | Um caso de teste do conjunto de testes de diagnóstico ativo do DCGM falhou. | Nenhum |
| DCGMError | Condição | Houve perda de conexão com o processo host do DCGM ou não foi possível estabelecê-la. | Nenhum |
| DCGMFieldError[Code] | Event | O DCGM detectou degradação da GPU por meio de um identificador de campo. | Nenhum |
| DCGMHealthCode[Code] | Event | Uma verificação de integridade do DCGM falhou de forma não fatal. | Nenhum |
| DCGMHealthCode[Code] | Condição | Uma verificação de integridade do DCGM falhou de forma fatal. | Nenhum |
| NeuronDMAError | Condição | Um mecanismo de DMA encontrou um erro irrecuperável. | Substituir |
| NeuronHBMUncorrectableError | Condição | Um HBM encontrou um erro incorrigível e produziu resultados incorretos. | Substituir |
| NeuronNCUncorrectableError | Condição | Foi detectado um erro de memória incorrigível do Neuron Core. | Substituir |
| NeuronSRAMUncorrectableError | Condição | Uma SRAM no chip encontrou um erro de paridade e produziu resultados incorretos. | Substituir |
| 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. | Nenhum |
| NvidiaDoubleBitError | Condição | Um erro de dois bits foi produzido pelo driver da GPU. | Substituir |
| NvidiaNCCLError | Event | Ocorreu uma falha de segmentação na NVIDIA Collective Communications Library (`libnccl`). | Nenhum |
| NvidiaNVLinkError | Condição | Erros do NVLink foram relatados pelo driver da GPU. | Substituir |
| NvidiaPCIeError | Event | As retransmissões de PCIe foram acionadas para a recuperação de erros de transmissão. | Nenhum |
| 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 |
| NvidiaPowerError | Event | O uso de energia pelas GPUs ultrapassou os limites permitidos. | Nenhum |
| NvidiaThermalError | Event | O status térmico das GPUs ultrapassou os limites permitidos. | Nenhum |
| NvidiaXID[Code]Error | Condição | Ocorreu um erro crítico relacionado com a GPU. | Substituir ou Reinicializar |
| NvidiaXID[Code]Warning | Event | Ocorreu um erro não crítico relacionado com a GPU. | Nenhum |
## Códigos de erro NVIDIA XID
O agente de monitoramento de nós detecta erros NVIDIA XID a partir dos logs do kernel da GPU. Os erros XID dividem-se em duas categorias:
+ **Códigos XID conhecidos**: erros críticos que definem uma condição do nó (`AcceleratedHardwareReady=False`) e acionam o reparo automático quando habilitado. O formato do código de motivo é `NvidiaXID[Code]Error`. Os códigos XID conhecidos que o agente de monitoramento do nó do EKS detecta podem não representar a lista completa de códigos XID da NVIDIA que exigem ações de reparo.
+ **Códigos XID desconhecidos**: registrados apenas como eventos do Kubernetes. Eles não acionam o reparo automático. O formato do código de motivo é `NvidiaXID[Code]Warning`. Para investigar erros XID desconhecidos, analise os logs do kernel com `dmesg | grep -i nvrm`.
Para obter mais informações sobre erros do XID, consulte [Xid Errors](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) 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](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) na *Documentação de implantação e gerenciamento da GPU NVIDIA*.
A tabela a seguir lista os códigos XID mais conhecidos, seus significados e a ação padrão de reparo do nó, caso esteja habilitada.
| Código XID | Descrição | Ação de reparo |
| --- | --- | --- |
| 13 | Exceção do mecanismo gráfico: ocorreu um erro no mecanismo gráfico da GPU, geralmente causado por problemas de software ou falhas no driver. | Reinicializar |
| 31 | Falha de página na memória da GPU: uma aplicação tentou acessar uma área da memória da GPU que não está mapeada ou não é acessível. | Reinicializar |
| 48 | Erro ECC de dois bits: ocorreu um erro de dois bits não corrigível na memória da GPU, indicando uma possível degradação do hardware. | Reinicializar |
| 63 | Evento de remapeamento da memória da GPU: o driver da GPU remapeou uma parte da memória da GPU devido a erros detectados. Isso geralmente é recuperável. | Reinicializar |
| 64 | Falha no remapeamento da memória da GPU: a GPU não conseguiu remapear a memória defeituosa, o que indica problemas de hardware. | Reinicializar |
| 74 | Erro NVLink: ocorreu um erro na interconexão NVLink de alta velocidade entre as GPUs. | Substituir |
| 79 | A GPU foi desconectada do barramento: a GPU não está mais acessível via PCIe, o que geralmente indica uma falha de hardware ou um problema de alimentação. | Substituir |
| 94 | Erro de memória contido: ocorreu um erro de memória, mas ele foi contido e não afetou outras aplicações. | Reinicializar |
| 95 | Erro de memória não contida: ocorreu um erro de memória que pode ter afetado outras aplicações ou a memória do sistema. | Reinicializar |
| 119 | Tempo limite do GSP RPC: o tempo de espera para a comunicação com o processador do sistema da GPU expirou, possivelmente devido a problemas de firmware. | Substituir |
| 120 | Erro no GSP: ocorreu um erro no processador do sistema da GPU. | Substituir |
| 121 | Erro C2C: ocorreu um erro na interconexão entre chips (utilizada em GPUs com vários chips). | Substituir |
| 140 | Erro ECC não recuperado: um erro ECC escapou do mecanismo de contenção e pode ter corrompido os dados. | Substituir |
Para visualizar as condições atuais do nó relacionadas à integridade da GPU, execute o seguinte comando.
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
Para visualizar eventos relacionados ao XID no seu cluster, execute um dos seguintes comandos.
```
kubectl get events | grep -i "NvidiaXID"
```
## 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 | Ação de reparo |
| --- | --- | --- | --- |
| ContainerRuntimeFailed | Event | O runtime do contêiner falhou ao criar um contêiner, provavelmente relacionado a quaisquer problemas relatados, caso tenham ocorrido repetidamente. | Nenhum |
| 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`. | Nenhum |
| KubeletFailed | Event | O kubelet entrou em um estado de falha. | Nenhum |
| 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. | Nenhum |
| 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. | Substituir |
| 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. | Nenhum |
| [Name]RepeatedRestart | Event | Uma unidade do systemd está reiniciando com frequência. | Nenhum |
| ServiceFailedToStart | Event | Uma unidade do systemd falhou ao iniciar. | Nenhum |
## 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 | Ação de reparo |
| --- | --- | --- | --- |
| 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. | Nenhum |
| AppCrash | Event | Uma aplicação no nó falhou. | Nenhum |
| 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. | Nenhum |
| 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á. | Nenhum |
| 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. | Nenhum |
| 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. | Nenhum |
| 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. | Substituir |
| 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. | Nenhum |
| 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. | Nenhum |
| 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. | Nenhum |
| SoftLockup | Event | A CPU ficou paralisada por um determinado período de tempo. | Nenhum |
## 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 | Ação de reparo |
| --- | --- | --- | --- |
| BandwidthInExceeded | Event | Os pacotes foram enfileirados ou descartados porque a largura de banda agregada de entrada excedeu o máximo para a instância. | Nenhum |
| 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. | Nenhum |
| 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. | Nenhum |
| EFAErrorMetric | Event | As métricas do driver EFA indicam que há uma interface com degradação de performance. | Nenhum |
| 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. | Nenhum |
| IPAMDNoIPs | Event | O IPAMD está sem endereços IP disponíveis. | Nenhum |
| IPAMDNotReady | Condição | O IPAMD não consegue se conectar ao servidor da API. | Substituir |
| IPAMDNotRunning | Condição | Não foi possível localizar o processo da CNI do Amazon VPC em execução no sistema. | Substituir |
| IPAMDRepeatedlyRestart | Event | Ocorreram várias reinicializações no serviço do IPAMD. | Nenhum |
| InterfaceNotRunning | Condição | Esta interface parece não estar funcionando ou há problemas de rede. | Substituir |
| InterfaceNotUp | Condição | Esta interface parece não estar ativa ou há problemas de rede. | Substituir |
| KubeProxyNotReady | Event | O kube-proxy falhou ao observar ou listar recursos. | Nenhum |
| 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. | Nenhum |
| MACAddressPolicyMisconfigured | Event | O valor definido para `MACAddressPolicy` na configuração de link do systemd-networkd está incorreto. | Nenhum |
| MissingDefaultRoutes | Event | Há regras de rota padrão ausentes. | Nenhum |
| MissingIPRoutes | Event | Existem rotas ausentes para os endereços IP dos pods. | Nenhum |
| MissingIPRules | Event | Existem regras ausentes para os endereços IP dos pods. | Nenhum |
| MissingLoopbackInterface | Condição | A interface de loopback está ausente nesta instância, causando falha nos serviços que dependem da conectividade local. | Substituir |
| NetworkSysctl | Event | As configurações de `sysctl` da rede deste nó podem estar configuradas incorretamente. | Nenhum |
| PPSExceeded | Event | Os pacotes foram enfileirados ou descartados porque o PPS bidirecional excedeu o máximo para a instância. | Nenhum |
| 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`. | Nenhum |
| UnexpectedRejectRule | Event | Uma regra inesperada de `REJECT` ou `DROP` foi encontrada no `iptables`, o que pode estar bloqueando o tráfego esperado. | Nenhum |
## 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 | Ação de reparo |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | Event | O limite máximo de IOPS da instância foi excedido. | Nenhum |
| EBSInstanceThroughputExceeded | Event | O limite máximo de throughput da instância foi excedido. | Nenhum |
| EBSVolumeIOPSExceeded | Event | O limite máximo de IOPS de um volume do EBS específico foi excedido. | Nenhum |
| EBSVolumeThroughputExceeded | Event | O limite máximo de throughput de um volume do Amazon EBS específico foi excedido. | Nenhum |
| 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`. | Nenhum |
| IODelays | Event | Atraso de entrada ou saída detectado em um processo, possivelmente indicando provisionamento insuficiente de entrada-saída, se excessivo. | Nenhum |
| 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. | Nenhum |
| 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. | Nenhum |
## Configure o agente de monitoramento de nós
O agente de monitoramento de nós do EKS é implantado como DaemonSet. Ao realizar a implantação como um complemento do EKS, é possível personalizar a instalação com os seguintes valores de configuração. Para configurações padrão, consulte o [chart do Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) do agente de monitoramento de nós do EKS.
| Opção de configuração | Descrição |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | Solicitação de recursos da CPU para o agente de monitoramento. |
| `monitoringAgent.resources.requests.memory` | Solicitação de recursos de memória para o agente de monitoramento. |
| `monitoringAgent.resources.limits.cpu` | Limite de recursos da CPU para o agente de monitoramento. |
| `monitoringAgent.resources.limits.memory` | Limite de recursos de memória para o agente de monitoramento. |
| `monitoringAgent.tolerations` | Tolerâncias para a programação do agente de monitoramento em nós com taint. |
| `monitoringAgent.additionalArgs` | Argumentos adicionais da linha de comando a serem passados ao agente de monitoramento. |
**nota**
Você pode configurar `hostname-override` e `verbosity` como `monitoringAgent.additionalArgs` no caso dos complementos do EKS ou da instalação via Helm. No momento, não é possível personalizar o `probe-address` (`8002`) ou `metrics-address` (`8003`) do agente de monitoramento de nós por meio de argumentos adicionais com os complementos do EKS ou a instalação via Helm.
O agente de monitoramento de nós inclui um componente de servidor NVIDIA DCGM (Data Center GPU Manager) (`nv-hostengine`) para monitorar GPUs NVIDIA. Esse componente é executado apenas em nós que são do tipo de instância de GPU NVIDIA, conforme indicado por `nodeAffinity` no [chart do Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) do agente. Não é possível utilizar uma instalação existente do NVIDIA DCGM com o agente de monitoramento de nós do EKS. Envie seus comentários sobre o roteiro do EKS, [issue \$12763 do GitHub](https://github.com/aws/containers-roadmap/issues/2763), caso essa funcionalidade seja necessária.
Ao realizar a implantação do agente de monitoramento de nós do EKS como um complemento do EKS, é possível personalizar a instalação do NVIDIA DCGM com os seguintes valores de configuração.
| Opção de configuração | Descrição |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | Solicitação de recursos da CPU para o agente DCGM. |
| `dcgmAgent.resources.requests.memory` | Solicitação de recursos de memória para o agente DCGM. |
| `dcgmAgent.resources.limits.cpu` | Limite de recursos da CPU para o agente DCGM. |
| `dcgmAgent.resources.limits.memory` | Limite de recursos de memória para o agente DCGM. |
| `dcgmAgent.tolerations` | Tolerâncias para a programação do agente DCGM em nós comprometidos. |
Você pode usar os seguintes comandos da AWS CLI para obter informações úteis sobre as versões e o esquema do complemento do agente de monitoramento de nós do EKS.
Obtenha a versão mais recente do complemento do agente para a sua versão do Kubernetes. Substitua `1.35` pela sua versão do Kubernetes.
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
Obtenha o esquema do complemento de agente com suporte em complementos do EKS. Substitua `v1.5.1-eksbuild.1` pela versão do agente.
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# Reparar automaticamente nós em clusters do EKS
Esse tópico descreve o comportamento do reparo automático de nós no EKS e como configurá-lo para atender às suas necessidades. O reparo automático de nós do EKS está habilitado por padrão no Modo Automático do EKS e pode ser usado com grupos de nós gerenciados pelo EKS e com o Karpenter.
As ações padrão de reparo automático de nós do EKS estão resumidas na tabela abaixo e se aplicam ao comportamento do Modo Automático do EKS, dos grupos de nós gerenciados pelo EKS e do Karpenter. Ao utilizar o Modo automático do EKS ou o Karpenter, todas as ações de reparo `AcceleratedHardwareReady` são `Replace`, e apenas os grupos de nós gerenciados pelo EKS oferecem suporte a `Reboot` como ação de reparo.
Para obter uma lista detalhada dos problemas de integridade dos nós detectados pelo agente de monitoramento de nós do EKS e as respectivas ações de reparo, consulte [Detecte problemas de integridade dos nós com o agente de monitoramento de nós do EKS](node-health-nma.md).
| Condição do nó | Descrição | Reparar após | Ação(ões) de reparo |
| --- | --- | --- | --- |
| AcceleratedHardwareReady | O parâmetro `AcceleratedHardwareReady` indica se o hardware acelerado (GPU, Neuron) no nó está funcionando corretamente. | 10 m | Substituir ou Reinicializar |
| ContainerRuntimeReady | ContainerRuntimeReady indica se o runtime de contêineres (containerd, etc.) está funcionando corretamente e é capaz de executar contêineres. | 30 m | Substituir |
| DiskPressure | DiskPressure é uma condição padrão do Kubernetes que indica que o nó está enfrentando pressão no disco (espaço em disco insuficiente ou alta carga de E/S). | N/D | Nenhum |
| KernelReady | KernelReady indica se o kernel está funcionando corretamente, sem erros críticos, falhas graves ou esgotamento de recursos. | 30 m | Substituir |
| MemoryPressure | MemoryPressure é uma condição padrão do Kubernetes que indica que o nó está enfrentando pressão de memória (baixa disponibilidade de memória). | N/D | Nenhum |
| NetworkingReady | NetworkingReady indica se a pilha de rede do nó está funcionando corretamente (interfaces, roteamento, conectividade). | 30 m | Substituir |
| StorageReady | O StorageReady indica se o subsistema de armazenamento do nó está funcionando corretamente (discos, sistemas de arquivos, E/S). | 30 m | Substituir |
| Ready | Ready é a condição padrão do Kubernetes que indica que o nó está íntegro e pronto para aceitar pods. | 30 m | Substituir |
As ações automáticas de reparo de nós do EKS estão desabilitadas por padrão nos seguintes cenários. As ações de reparo de nós em andamento continuam em cada cenário. Consulte [Configurar o reparo automático de nós](#configure-node-repair) para saber como substituir essas configurações padrão.
**Grupos de nós gerenciados do EKS**
+ O grupo de nós possui mais de cinco nós e mais de 20% dos nós desse grupo estão com problemas.
+ Uma mudança de zona para o seu cluster é acionada por meio do Application Recovery Controller (ARC).
**Modo automático do EKS e Karpenter**
+ Mais de 20% dos nós do NodePool não estão íntegros.
+ No caso de NodeClaims autônomos, 20% dos nós do cluster não estão íntegros.
## Configurar o reparo automático de nós
O reparo automático de nós não pode ser configurado ao usar o Modo automático do EKS e está sempre ativado com as mesmas configurações padrão do Karpenter.
### Karpenter
Para utilizar o reparo automático de nós com o Karpenter, habilite o gate de recursos `NodeRepair=true`. É possível habilitar gates de recurso por meio da opção `--feature-gates` da CLI ou da variável de ambiente `FEATURE_GATES` na implantação do Karpenter. Para obter mais informações, consulte a documentação do [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair).
### Grupos de nós gerenciados
É possível habilitar o reparo automático de nós ao criar novos grupos de nós gerenciados pelo EKS ou ao atualizar grupos de nós gerenciados pelo EKS já existentes.
+ **Console do Amazon EKS**: marque a caixa de seleção **Habilitar reparo automático de nós** para o grupo de nós gerenciados. Para obter mais informações, consulte [Criar um grupo de nós gerenciados para seu cluster](create-managed-node-group.md).
+ ** AWS CLI**: adicione `--node-repair-config enabled=true` ao comando [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html) ou [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html).
+ **eksctl**: configure `managedNodeGroups.nodeRepairConfig.enabled: true`, consulte o exemplo no [eksctl GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml).
Ao utilizar grupos de nós gerenciados do EKS, é possível controlar o comportamento do reparo automático dos nós por meio das seguintes configurações.
Para controlar quando o reparo automático de nós deixa de agir, defina um limite com base no número de nós com falhas no grupo de nós. Defina a contagem absoluta ou a porcentagem, mas não ambas.
| Configuração | Descrição |
| --- | --- |
| `maxUnhealthyNodeThresholdCount` | O número absoluto de nós não íntegros acima do qual o reparo automático de nós é interrompido. Use isso para limitar o escopo dos reparos. |
| `maxUnhealthyNodeThresholdPercentage` | A porcentagem de nós não íntegros acima da qual o reparo automático de nós é interrompido (0-100). |
Para controlar quantos nós são reparados ao mesmo tempo, é possível configurar o paralelismo de reparos. Assim como ocorre no limite de nós não íntegros, configure a contagem absoluta ou a porcentagem, mas nunca as duas simultaneamente.
| Configuração | Descrição |
| --- | --- |
| `maxParallelNodesRepairedCount` | Número máximo de nós a serem reparados ao mesmo tempo. |
| `maxParallelNodesRepairedPercentage` | A porcentagem máxima de nós não íntegros a serem reparados simultaneamente (0-100). |
Com `nodeRepairConfigOverrides`, é possível personalizar o comportamento de reparo para condições específicas. Use isso quando precisar de diferentes ações de reparo ou tempos de espera para diferentes tipos de problemas.
Cada substituição requer todos os campos a seguir:
| Campo | Descrição |
| --- | --- |
| `nodeMonitoringCondition` | O tipo de condição do nó relatado pelo agente de monitoramento de nós. Por exemplo: `AcceleratedHardwareReady`, `NetworkingReady`, `StorageReady`, `KernelReady`. |
| `nodeUnhealthyReason` | O código específico da causa da condição não íntegra. Por exemplo: `NvidiaXID31Error`, `IPAMDNotRunning`. |
| `minRepairWaitTimeMins` | O tempo mínimo, em minutos, durante o qual a condição deve persistir antes que o nó se torne elegível para reparo. Utilize esta opção para evitar o reparo de nós devido a problemas temporários. |
| `repairAction` | A ação a ser tomada quando as condições forem atendidas. Valores válidos: `Replace` (encerrar e substituir o nó), `Reboot` (reinicializar o nó) ou `NoAction` (nenhuma ação de reparo). |
O seguinte exemplo da AWS CLI cria um grupo de nós com configurações de reparo personalizadas.
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--node-role arn:aws:iam::111122223333:role/NodeRole \
--subnets subnet-0123456789abcdef0 \
--node-repair-config '{
"enabled": true,
"maxUnhealthyNodeThresholdPercentage": 10,
"maxParallelNodesRepairedCount": 3,
"nodeRepairConfigOverrides": [
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID64Error",
"minRepairWaitTimeMins": 5,
"repairAction": "Replace"
},
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID31Error",
"minRepairWaitTimeMins": 15,
"repairAction": "NoAction"
}
]
}'
```
Esta configuração realiza o seguinte:
+ Habilita o reparo automático de nós
+ Interrompe as ações de reparo quando mais de 10% dos nós não estão íntegros
+ Repara até 3 nós de cada vez
+ Anula erros XID 64 (falha no remapeamento da memória da GPU) para substituir o nó após 5 minutos. O padrão é reinicializar após 10 minutos.
+ Anula erros XID 31 (falha na página de memória da GPU) para não realizar nenhuma ação. O padrão é reinicializar após 10 minutos.
# Visualizar o status de integridade dos nós
Este tópico explica as ferramentas e os métodos disponíveis para monitorar o status de integridade dos nós nos clusters do Amazon EKS. As informações abrangem condições, eventos e casos de detecção de nós que ajudam a identificar e diagnosticar problemas no nível do nó. Use os comandos e padrões descritos aqui para inspecionar os recursos de integridade do nó, interpretar as condições de status e analisar os eventos do nó para solucionar problemas operacionais.
Você pode obter algumas informações sobre a integridade dos nós com comandos do Kubernetes para todos os nós. E se você usar o agente de monitoramento de nós por meio do Modo Automático do Amazon EKS ou do complemento gerenciado do Amazon EKS, você obterá uma variedade maior de sinais de nós para ajudar na solução de problemas. As descrições dos problemas de integridade detectados pelo agente de monitoramento de nós também são disponibilizadas no painel de observabilidade. Para obter mais informações, consulte [Detecte problemas de integridade dos nós com o agente de monitoramento de nós do EKS](node-health-nma.md).
## Condições de nós
As condições do nó representam problemas terminais que exigem ações de correção, como a substituição ou reinicialização da instância.
**Para obter as condições de todos os nós:**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**Para obter as condições detalhadas de um nó específico:**
```
kubectl describe node node-name
```
**Exemplo de saída de condição de um nó íntegro:**
```
- lastHeartbeatTime: "2024-11-21T19:07:40Z"
lastTransitionTime: "2024-11-08T03:57:40Z"
message: Monitoring for the Networking system is active
reason: NetworkingIsReady
status: "True"
type: NetworkingReady
```
**Exemplo de condição de um nó não íntegro com um problema de rede:**
```
- lastHeartbeatTime: "2024-11-21T19:12:29Z"
lastTransitionTime: "2024-11-08T17:04:17Z"
message: IPAM-D has failed to connect to API Server which could be an issue with
IPTable rules or any other network configuration.
reason: IPAMDNotReady
status: "False"
type: NetworkingReady
```
## Eventos de nós
Os eventos de nós indicam problemas temporários ou configurações abaixo do ideal.
**Para obter todos os eventos relatados pelo agente de monitoramento de nós**
Quando o agente de monitoramento de nós estiver disponível, você poderá executar o comando a seguir.
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
Exemplo de resultado:
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**Para obter os eventos de todos os nós**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**Para obter os eventos para um nó específico**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**Para observar os eventos em tempo real**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**Exemplo de saída de evento:**
```
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure
5m Normal NodeReady Node/node-1 Node became ready
```
## Comandos comuns de solução de problemas
```
# Get comprehensive node status
kubectl get node node-name -o yaml
# Watch node status changes
kubectl get nodes -w
# Get node metrics
kubectl top node
```
# Recuperar logs de nós de um nó gerenciado usando kubectl e S3
Saiba como recuperar logs de nós de um nó gerenciado do Amazon EKS que tem o agente de monitoramento de nós.
## Pré-requisitos
Certifique-se de ter o seguinte:
+ Um cluster existente do Amazon EKS com o agente de monitoramento de nós. Para obter mais informações, consulte [Detectar problemas de integridade dos nós e habilitar o reparo automático dos nós](node-health.md).
+ A ferramenta de linha de comandos da `kubectl` instalada e configurada para se comunicar com o cluster.
+ A AWS CLI instalada e conectada com permissões suficientes para criar buckets e objetos do S3.
+ Uma versão recente do Python 3 instalada
+ O AWS SDK para Python 3, Boto 3, instalado.
## Etapa 1: criar um bucket de destino do S3 (opcional)
Caso ainda não tenha um bucket do S3 para armazenar os logs, crie um. Use o comando da AWS CLI a seguir. O bucket usa como padrão a lista de controle de acesso `private`. Substitua *bucket-name* pelo nome exclusivo do bucket escolhido.
```
aws s3api create-bucket --bucket
```
## Etapa 2: criar um URL do S3 pré-assinado para HTTP PUT
O Amazon EKS retorna os logs dos nós fazendo uma operação HTTP PUT em um URL especificado por você. Neste tutorial, vamos gerar um URL de HTTP PUT do S3 pré-assinado.
Os logs serão retornados como um tarball gzip, com a extensão `.tar.gz`.
**nota**
Você deve usar a API ou um SDK da AWS para criar o URL de upload do S3 pré-assinado para que o EKS faça o upload do arquivo de logs. Você não pode criar um URL de upload do S3 pré-assinado usando a AWS CLI.
1. Determine em que parte do bucket você deseja armazenar os logs. Por exemplo, você pode usar *2024-11-12/logs1.tar.gz* como a chave.
1. Salve o código Python abaixo no arquivo *presign-upload.py*. Substitua ** e **. A chave deve terminar com `.tar.gz`.
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. Execute o script com
```
python presign-upload.py
```
1. Observe a saída do URL. Use esse valor na próxima etapa como *http-put-destination*.
Para obter mais informações, consulte [Generate a presigned URL to upload a file](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) na documentação do AWS Boto3 SDK para Python.
## Etapa 3: criar um recurso NodeDiagnostic
Identifique o nome do nós do qual deseja coletar os logs.
Crie um manifesto `NodeDiagnostic` que use o nome do nó como nome do recurso e forneça um destino de URL de HTTP PUT.
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
Aplique o manifesto ao cluster.
```
kubectl apply -f nodediagnostic.yaml
```
Você pode verificar o status da coleta descrevendo o recurso `NodeDiagnostic`:
+ Um status de `Success` ou `SuccessWithErrors` indica que a tarefa foi concluída e os logs foram enviados para o destino fornecido (`SuccessWithErrors` indica que alguns logs podem estar ausentes)
+ Se o status for Falha, confirme se o URL de upload está formado de forma correta e não expirou.
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## Etapa 4: fazer download dos logs do S3
Aguarde aproximadamente um minuto antes de tentar fazer download dos logs. Em seguida, use a CLI do S3 para fazer download dos logs.
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## Etapa 5: limpar o recurso NodeDiagnostic
+ Os recursos `NodeDiagnostic` não são excluídos automaticamente. Você deve limpá-los por conta própria depois de obter os artefatos de logs.
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## Destino do NodeDiagnostic `node`
A partir da versão `v1.6.0` do Node Monitoring Agent, existe uma opção para definir o destino da coleta de logs como `node`. A utilização deste destino resultará na coleta e no armazenamento temporário de logs no nó para posterior coleta. Além dessa funcionalidade, no repositório do Node Monitoring Agent no GitHub há um plug-in `kubectl` que você pode instalar para facilitar a interação e a coleta de logs. Para obter mais informações, consulte a [documentação do plug-in `kubectl ekslogs`](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).
## Exemplo de uso
```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs
# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs
# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l =
```