Global outage event
If you’re experiencing issues with your AWS services, then please refer to the AWS Health Dashboard. You can find the overall status of ongoing outages, the health of AWS services, and the latest updates from AWS engineers.
Perché il mio Amazon EKS Pod è bloccato nello stato ContainerCreating con l'errore "failed to create pod sandbox"?
Il mio pod Amazon Elastic Kubernetes Service (Amazon EKS) è bloccato nello stato ContainerCreating con l'errore "failed to create pod sandbox".
Risoluzione
Prerequisiti
Determina quale pod ha un problema. Completa i seguenti passaggi:
-
Esegui questo comando per elencare i pod nel cluster e identificare quelli nello stato ContainerCreating:
kubectl get pods --all-namespaces -o wide -
Esegui questo comando per recuperare i dettagli su ogni pod nello stato ContainerCreating:
kubectl describe pod pod-name -n pod-namespaceNota: sostituisci pod-name con il nome del tuo pod e pod-namespace con il namespace in cui si trova il tuo pod.
-
Esamina l'output in Eventi per identificare i pod, quindi utilizza le seguenti sezioni per risolvere il problema.
Errore "Resource temporarily unavailable"
Se le impostazioni del kernel definite per PID o file superano il limite massimo per il sistema operativo, ricevi un messaggio di errore simile al seguente:
"kubelet, ip-192-168-0-1.us-east-1.compute.internal Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for Pod "example_pod": Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown"
Per risolvere temporaneamente il problema, riavvia il nodo.
Per risolvere il problema alla radice, completa i seguenti passaggi:
-
Raccogli i log dei nodi per Containerd e il kubelet.
Per Windows, connettiti all'istanza. Apri un prompt dei comandi di PowerShell e utilizza lo script di raccolta dei log EKS per Windows per raccogliere i log dei nodi worker. Per ulteriori informazioni, consulta EKS Logs Collector (Windows) (Programma di raccolta di log EKS (Windows)) sul sito web GitHub. Esegui questo comando:Invoke-WebRequest -OutFile eks-log-collector.ps1 https://raw.githubusercontent.com/awslabs/amazon-eks-ami/main/log-collector-script/windows/eks-log-collector.ps1 .\eks-log-collector.ps1Per Linux, connettiti all'istanza. Quindi utilizza lo script di raccolta dei log EKS per Linux per raccogliere i log dei nodi worker. Per ulteriori informazioni, consulta EKS Logs Collector (Linux) (Programma di raccolta di log EKS (Linux)) sul sito web GitHub. Esegui questo comando per scaricare lo script di raccolta dei log:
curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh -
Quindi esegui lo script scaricato:
sudo bash eks-log-collector.sh -
Esamina il log del kubelet per individuare le risposte di errore seguenti:
"kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)""kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)" -
Identifica i processi zombi e arresta quelli che non sono necessari.
Per Windows, apri Gestione attività, quindi scegli la scheda Dettagli. Controlla i processi che mostrano lo stato Non risponde per identificare i processi zombi.
Per Linux, esegui questo comando ps per verificare la presenza di processi zombie elencati nello stato Z:ps aux | egrep "Z|defunct"Per ulteriori informazioni, consulta How to kill Zombie processes on Linux (Come arrestare i processi zoombie in Linux) sul sito web Linux Journal.
Errore "Network plugin cni failed to set up pod network"
Se il plugin Container Network Interface (CNI) non è in grado di assegnare un indirizzo IP al pod appena creato, potresti ricevere il seguente messaggio di errore:
"Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container"
L'errore può verificarsi per diversi motivi, che principalmente rientrano in tre categorie:
Limitazioni delle risorse:
- IP di sottorete esauriti
- Raggiunto il limite massimo di collegamenti ENI
Problemi di configurazione:
- Policy CNI IAM mancante sui nodi worker
- Pod (aws-node) CNI VPC non In esecuzione
- Versioni obsolete di CNI VPC, kube-proxy o CoreDNS
- Gruppi di sicurezza o liste di controllo degli accessi non configurati correttamente
Problemi specifici dell'architettura:
- Disallineamento della configurazione tra CNI VPC e caso d'uso
- Configurazione OpenID Connect (OIDC) mancante
- Componenti aggiuntivi self-managed anziché gestiti da EKS
Per una procedura dettagliata di risoluzione dei problemi, consulta Come faccio a risolvere i problemi relativi ai plugin kubelet o CNI per Amazon EKS?
È consigliabile eseguire queste operazioni:
- Utilizza una rete personalizzata per il plugin CNI VPC che ti consenta di distribuire pod su sottoreti alternative.
- Attiva la modalità di delega del prefisso. Per ulteriori informazioni, consulta Modalità prefisso per Windows.
- Utilizza il gruppo di sicurezza per i pod (Gruppo di sicurezza per pog) per assegnare gruppi di sicurezza personalizzati a più pod tramite ENI di branch su un nodo worker.
Nota: se apporti modifiche alla configurazione CNI, devi riavviare i nodi interessati affinché le modifiche abbiano effetto.
Errore "Error while dialing"
Se il Pod aws-node non è riuscito a comunicare con IPAM perché il pod aws-node non è stato eseguito sul nodo, ricevi un errore simile al seguente:
"Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"
L'errore si verifica nei seguenti casi:
Plugin CNI VPC nello stato In sospeso
Errori dei controlli Liveness e Readiness possono verificarsi a causa di configurazioni delle regole di sicurezza o errori dell'applicazione. Anche l'esaurimento delle risorse può causare ritardi. Generalmente, gli errori possono verificarsi se DISABLE_TCP_EARLY_DEMUX è impostato su false con POD_SECURITY_GROUP_ENFORCING_MODE in modalità rigorosa.
Se utilizzi gruppi di sicurezza per pod e controlli Liveness o Readiness, imposta DISABLE_TCP_EARLY_DEMUX su true in modalità rigorosa. Ciò consente al kubelet di utilizzare il protocollo TCP per connettersi ai pod sulle interfacce di rete delle branch.
Problemi con i plugin CNI gestito
aws-node non supera i controlli quando viene aggiunto come plugin gestito nella Console di gestione AWS. Ciò accade perché i plugin gestiti sovrascrivono l'account di servizio.
Per risolvere il problema, intraprendi una delle seguenti azioni:
- Rimuovi il componente aggiuntivo gestito dalla Console di gestione AWS. Quindi ricrealo con il ruolo IAM corretto che fornisce la policy IAM AmazonEKS_CNI_Policy richiesta.
- Modifica l'account di servizio aws-node esistente per associarlo al ruolo IAM corretto con le autorizzazioni CNI richieste.
- Se utilizzi Pod Identity sul cluster, crea la necessaria Associazione Pod Identity che associa l'account di servizio aws-node al ruolo IAM che deve essere utilizzato dal plugin CNI VPC.
Raccomandazioni aggiuntive:
- Utilizza le ultime versioni di CNI VPC (aws-node), kube-proxy e coredns.
Errore "Failed to setup network for sandbox"
Se utilizzi Enable Prefix delegation (Abilita delega del prefisso) nei pod CNI VPC (aws-node), potresti ricevere il seguente messaggio di errore:
"Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox"
Per ulteriori informazioni al riguardo, controlla i log del daemon di gestione degli indirizzi IP (IP Address Management Daemon, IPAMD) in /var/log/aws-routed-eni/ipamd.log nel nodo worker.
Anche se la sottorete ha indirizzi IP disponibili, se la sottorete non ha blocchi /28 contigui di indirizzi IP disponibili, si verifica un errore. L'errore si manifesta quando la frammentazione degli indirizzi IP secondari esistenti si estende su una sottorete. L'errore viene visualizzato nel plugin CNI di Amazon VPC per i log di Kubernetes o negli eventi di CloudTrail per il nodo worker interessato. Potresti ricevere il seguente messaggio di errore:
"InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"
Per risolvere l'errore, intraprendi una delle seguenti azioni:
Crea una nuova sottorete, quindi avvia i pod nella nuova sottorete.
-oppure-
Utilizza una prenotazione CIDR su sottorete di Amazon EC2 per riservare spazio all'interno di una sottorete da utilizzare con l'assegnazione di un prefisso.
Se passi dall'assegnazione di un indirizzo IP all'assegnazione di un prefisso IP, crea nuovi gruppi di nodi. Dopodiché puoi aumentare il numero di indirizzi IP disponibili anziché eseguire una sostituzione progressiva dei nodi esistenti.
Se esegui pod su un nodo a cui sono assegnati sia indirizzi IP che prefissi IP, ciò può causare incoerenze nella capacità degli indirizzi IP pubblicizzati. Questa situazione può influire sui carichi di lavoro futuri sul nodo. Per risolvere il problema, segui la procedura descritta in Assegna più indirizzi IP ai nodi Amazon EKS con prefissi.
Errore "Pod does not have label" di nodi Windows
Se un pod non ha un nodeSelector pianificato su un nodo Windows, potresti ricevere un messaggio di errore simile al seguente:
"Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address" or "Pod does not have label vpc.amazonaws.com/PrivateIPv4Address"
Per risolvere il problema, assicurati di includere le seguenti etichette in PodSpec per il parametro nodeSelector:
nodeSelector: kubernetes.io/os: windows kubernetes.io/arch: amd64
Verifica di aver impostato il parametro enable-windows-ipam su true nella configmap amazon-vpc-cni.
Se non hai una configmap amazon-vpc-cni, utilizza il seguente modello e caricalo nel cluster:
apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
Riavvia i pod aws-node e node-windows.
Per ulteriori informazioni sulla distribuzione di nodi Windows in cluster Amazon EKS, consulta Implementazione di nodi Windows su cluster EKS.
Errore del gruppo di sicurezza
In caso di problemi relativi al gruppo di sicurezza, verrà visualizzato un errore simile al seguente:
"Plugin type="aws-cni" name="aws-cni" failed (add): add cmd: failed to assign an IP address to container
Vpc-resource-controller failed to allocate branch ENI to pod: creating network interface, NoCredentialProviders: no valid providers in chain. Deprecated."
Questa risposta di errore può indicare un problema con il piano di controllo (control-plane) health.kubernetes. Per risolvere il problema, contatta il Supporto AWS.
Informazioni correlate
Come faccio a risolvere i problemi relativi ai plugin kubelet o CNI per Amazon EKS?
Come posso risolvere i problemi relativi a un provider OIDC e IRSA in Amazon EKS?
Come posso risolvere gli errori IRSA in Amazon EKS?
Configurare il plugin Amazon VPC CNI per utilizzare IRSA in Amazon EKS
- Argomenti
- Containers
- Lingua
- Italiano
Video correlati


Contenuto pertinente
AWS UFFICIALEAggiornata 4 mesi fa