Come posso risolvere i problemi di dimensionamento dei cluster con il dimensionamento automatico di Karpenter in Amazon EKS?

Risoluzione

Risolvi il problema in base al messaggio di errore ricevuto.

Impossibile pianificare i pod di Karpenter a causa dell'insufficienza delle istanze nei gruppi di nodi Amazon EKS

Nota: se ricevi errori quando esegui i comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta Risoluzione degli errori per AWS CLI. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

In Karpenter versione 0.16.0 e successive, il numero di repliche predefinito è passato da 1 a 2. Per ulteriori informazioni, consulta v0.16.0 sul sito web GitHub. Se la capacità dei nodi nel cluster non è sufficiente per supportare il numero di repliche configurato, non puoi pianificare i pod di Karpenter. Poiché Karpenter non è in grado di eseguire il provisioning dei nodi per eseguire i propri pod, la capacità insufficiente causa un esito negativo che si traduce in poi non pianificati. Quindi ricevi il seguente errore:

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

Per risolverlo, intraprendi una delle seguenti azioni:

Riduci le repliche di distribuzione di Karpenter a una

Se la distribuzione di Karpenter non richiede ridondanza, modificala per utilizzare una sola replica. Esegui questo comando:

kubectl scale deployment karpenter --replicas=1

Aumenta la capacità dei nodi per i pod di Karpenter

Per eseguire due repliche di Karpenter, assicurati che sia presente una capacità sufficiente per due repliche. Scegli una delle seguenti opzioni:

Aumenta orizzontalmente il gruppo Auto Scaling

1. Aumenta il numero minimo di istanze nel gruppo Auto Scaling. Esegui questo comando:

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

   Nota: sostituisci your-node-group-name con il nome del tuo gruppo Auto Scaling.
2. Assicurati che siano presenti nodi che Karpenter non gestisce. Controlla la presenza di etichette Karpenter nelle etichette dei nodi (ad esempio, karpenter.sh/nodepool). Esegui questo comando:

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

Utilizza i nodi esistenti

Se il nodo o i nodi di destinazione esistenti hanno etichette Karpenter come **karpenter.sh/nodepool **, rimuovile. Esegui questo comando:

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

Nota: sostituisci your-node-name con il nome del tuo nodo.

Collegamenti del volume ed errori di montaggio

Quando sullo stesso nodo sono pianificati più pod con Persistent Volume Claim (PVC), il nodo potrebbe superare il limite di collegamenti del volume. Quindi potresti ricevere uno dei seguenti messaggi di errore:

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

Per risolvere i problemi di collegamenti ed errori di montaggio per carichi di lavoro con un numero elevato di PVC, completa i seguenti passaggi:

1. Applica topologySpreadConstraints e podAntiAffinity per evitare che i pod con un numero elevato di PVC vengano pianificati sullo stesso nodo. Per ulteriori informazioni, consulta topologySpreadConstraints field (campo topologySpreadConstraints) e Pod affinity example (Esempio di affinità dei pod) sul sito web Kubernetes. Questa azione distribuisce i pod con un numero elevato di PVC su nodi diversi per evitare la concentrazione di collegamenti del volume su un solo nodo.
2. Utilizza driver CSI come il driver Container Storage Interface (CSI) di Amazon Elastic Block Store (Amazon EBS) (aws-ebs-csi-driver) e aggiungi le taint di avvio a NodePool. Queste azioni assicurano che i pod non vengano pianificati prematuramente sui nodi prima che siano completamente pronti.
   Esempio di configurazione per le taint di avvio in Amazon EBS:

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

Errore di plugin di archiviazione obsoleto

Karpenter non supporta i plugin di archiviazione in-tree obsoleti come Amazon EBS. Se utilizzi un Persistent Volume (PV) con provisioning statico e un plugin in-tree, Karpenter non è in grado di scoprire il limite di collegamenti del volume del nodo. Questa situazione può causare errori di pianificazione e potresti ricevere il seguente messaggio di errore:

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

Per risolvere il problema, utilizza driver CSI per Amazon EBS e aggiorna le configurazioni di PV per utilizzare il driver CSI.

Errori di pianificazione o raggruppamento dovuti a richieste di risorse non specificate

Karpenter procede al binpacking dei pod in base alle richieste di risorse. Se le richieste sono troppo poche o nulle, Karpenter potrebbe allocare troppi allo stesso nodo. Questa situazione può portare a conflitti di risorse e limitazione (della larghezza di banda) della CPU. Inoltre, se vengono impostati limiti di memoria e i pod tentano di utilizzare più memoria del loro limite, potrebbero verificarsi terminazioni OOM (Out-Of-Memory). Potresti ricevere il seguente messaggio di errore:

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

Per evitare questi problemi, utilizza le configurazioni LimitRange per impostare richieste minime di risorse per un binpacking accurato. Le configurazioni LimitRange aiutano a stabilire limiti massimi per prevenire un consumo eccessivo. Forniscono inoltre limiti predefiniti per i pod non specificati. Per ulteriori informazioni, consulta Utilizza LimitRanges per configurare le impostazioni predefinite per le richieste e i limiti delle risorse.

I pod di Windows non si avviano con un errore di estrazione dell'immagine

Un pod non si avvia se la versione del sistema operativo del container non corrisponde alla versione del sistema operativo Windows. Ricevi un messaggio di errore simile al seguente:

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

Per risolvere il problema, definisci NodeSelector per il pod in modo da assicurarti che i container siano pianificati su una versione host del sistema operativo compatibile. Per ulteriori informazioni, consulta Compatibilità delle versioni dei container Windows sul sito web Microsoft.

Nodi non inizializzati correttamente

Il sistema determina l'inizializzazione del nodo in base alla sua disponibilità, alla registrazione prevista delle risorse e alla rimozione delle taint di avvio di NodePool. Se una di queste condizioni non viene soddisfatta, il nodo Karpenter non viene inizializzato correttamente e rimane in uno stato Non pronto. Di conseguenza, il sistema non può utilizzarlo per pianificare o consolidare i carichi di lavoro. Potresti ricevere il seguente messaggio di errore:

"Nodes provisioned by Karpenter are in a NotReady state"

Verifica che lo stato del nodo sia Pronto. In caso contrario, ispeziona i log di kubelet per identificare potenziali problemi relativi alle autorizzazioni, ai gruppi di sicurezza o alla rete.

Verifica che tutte le risorse richieste, come nvidia.com/gpu o vpc.amazonaws.com/pod-eni, siano registrate correttamente nel nodo.

Per controllare le risorse nvidia.com/gpu sul nodo, esegui questo comando:

kubectl describe node your-node-name

Nota: sostituisci your-node-name con il nome del tuo nodo.

Esempio di output:

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

Se mancano queste risorse, verifica che il daemonset o i plugin appropriati siano in esecuzione. Per verificare la presenza del daemonset, esegui questo comando:

kubectl get ds -n your-daemonset-namespace

Nota: sostituisci your-daemonset-namespace con il namespace del tuo daemonset.

Errori di pianificazione dovuti a vari vincoli e limitazioni

Il pod non può essere pianificato a causa di vincoli di affinità, antiaffinità o diffusione della topologia

Un pod non viene pianificato se vincoli di affinità, antiaffinità o diffusione della topologia richiedono nodi o zone specifici, ma non esistono nodi adatti nelle posizioni richieste. Se il sistema non riesce a posizionare un pod a causa di requisiti di nodo o zona non soddisfatti, potresti ricevere il seguente messaggio di errore:

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

Per risolvere il problema, rivedi e modifica le impostazioni di affinità e antiaffinità del pod o i vincoli di diffusione della topologia per allinearli ai nodi disponibili. Puoi allentare questi vincoli o eseguire il provisioning di più nodi nelle zone richieste.

Impossibile pianificare il pod a causa di risorse insufficienti

I pod rimangono non pianificati a causa di richieste di risorse che superano la capacità disponibile del nodo. Se non sono disponibili nodi con CPU, memoria o altre risorse sufficienti per accettare il pod, potresti ricevere il seguente messaggio di errore:

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

Per risolvere il problema, assicurati che le richieste di risorse nella specifica del pod riflettano l'utilizzo effettivo. Modifica le richieste e i limiti delle risorse, se necessario, oppure esegui il provisioning di nodi più grandi con maggiore capacità per soddisfare le richieste di risorse.

Alcune taint impediscono la pianificazione dei pod

Quando gli amministratori del cluster applicano taint personalizzate a nodi specifici, i pod devono avere tolleranze corrispondenti. Se non hanno tolleranze corrispondenti, il sistema non può pianificare i pod su quei nodi. Ricevi il seguente messaggio di errore:

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

Per risolvere il problema, aggiungi le tolleranze appropriate alla specifica del pod per consentirgli di tollerare le taint. In alternativa, puoi rimuovere o modificare le taint personalizzate non necessarie sui nodi se sono troppo restrittive.

Per rimuovere una taint da un nodo, esegui questo comando:

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

Nota: sostituisci your-node-name con il nome del tuo nodo e your-custom-taint con il nome della tua taint personalizzata.

I vincoli NodeAffinity o NodeSelector non sono soddisfatti

Se sono presenti vincoli di affinità dei nodi o del selettore di nodi che non corrispondono a alcun nodo disponibile nel cluster, il pianificatore non può posizionare pod. Ricevi il seguente messaggio di errore:

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

Per risolvere il problema, modifica i requisiti di affinità dei nodi o del selettore di nodi del pod per renderli più flessibili. Oppure puoi eseguire il provisioning di nodi aggiuntivi che soddisfano i criteri del pod, se necessario. Per ulteriori informazioni, consulta Node affinity (Affinità dei nodi) e nodeSelector (Selettore di nodi) sul sito web Kubernetes.

Indirizzi IP insufficienti nella sottorete

Quando Karpenter tenta di effettuare il provisioning di nuovi nodi, l'operazione non riesce perché il numero di indirizzi IP nella sottorete è insufficiente. Questa situazione si verifica quando l'intervallo Classless Inter-Domain Routing (CIDR) della sottorete è esaurito e non può ospitare nuove istanze Amazon Elastic Compute Cloud (Amazon EC2). Ricevi il seguente messaggio di errore:

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

Per risolvere il problema, intraprendi una delle seguenti azioni:

Se gli indirizzi IP della sottorete sono esauriti, aggiungi un blocco CIDR IPv4 aggiuntivo come CIDR secondario ad Amazon Virtual Private Cloud (Amazon VPC).

-oppure-

Utilizza una rete personalizzata per assegnare spazi di indirizzi IP separati ai pod e ai nodi. Per attivare una rete personalizzata, esegui questo comando:

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

Per ulteriori informazioni sulle reti personalizzate, consulta Come posso scegliere sottoreti di indirizzi IP specifiche per i pod nel mio cluster Amazon EKS?

Impossibile pianificare un pod a causa di requisiti incompatibili

Karpenter non riesce a pianificare i pod che specificano etichette di gruppi di nodi come eks.amazonaws.com/nodegroup che non corrispondono a alcun valore definito nelle configurazioni del pool di nodi. Se si verifica questa mancata corrispondenza, Karpenter non può posizionare i pod sui nodi perché mancano le etichette dei nodi richieste. Ricevi uno dei seguenti messaggi di errore:

"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 desideri che i pod siano pianificabili da Karpenter, rimuovi il nodeSelector specifico del gruppo di nodi gestiti per risolvere l'errore.

Esempio:

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

Nota: sostituisci your-pod-name, your-deployment-name o your-daemonset-name con il nome del tuo pod, della tua distribuzione o del tuo daemonset.

Errori di consolidamento dei nodi

Il consolidamento dei nodi di Karpenter può avere esito negativo a causa di vincoli di pianificazione o configurazioni dei pod specifiche che ne impediscono la migrazione.

Vincoli di pianificazione

Il consolidamento dei nodi non riesce quando i pod non possono essere eseguire la migrazione per i seguenti motivi:

• Affinità o antiaffinità tra pod: pod che richiedono o evitano la co-localizzazione con altri pod.
• Vincoli di diffusione della topologia: pod che devono essere distribuiti in zone, nodi o rack diversi.
• Altre restrizioni di pianificazione: qualsiasi altro vincolo che impedisca ai pod di spostarsi su altri nodi.

Rivedi e modifica le regole di affinità e antiaffinità dei pod per renderle meno restrittive. Modifica i vincoli di diffusione della topologia per consentire una maggiore flessibilità e altre restrizioni di pianificazione che potrebbero essere troppo rigide.

Prevenzione specifica del pod

Se sui nodi sono in esecuzione determinati tipi di pod, Karpenter potrebbe non essere in grado di consolidarli. Karpenter non riesce a rimuoverli a causa di annotazioni, vincoli di pianificazione, budget per le interruzioni dei pod (PDB) o la mancanza di un proprietario del controller. Il consolidamento potrebbe non riuscire perché Karpenter non viola queste preferenze, anche se kube-scheduler potrebbe tecnicamente inserire i pod altrove.