Como soluciono problemas de escalabilidade de cluster com o autoscaling do Karpenter no Amazon EKS?

Resolução

Solucione o problema com base na mensagem de erro recebida.

Não é possível programar Pods do Karpenter devido à insuficiência de instâncias do grupo de nós do Amazon EKS

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de problemas da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Na versão 0.16.0 e posterior do Karpenter, a contagem padrão de réplicas mudou de 1 para 2. Para obter mais informações, consulte v0.16.0 no site do GitHub. Se não houver capacidade de nó suficiente no cluster para suportar o número configurado de réplicas, não será possível programar os Pods do Karpenter. Como o Karpenter não pode provisionar nós para executar seus próprios Pods, ele apresenta falha devido à capacidade insuficiente e resulta em Pods não programados. Assim, você recebe a seguinte mensagem de erro:

"Warning FailedScheduling 3m default-scheduler 0/1 nodes are available: 1 Insufficient memory."

Para resolver esse erro, realize uma das seguintes ações:

Reduza as réplicas de implantação do Karpenter para uma

Se sua implantação do Karpenter não exigir redundância, altere-a para usar uma única réplica. Execute o seguinte comando:

kubectl scale deployment karpenter --replicas=1

Aumente a capacidade do nó dos Pods do Karpenter

Para executar duas réplicas do Karpenter, certifique-se de que haja capacidade suficiente para duas réplicas. Escolha uma das seguintes opções:

Aumente a escala horizontalmente do grupo do Auto Scaling

1. Aumente a contagem mínima de instâncias no grupo do Auto Scaling. Execute o seguinte comando:

   aws autoscaling update-auto-scaling-group --auto-scaling-group-name your-node-group-name --min-size 2 --desired-capacity 2

   Observação: substitua your-node-group-name pelo nome do seu grupo do Auto Scaling.
2. Certifique-se de que haja nós que o Karpenter não gerencia. Verifique os rótulos dos nós para ver os rótulos do Karpenter, como karpenter.sh/nodepool. Execute o seguinte comando:

   kubectl get nodes --show-labels | grep karpenter.sh/nodepool

Use os nós existentes

Se o nó ou nós de destino existentes tiverem rótulos Karpenter, como karpenter.sh/nodepool, remova os rótulos. Execute o seguinte comando:

kubectl label nodes your-node-name karpenter.sh/nodepool-

Observação: substitua your-node-name pelo nome do seu nó.

Falhas de anexação e montagem de volumes

Quando vários pods com solicitações de volumes persistentes (Persistent Volume Claims, PVCs) são programados no mesmo nó, ele pode exceder seu limite de anexo de volume. Em seguida, é possível receber uma das seguintes mensagens de erro:

"Warning FailedAttachVolume pod/example-pod AttachVolume. Attach failed for volume " " : rpc error: code = Internal desc = Could not attach volume " " to node " ": attachment of disk " " failed, expected device to be attached but was attaching"

"Warning FailedMount pod/example-pod Unable to attach or mount volumes: unmounted volumes=[], unattached volumes=[]: timed out waiting for the condition"

Para resolver falhas de anexação e montagem de volumes para workloads com uso intenso de PVC, conclua as seguintes etapas:

1. Aplique topologySpreadConstraints e podAntiAffinity para evitar que pods com uso intenso de PVC sejam programados no mesmo nó. Para obter mais informações, consulte campo topologySpreadConstraints e Pod affinity example (Exemplo de afinidade de pod) no site do Kubernetes. Essa ação distribui pods com uso intenso de PVC em diferentes nós para evitar a concentração de anexos de volume em um único nó.
2. Use drivers CSI, como o driver Container Storage Interface (CSI) do Amazon Elastic Block Store (Amazon EBS) (aws-ebs-csi-driver), e adicione taints de startup ao seu NodePool. Essas ações garantem que os Pods não sejam programados prematuramente nos nós antes de estarem totalmente prontos.
   Exemplo de configuração para taints de startup no Amazon EBS:

   --yaml--
   apiVersion: karpenter.sh/v1
   kind: NodePool
   spec:
     template:
       spec:
         startupTaints:
           - key: ebs.csi.aws.com/agent-not-ready
             effect: NoExecute
   

Erro de plug-in de armazenamento obsoleto

O Karpenter não oferece suporte a plug-ins de armazenamento in-tree obsoletos, como o Amazon EBS. Se você usar um Volume Persistente (PV) provisionado estaticamente com um plug-in in-tree, o Karpenter não conseguirá descobrir os limites de anexação de volume do nó. Esse cenário pode causar falhas na programação e é possível receber a seguinte mensagem de erro:

"ERROR controller.node_state PersistentVolume source 'AWSElasticBlockStore' uses an in-tree storage plugin which is unsupported by Karpenter and is deprecated by Kubernetes."

Para resolver esse problema, use drivers CSI para Amazon EBS e atualize suas configurações de PV para usar o driver CSI.

Falhas de programação ou de bin-pack devido a solicitações de recursos não especificadas

O Karpenter faz bin-pack dos Pods com base nas solicitações de recursos. Se as solicitações estiverem muito baixas ou ausentes, o Karpenter pode alocar muitos pods para o mesmo nó. Esse cenário pode levar à contenção de recursos e ao controle de utilização da CPU. Além disso, se os limites de memória forem definidos e os pods tentarem usar mais memória do que o limite, talvez haja terminações de falta de memória (OOM). É possível receber a seguinte mensagem de erro:

"Warning OOMKilled pod/your-pod-name Container "container-name" was killed due to OOM (Out of Memory). Memory limit: 512Mi, Memory usage: 513Mi"

Para evitar esses problemas, use as configurações LimitRange para definir solicitações mínimas de recursos para fazer um bin-pack preciso. As configurações LimitRange ajudam a estabelecer limites máximos para evitar o consumo excessivo. Elas também fornecem limites padrão para pods não especificados. Para obter mais informações, consulte Use LimitRanges to configure defaults for resource requests and limits (Use LimitRanges para configurar padrões para solicitações e limites de recursos).

Falha ao iniciar os pods do Windows com erro de extração de imagem

Um pod falha ao iniciar se a versão do sistema operacional (SO) do contêiner não corresponder à versão do sistema operacional do Windows. Você recebe uma mensagem de erro semelhante à seguinte:

"Failed to pull image "mcr.microsoft.com/windows/servercore:xxx": rpc error: code = NotFound desc = failed to pull and unpack image "mcr.microsoft.com/windows/servercore:xxx": no match for platform in manifest: not found"

Para resolver esse problema, defina o nodeSelector do seu pod para garantir que seus contêineres estejam programados em uma versão de host de sistema operacional compatível. Para obter mais informações, consulte Windows container version compatibility (Compatibilidade de versões de contêineres do Windows) no site da Microsoft.

Os nós não foram inicializados corretamente

O sistema determina a inicialização do nó com base na prontidão do nó, no registro esperado dos recursos e na remoção dos taints de startup do NodePool. Se alguma dessas condições não for atendida, o nó do Karpenter não será inicializado corretamente e o nó permanecerá no estado NotReady. Como resultado, o sistema não pode usar o nó para programar ou consolidar workloads. É possível receber a seguinte mensagem de erro:

"Nodes provisioned by Karpenter are in a NotReady state"

Verifique se o estado do nó está Pronto. Se não estiver, inspecione os logs do Kubelet para identificar possíveis problemas com permissões, grupos de segurança ou rede.

Verifique se todos os recursos necessários, como nvidia.com/gpu ou vpc.amazonaws.com/pod-eni, estão registrados corretamente no nó.

Para verificar os recursos do nvidia.com/gpu no nó, execute o seguinte comando:

kubectl describe node your-node-name

Observação: substitua your-node-name pelo nome do seu nó.

Exemplo de saída:

...
Capacity:
  nvidia.com/gpu.shared: 80
...

Se esses recursos estiverem ausentes, verifique se o daemonset ou os plug-ins apropriados estão em execução. Para verificar o daemonset, execute o seguinte comando:

kubectl get ds -n your-daemonset-namespace

Observação: substitua your-daemonset-namespace pelo namespace do seu daemonset.

Falhas de agendamento devido a várias restrições e limitações

O pod não pode ser programado devido a restrições de afinidade, antiafinidade ou distribuição de topologia

Um pod não é programado se as restrições de afinidade, antiafinidade ou distribuição de topologia exigirem nós ou zonas específicos, mas não existem nós adequados nos locais necessários. Se o sistema não conseguir colocar um pod devido aos requisitos de nó ou zona que não foram atendidos, é possível receber a seguinte mensagem de erro:

"Warning FailedScheduling pod/"pod-name" 0/3 nodes are available: 1 node(s) didn't match pod affinity rules, 2 node(s) didn't match pod topology spread constraints rules, 3 nodes(s) didn't match inter-pod anti-affinity rules."

Para resolver esse erro, revise e ajuste as configurações de afinidade e antiafinidade do pod ou as restrições de distribuição de topologia para alinhá-las aos nós disponíveis. É possível reduzir essas restrições ou provisionar mais nós nas zonas necessárias.

Falha ao programar o pod devido à insuficiência de recursos

Os pods permanecem não programados devido a solicitações de recursos que excedem a capacidade disponível do nó. Se não houver nenhum nó com CPU, memória ou outros recursos suficientes para aceitar o pod, é possível receber a seguinte mensagem de erro:

"Warning FailedScheduling 30s (x13 over 60m) default-scheduler 0/5 nodes are available: 1 Insufficient memory. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod."

Para resolver esse problema, certifique-se de que as solicitações de recursos na especificação do pod reflitam o uso real. Ajuste as solicitações e os limites de recursos, se necessário, ou provisione nós maiores com mais capacidade para atender às demandas de recursos.

Taints impedem que os pods sejam programados

Quando os administradores do cluster aplicam taints personalizados a nós específicos, os pods precisam ter tolerâncias correspondentes. Se eles não tiverem tolerâncias correspondentes, o sistema não poderá programar pods nesses nós. Você recebe a seguinte mensagem de erro:

"0/5 nodes are available: 3 node(s) had taint {dedicated: gpu}, that the pod didn't tolerate, 2 node(s) had taint {dedicated: non-gpu}, that the pod didn't tolerate."

Para resolver esse erro, adicione as tolerâncias apropriadas à especificação do pod para permitir que ele tolere os taints. Ou é possível remover ou modificar os taints personalizados desnecessários nos nós se eles forem muito restritivos.

Para remover um taint de um nó, execute o seguinte comando:

kubectl taint nodes your-node-name your-custom-taint-

Observação: substitua your-node-name pelo nome do seu nó e your-custom-taint pelo nome do seu taint personalizado.

As restrições de NodeAffinity ou NodeSelector não foram satisfeitas

Se houver restrições de afinidade de nó ou de seletor de nós que não correspondam a nenhum nó disponível no cluster, o programador não poderá colocar pods. Você recebe a seguinte mensagem de erro:

"Warning FailedScheduling  3m    default-scheduler 0/4 nodes are available: 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) didn't satisfy existing pods anti-affinity rules, 4 node(s) didn't match Pod's node affinity rules."

Para resolver esse erro, modifique os requisitos de afinidade do nó ou do seletor de nós do pod para serem mais flexíveis. Ou é possível provisionar nós adicionais que atendam aos critérios do pod, se necessário. Para obter mais informações, consulte Node affinity e nodeSelector no site do Kubernetes.

Endereços IP insuficientes na sub-rede

Quando o Karpenter tenta provisionar novos nós, ele falha devido à insuficiência de endereços IP na sub-rede. Esse cenário ocorre quando o intervalo de Encaminhamento Entre Domínios Sem Classificação (CIDR) da sub-rede está esgotado e não pode acomodar novas instâncias do Amazon Elastic Compute Cloud (Amazon EC2). Você recebe a seguinte mensagem de erro:

"error": "creating machine, creating instance, with fleet error(s), InsufficientFreeAddressesInSubnet: There are not enough free addresses in subnet 'subnet-a to satisfy the requested number of instances."

Para resolver esse erro, realize uma das seguintes ações:

Se os endereços IP da sub-rede estiverem esgotados, adicione um bloco CIDR IPv4 extra como um CIDR secundário à sua Amazon Virtual Private Cloud (Amazon VPC).

-ou-

Use redes personalizadas para atribuir espaços de endereço IP separados aos seus pods e nós. Execute o comando a seguir para ativar a rede personalizada:

kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

Para obter mais informações sobre redes personalizadas, consulte Como escolho sub-redes de endereço IP específicas para pods no meu cluster do Amazon EKS?

Não é possível programar o Pod devido a requisitos incompatíveis

O Karpenter não consegue programar pods que especificam rótulos de grupos de nós, como eks.amazonaws.com/nodegroup, que não correspondem a nenhum valor definido nas configurações do grupo de nós. Se essa incompatibilidade ocorrer, o Karpenter não pode colocar pods nos nós devido à ausência dos rótulos de nós necessários. Você recebe uma das seguintes mensagens de erro:

"incompatible requirements, label \"eks.amazonaws.com/nodegroup\" does not have known values""

"incompatible requirements, key topology.kubernetes.io/zone, topology.kubernetes.io/zone In [us-east-1a] not in topology.kubernetes.io/zone In [us-east-1b us-east-1c]"

"incompatible requirements, key nodes.ktp.io/role, nodes.ktp.io/role In [ktp-atom-apps] not in nodes.ktp.io/role In [kube-apps]"

Se você quiser que os pods sejam programáveis pelo Karpenter, remova o nodeSelector específico do grupo de nós gerenciados para resolver esse erro.

Exemplo:

kubectl edit pod your-pod-name
or  
kubectl edit deployment your-deployment-name
or
kubectl edit daemonset your-daemonset-name

Observação: substitua your-pod-name, your-deployment-name ou your-daemonset-name pelo nome do seu pod, implantação ou daemonset.

Falhas na consolidação de nós

A consolidação dos nós do Karpenter pode falhar devido a restrições de programação ou configurações específicas do pod que impedem a migração do pod.

Restrições de programação

A consolidação de nós falha quando os pods não podem ser migrados pelos seguintes motivos:

• Afinidade ou antiafinidade entre Pods: Pods que exigem ou evitam a co-localização com outros pods.
• Restrições de distribuição de topologia: Pods que devem ser distribuídos em diferentes zonas, nós ou racks.
• Outras restrições de programação: Qualquer outra restrição que impeça que os pods se movam para outros nós.

Analise e ajuste as regras de afinidade e antiafinidade do pod para que sejam menos restritivas. Ajuste as restrições de distribuição de topologia para permitir mais flexibilidade e outras restrições de programação que possam ser muito restritas.

Prevenção específica de pods

Se houver certos tipos de pods executados em seus nós, talvez o Karpenter não consiga consolidar os nós. O Karpenter não pode remover esses pods devido a anotações, restrições de programação, orçamentos de interrupção de pods (Pod Disruption Budgets, PDBs) ou à falta de um proprietário do controlador. A consolidação pode falhar porque o Karpenter não violará essas preferências, mesmo que o kube-scheduler tecnicamente possa caber nos Pods em outro lugar.