Reparar automaticamente nós em clusters do EKS - Amazon EKS

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.

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.

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

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.

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.