Come posso risolvere i problemi di pianificazione dei pod correlati alla disponibilità dei nodi in Amazon EKS?

Risoluzione

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.

Memoria insufficiente o errori della CPU

Quando la CPU o la memoria disponibile nei nodi worker non è sufficiente per consentire al pod di raggiungere lo stato In esecuzione, ricevi i seguenti messaggi di errore:

• "Warning FailedScheduling 16m default-scheduler 0/2 nodes are available: 1 Too many pods, 2 Insufficient cpu, 2 Insufficient memory. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod"
• "Warning FailedScheduling 11m default-scheduler 0/2 nodes are available: 1 Insufficient cpu, 1 Insufficient memory, 1 node(s) were unschedulable. preemption: 0/2 nodes are available: 1 No preemption victims found for incoming pod, 1 Preemption is not helpful for scheduling"

Per risolvere i problemi relativi a memoria o CPU insufficiente, procedi nel seguente modo:

1. Avvia una sessione SSH di Gestione sessione (una funzionalità di AWS Systems Manager) con i nodi worker.

2. Esegui questo comando kubectl top node per ottenere la percentuale corrente di utilizzo della CPU e della memoria per ogni nodo:

   kubectl top node

   Nota: per ulteriori informazioni sul comando precedente, consulta kubectl top node sul sito web Kubernetes.

3. Esegui questo comando kubectl describe per ottenere informazioni sulle risorse totali disponibili nel nodo:

   kubectl describe node your_node_name

   Nota: sostituisci your_node_name con il nome del tuo nodo. Per ulteriori informazioni sul comando precedente, consulta kubectl describe sul sito web Kubernetes.
   L'esempio di output seguente mostra le risorse in un nodo che puoi allocare a un pod:

   Allocatable:
     cpu: 1930m
     ephemeral-storage: 18242267924
     hugepages-1Gi: 0
     hugepages-2Mi: 0
     memory: 3388304Ki
     pods: 17

4. Identifica la classe di istanza Amazon Elastic Compute Cloud (Amazon EC2) utilizzata dai nodi worker. Quindi controlla la CPU e la memoria predefinite disponibili nelle istanze.

5. Rivedi i limiti e le richieste di risorse che hai definito nella distribuzione. Per maggiori dettagli, consulta Deployments (Distribuzioni) sul sito web Kubernetes. Se configuri limiti, assicurati che soddisfino i requisiti del carico di lavoro. L'esempio di output seguente mostra i limiti e le richieste di risorse:

   Limits:
     memory: 170Mi
   Requests:
     cpu: 100m
     memory: 70Mi

   Nota: i valori corretti per Limiti e Richieste possono aiutarti a determinare se devi aumentare verticalmente la capacità del nodo worker. Per ulteriori informazioni, consulta Resource Management for Pods and Containers (Gestione delle risorse per pod e container) sul sito web Kubernetes.

Problemi relativi alla quota dell'interfaccia di rete

Quando raggiungi la quota dell'interfaccia di rete elastica nel nodo, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 117s default-scheduler 0/2 nodes are available: 1 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod"

Nota: ogni pod in un cluster Kubernetes ha il proprio indirizzo IP. Il numero di indirizzi IP supportati da un tipo di istanza aiuta a determinare il numero massimo di pod in esecuzione in un nodo worker. Se raggiungi il numero massimo di pod che possono essere eseguiti in un nodo worker, i pod potrebbero rimanere bloccati nello stato In sospeso.

Per verificare il numero massimo di pod che possono essere eseguiti in ogni nodo, esegui questo comando describe-instance-types:

aws ec2 describe-instance-types --filters "Name=instance-type,Values=c5.*" --query "InstanceTypes[].{ Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" --output table

L'output del comando mostra informazioni sul numero massimo di interfacce di rete e indirizzi IPv4 per interfaccia per ogni tipo di istanza. L'output del comando precedente mostra un pod in meno rispetto al numero massimo di pod perché l'output esclude la prima interfaccia di rete (eth0).

Per ulteriori informazioni, consulta Scelta di una tipologia di istanza di nodo Amazon EC2 ottimale. Inoltre, consulta Numero massimo di indirizzi IP per interfaccia di rete.

Per informazioni sul numero massimo di pod che un'istanza può supportare, consulta amazon-vpc-cni-k8s sul sito web GitHub.

Se gli indirizzi IP disponibili nelle istanze correnti del nodo worker non sono sufficienti, intraprendi le seguenti azioni:

• Aumenta verticalmente la classe di istanza a una che supporta più pod. È consigliabile controllare le quote dell'interfaccia di rete prima di eseguire l'aumento verticale.
• Utilizza Karpenter e Cluster Autoscaler per aumentare orizzontalmente il numero di nodi.

Errori relativi a taint o tolleranze

Quando si verifica un problema relativo a taint o tolleranze, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 12s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {NodeType: MemoryOptimized}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling"

Il pod che desideri pianificare richiede un nodo con una taint specifica (NodeType: MemoryOptimized). Tuttavia, la pianificazione non riesce perché il nodo non è disponibile nel cluster.

Per risolvere i problemi relativi a taint o tolleranze, completa i passaggi seguenti:

1. Esegui questo comando kubectl describe per ottenere le taint che hai configurato nel nodo:

   kubectl describe node your_node_name

   Nota: sostituisci your_node_name con il nome del tuo nodo. Puoi pianificare un pod nel nodo solo quando il pod ha una tolleranza corrispondente.

2. Esegui questo comando kubectl describe per ottenere le tolleranze su un pod:

   kubectl describe pod your_pod_name -n your_namespace

   Nota: sostituisci your_pod_name con il nome del tuo pod e your_namespace con il tuo namespace.

Errori relativi all'affinità

Quando si verifica un problema relativo all'affinità di un nodo, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 13s default-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling"

Per risolvere i problemi relativi all'affinità, completa i seguenti passaggi:

1. Aggiorna la configurazione dell'affinità del nodo del pod per utilizzare preferredDuringSchedulingIgnoredDuringExecution invece di requiredDuringSchedulingIgnoredDuringExecution.

   Nota: per pianificare un pod, devi utilizzare requiredDuringSchedulingIgnoredDuringExecution. Il pianificatore di Kubernetes pianifica il pod solo in un nodo conforme alla regola di affinità.

2. Aggiungi nodi al cluster con l'affinità corrispondente in modo che il pianificatore di Kubernetes possa trovare un nodo in cui pianificare il pod.

3. Rimuovi i termini del selettore di nodi dalla distribuzione o aggiorna il gruppo di nodi con un valore che soddisfi la condizione della distribuzione. Scegli l'opzione appropriata in base ai requisiti e alla disponibilità dei nodi nel cluster Kubernetes.

   L'esempio di output seguente mostra una configurazione del selettore di nodi in una distribuzione:

   affinity:
     nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
             - matchExpressions:
               - key: instance-az
                 operator: In
                 values:
                  - az1
                 - az2

4. Esegui questo comando kubectl describe per ottenere i dettagli del nodo:

   kubectl describe node your_node_name

   Nota: sostituisci your_node_name con il nome del tuo nodo.

   L'esempio seguente mostra i dettagli del nodo:

   Name: ip-10-1-1-172.ap-south-1.compute.internal
   Roles: <none>
   Labels: beta.kubernetes.io/arch=amd64
                beta.kubernetes.io/instance-type=t3.medium
                beta.kubernetes.io/os=linux
                instance-az=az1

Nota: il valore della chiave che hai definito nella distribuzione deve essere nel nodo in modo che Kubernetes possa collocarvi il pod.

Errori relativi ai gruppi di sicurezza dei pod

In caso di problemi con i gruppi di sicurezza dei pod, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 3s default-scheduler 0/3 nodes are available: 1 Insufficient vpc.amazonaws.com/pod-eni, 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming Pod, 2 Preemption is not helpful for scheduling"

Nota: quando utilizzi gruppi di sicurezza per i pod in Amazon EKS, il VPC Resource Controller crea un'interfaccia di rete di ramificazione per ogni pod. Il VPC Resource Controller crea anche un'interfaccia di rete trunk nel nodo worker per gestire l'interfaccia di rete di ramificazione.

Importante: per utilizzare gruppi di sicurezza per i pod, devi avviare i nodi worker in tipi di istanza Nitro, come le famiglie C5, M5, R5 e T3. I tipi di istanza Nitro supportano la funzionalità di interfaccia di rete necessaria per ospitare l'interfaccia di rete di ramificazione per i pod.

Per risolvere il problema relativo al gruppo di sicurezza del pod, completa i seguenti passaggi:

1. Esegui questo comando kubectl describe per verificare che l'istanza del nodo worker supporti un'interfaccia trunk:

   kubectl describe node your_node_name

   Nota: sostituisci your_node_name con il nome del tuo nodo.

2. Nella descrizione del nodo presente nell'output del comando precedente, controlla gli eventi del VPC Resource Controller.
   L'output seguente mostra un esempio di istanza incompatibile:

   Events:
     Type     Reason                   Age                    From                             Message
     ----     ------                   ----                   ----                             -------
     Normal   RegisteredNode           22m                    node-controller                  Node ip-192-168-59-29.us-east-2.compute.internal event: Registered Node ip-192-168-59-29.us-east-2.compute.internal in Controller
     Normal   ControllerVersionNotice  21m                    vpc-resource-controller          The node is managed by VPC resource controller version v1.4.9
     Normal   NodeReady                21m                    kubelet                          Node ip-192-168-59-29.us-east-2.compute.internal status is now: NodeReady
     Warning  Unsupported              13m (x16 over 21m)     vpc-resource-controller          The instance type t3.small is not supported for trunk interface (Security Group for Pods)
   

Errori relativi a Fargate che non supporta il pod

Quando AWS Fargate non supporta il pod, ricevi il seguente messaggio di errore:

"Warning FailedScheduling <unknown> fargate-scheduler Pod not supported on Fargate: volumes not supported: mysql-db not supported because: PVC mysql-db not bound"

I pod eseguiti su Fargate e che utilizzano un volume Amazon Elastic File System (Amazon EFS) hanno gli stessi requisiti dei pod normali. Fargate non pianifica un pod quando le risorse PersistentVolume e PersistentVolumeClaim necessarie non sono nel cluster.

Per risolvere il problema relativo a un pod non supportato da Fargate, completa i seguenti passaggi:

1. Crea e configura correttamente le risorse PersistentVolume e PersistentVolumeClaim richieste nel cluster. Per ulteriori informazioni, consulta Configure a Pod to Use a PersistentVolume for Storage (Configurazione di un pod per utilizzare un volume persistente per l'archiviazione) sul sito web Kubernetes.
2. Verifica se sono presenti problemi con le risorse PersistentVolume e PersistentVolumeClaim quando il volume è associato al pod. Ad esempio, potresti avere problemi relativi al file system EFS, alle autorizzazioni o di altro genere.

Errori relativi a Fargate che non supporta il tipo di volume

Quando il pod contiene la definizione di tipo di volume non supportato, ricevi il seguente messaggio di errore:

"Warning FailedScheduling <unknown> fargate-scheduler Pod not supported on Fargate: volumes not supported: admin-panel is of an unsupported volume Type"

Importante: non puoi montare volumi Amazon Elastic Block Store (Amazon EBS) in pod Fargate.

Per risolvere il problema relativo a un tipo di volume non supportato, intraprendi le seguenti azioni:

• Assicurati che la definizione del pod specifichi un volume EFS e non un volume EBS o un altro tipo di volume non supportato.
• Verifica di aver configurato correttamente le risorse PersistentVolume e PersistentVolumeClaim e che facciano riferimento a un file system EFS.
• Verifica se sono presenti problemi relativi al file system, alle autorizzazioni o alla configurazione di EFS che potrebbero causare il mancato collegamento del volume al pod.

Errori relativi al contesto di sicurezza in Fargate

Quando un contesto di sicurezza non è valido, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 109s fargate-scheduler Pod not supported on Fargate: invalid SecurityContext fields: Privileged"

Per risolvere il problema relativo al contesto di sicurezza, assicurati che i pod Fargate rispettino i seguenti requisiti:

• La definizione del pod non può specificare il contesto di sicurezza del container con privilegi. Fargate non accetta container con privilegi.
• La definizione del pod non può montare il file system root dell'host (/) nel container. Fargate isola i container dal file system root dell'host.

Errori relativi a un pianificatore non corretto in Fargate

Se utilizzi Amazon EKS con profili Fargate o pianificatori personalizzati, potresti non avere il pianificatore Kubernetes corretto per gestire i pod.

Per risolvere i problemi relativi al pianificatore, completa i seguenti passaggi:

1. Analizza gli eventi del pod.
   L'esempio seguente mostra che il pianificatore predefinito non riesce a trovare un nodo per il pod perché una taint è associata al tipo di calcolo Fargate:

   Events:
   Type     Reason            Age        From               Message
   ----     ------            ----       ----               -------
   Warning  FailedScheduling  109s       default-scheduler  0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..

   Nota: i pod di Fargate devono essere pianificati da fargate-scheduler.

2. Esegui questo comando kubectl get mutatingwebhookconfigurations per verificare di aver installato il webhook Fargate nel cluster:

   kubectl get mutatingwebhookconfigurations 0500-amazon-eks-fargate-mutation.amazonaws.com

Se l'output mostra la configurazione del webhook e fargate-scheduler non riesce a prelevare il pod, verifica la presenza di altre configurazioni webhook mutanti personalizzate che potrebbero entrare in conflitto. Ad esempio, un webhook in conflitto potrebbe causare il problema perché Fargate elabora i webhook in ordine alfabetico.

Errori relativi al conflitto tra porte

In caso di conflitto tra porte nel computer host su cui il pianificatore Kubernetes pianifica il pod, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 10s default-scheduler 0/2 nodes are available: 1 node(s) didn't have free ports for requested pod ports. 1 node(s) didn't match the requested hostname"

L'errore si verifica perché hai configurato più pod con lo stesso valore hostPort, oppure un altro processo nel computer host sta già eseguendo la porta.

Quando configuri un pod con hostNetwork: true, i container in esecuzione all'interno del pod hanno accesso diretto alle interfacce di rete del computer host. Di conseguenza, le porte del container sono esposte direttamente alla rete esterna sulle porte host corrispondenti.

Per risolvere i problemi relativi al conflitto tra porte, completa i seguenti passaggi:

1. Esegui questo comando kubectl describe per controllare le configurazioni delle porte:

   kubectl describe deploy nginx-deployment

   L'esempio di output seguente mostra dove si trovano le informazioni sulla porta:

       spec:
         hostNetwork: true
         containers:
         - name: nginx
           image: nginx:latest
           ports:
           - containerPort: 80
             hostPort: 80

2. Modifica la rete o la porta host. Ad esempio, puoi impostare hostNetwork sul valore predefinito false per assegnare un'interfaccia di rete virtuale al pod. Puoi anche aggiornare la configurazione del pod per utilizzare una porta host diversa che non sia già in uso nel computer host. Per consentire al kernel di assegnare automaticamente una porta host casuale ai pod, imposta hostPort su 0 come nell'esempio seguente:

     Containers:
      nginx:
       Image:        nginx:latest
       Port:         80/TCP
       Host Port:    0/TCP

3. Pianifica il pod su un host diverso. Se il conflitto tra porte è specifico del computer host su cui desideri pianificare il pod, pianificalo in un nodo diverso. Il nodo deve trovarsi nel cluster Kubernetes. Puoi anche utilizzare la logica di affinità. Per ulteriori informazioni, consulta Modelli di orientamento prescrittivi AWS.

Errori relativi all'affinità tra nodi in conflitto

Quando le regole di affinità tra nodi sono in conflitto, ricevi il seguente messaggio di errore:

"Warning FailedScheduling 57s (x3 over 3m3s) default-scheduler 0/15 nodes are available: 1 node(s) were unschedulable, 14 node(s) had volume node affinity conflict"

L'errore si verifica quando i requisiti di volume del pod non sono soddisfatti per i nodi disponibili a causa di regole di affinità tra nodi in conflitto.

Per risolvere il problema relativo all'affinità tra nodi in conflitto, completa i seguenti passaggi:

1. Identifica le regole di affinità tra nodi in conflitto nelle definizioni del pod e del volume. Ad esempio, il pod potrebbe avere una regola di affinità tra nodi che richiede l'etichetta node-type=high-storage, ma il volume richiede l'etichetta node-type=ssd-storage.

2. Per risolvere il conflitto tra regole, aggiorna le regole di affinità tra nodi per il pod o per il volume. Ad esempio, aggiorna la regola di affinità tra nodi del pod in modo che corrisponda ai requisiti del volume, come nell'esempio seguente:

   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
         - matchExpressions:
           - key: node-type
             operator: In
             values:
             - ssd-storage

3. Verifica che le etichette dei nodi corrispondano alle regole di affinità. Quindi verifica che i nodi disponibili nel cluster abbiano le etichette corrette per soddisfare i nuovi requisiti. Per elencare i nodi e le relative etichette, esegui questo comando kubectl get nodes:

   kubectl get nodes --show-labels

   Nota: assicurati di avere nodi disponibili con l'etichetta node-type=ssd-storage richiesta.

4. Modifica i gruppi di nodi o aggiungine di nuovi. Se utilizzi gruppi di nodi e i nodi non hanno le etichette richieste, aggiorna i gruppi di nodi esistenti. Oppure crea nuovi gruppi di nodi con le etichette e i tipi di istanza appropriati.

Errori relativi alla mancanza di zone di volume disponibili

Quando provi a distribuire un pod nel cluster e non hai una zona di volume disponibile, ricevi i seguenti messaggi di errore:

• "Warning FailedScheduling 60s (x5 over 60s) default-scheduler Pod has unbound PersistentVolumeClaims (repeated 2 times)"
• "Warning FailedScheduling 2s (x16 over 59s) default-scheduler 0/2 nodes are available: 2 node(s) had no available volume zone"

I requisiti di volume del pod non sono soddisfatti perché le zone di volume disponibili e i vincoli delle zone di volume del pod non corrispondono.

Per risolvere il problema relativo alla mancanza di zone di volume disponibili, completa i seguenti passaggi:

1. Analizza le definizioni del pod e del volume per identificare i vincoli specifici delle zone di volume che causano il problema relativo alla mancanza di zone di volume disponibili. Ad esempio, controlla se hai impostato il pod o il volume per utilizzare una zona di disponibilità in cui non sono in esecuzione nodi worker.

2. Esegui questo comando kubectl get pv per verificare quali zone di volume sono disponibili nel cluster:

   kubectl get pv --all-namespaces -o jsonpath='{range .items[*]}{.spec.awsElasticBlockStore.availabilityZone}{"\n"}{end}' | sort | uniq

   Nota: assicurati che l'elenco di output includa le zone di volume richieste dal pod o dal volume.

3. Aggiorna i vincoli delle zone del volume. Se la zona di volume richiesta non è disponibile, aggiorna la configurazione del pod o del volume. La configurazione deve limitare la creazione di volumi solo alle zone di disponibilità in cui sono in esecuzione i nodi worker.

4. Verifica che i gruppi di nodi si estendano su più zone di disponibilità. Se i gruppi di nodi non si estendono su più zone, crea nuovi gruppi di nodi che includano le zone di volume richieste.