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.
-
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.
-
AWS CLI: adicione
--node-repair-config enabled=trueao comandoeks create-nodegroupoueks update-nodegroup-config. -
eksctl: configure
managedNodeGroups.nodeRepairConfig.enabled: true, consulte o exemplo no eksctl GitHub.
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 |
|---|---|
|
|
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. |
|
|
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 |
|---|---|
|
|
Número máximo de nós a serem reparados ao mesmo tempo. |
|
|
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 |
|---|---|
|
|
O tipo de condição do nó relatado pelo agente de monitoramento de nós. Por exemplo: |
|
|
O código específico da causa da condição não íntegra. Por exemplo: |
|
|
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. |
|
|
A ação a ser tomada quando as condições forem atendidas. Valores válidos: |
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.