Warum steckt mein Amazon-EKS-Pod im Status „ContainerCreating“ mit dem Fehler „Failed to create pod sandbox“ fest?

Lesedauer: 11 Minute

Mein Amazon Elastic Kubernetes Service (Amazon EKS)-Pod steckt im Status „ContainerCreating“ fest und ich erhalte die Fehlermeldung „failed to create pod sandbox“.

Lösung

Voraussetzungen

Ermittle, bei welchem Pod ein Problem aufgetreten ist. Führe die folgenden Schritte aus:

Führe den folgenden Befehl aus, um die Pods im Cluster aufzulisten und Pods im Status ContainerCreating zu identifizieren:

kubectl get pods --all-namespaces -o wide

Führe den folgenden Befehl aus, um die Details zu jedem Pod im Status ContainerCreating abzurufen:
```
kubectl describe pod pod-name -n pod-namespace
```
Hinweis: Ersetze pod-name durch den Namen deines Pods und pod-namespace durch den Namespace, in dem sich dein Pod befindet.
Überprüfe die Ausgabe in den Ereignissen, um die Pods zu identifizieren, und verwende dann die folgenden Abschnitte, um das Problem zu beheben.

Fehler „Resource temporarily unavailable“

Wenn die definierten Kernel-Einstellungen für PID oder Dateien das maximale Limit für das Betriebssystem überschreiten, erhältst du eine Fehlermeldung, die der folgenden ähnelt:

„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“

Starte den Knoten neu, um das Problem vorübergehend zu beheben.

Gehe wie folgt vor, um das Problem zu beheben:

Sammle die Knotenprotokolle für Containerd und Kubelet.
Stelle unter Windows eine Verbindung zur Instance her. Öffne eine PowerShell-Eingabeaufforderung und verwende dann das Windows-EKS-Protokollsammler-Skript, um die Worker-Knotenprotokolle zu sammeln. Weitere Informationen findest du unter EKS Logs Collector (Windows) (EKS-Protokollsammler (Windows)) auf der GitHub-Website. Führe den folgenden Befehl aus:

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

Stelle unter Linux eine Verbindung zur Instance her. Verwende dann das Linux-EKS-Protokollsammler-Skript, um die Worker-Knotenprotokolle zu sammeln. Weitere Informationen findest du unter EKS Logs Collector (Linux) (EKS-Protokollsammler (Linux)) auf der GitHub-Website. Führe den folgenden Befehl aus, um das Protokollsammler-Skript herunterzuladen:

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

Führe dann das heruntergeladene Skript aus:

sudo bash eks-log-collector.sh

Überprüfe das Kubelet-Protokoll auf die folgenden Fehlermeldungen:
„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)“
Identifiziere die Zombie-Prozesse und stoppe dann diejenigen, die nicht erforderlich sind.
Öffne unter Windows den Task-Manager und wähle dann die Registerkarte Details. Suche nach Prozessen, die den Status Reagiert nicht anzeigen, um die Zombie-Prozesse zu identifizieren.
Führe unter Linux den folgenden Befehl ps aus, um nach Zombie-Prozessen zu suchen, die im Status Z aufgeführt sind:
```
ps aux | egrep "Z|defunct"
```
Weitere Informationen findest du unter How to kill Zombie processes on Linux (So beendest du Zombie-Prozesse unter Linux) auf der Linux-Journal-Website.

Fehler „Network plugin cni failed to set up pod network“

Wenn die Container Network Interface (CNI, Container-Netzwerk-Schnittstelle) dem neu erstellten Pod keine IP-Adresse zuweisen kann, erhältst du möglicherweise die folgende Fehlermeldung:

„Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container“

Dieser Fehler kann aus verschiedenen Gründen auftreten und fällt hauptsächlich in drei Kategorien:

Ressourcenbeschränkungen:

Erschöpfte Subnetz-IPs
Maximales ENI-Anhangslimit erreicht

Probleme mit der Konfiguration:

Fehlende IAM-CNI-Richtlinie auf Worker-Knoten
VPC CNI (aws-node)-Pod ist nicht im Status Wird ausgeführt
Veraltete Versionen von VPC CNI, Kube-Proxy oder CoreDNS
Falsch konfigurierte Sicherheitsgruppen oder Zugriffssteuerungslisten

Architekturspezifische Herausforderungen:

Die VPC-CNI-Konfiguration passt nicht zu deinem Anwendungsfall
Fehlende OpenID Connect (OIDC)-Konfiguration
Selbstverwaltete Add-ons statt EKS-verwalteter Add-ons

Detaillierte Schritte zur Problembehandlung findest du unter Wie löse ich Probleme mit dem Kubelet- oder CNI-Plug-in für Amazon EKS?

Es hat sich bewährt, Folgendes zu tun:

Verwende ein benutzerdefiniertes Netzwerk für die VPC-CNI, mit dem du Pods in alternativen Subnetzen bereitstellen kannst.
Aktiviere den Modus Präfixdelegierung. Weitere Informationen findest du unter Präfixmodus für Windows.
Verwende Security Group for Pods (Sicherheitsgruppe für Pods), um mithilfe von Zweig-ENIs auf einem Worker-Knoten mehreren Pods benutzerdefinierte Sicherheitsgruppen zuzuweisen.

Hinweis: Wenn du Änderungen an der CNI-Konfiguration vornimmst, musst du die betroffenen Knoten neu starten, damit die Änderungen wirksam werden.

Fehler „Error while dialing“

Wenn der aws-node-Pod nicht mit IPAM kommunizieren konnte, weil der aws-node-Pod auf dem Knoten nicht ausgeführt werden konnte, wird eine Fehlermeldung ähnlich der folgenden angezeigt:

„Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused“

Der Fehler tritt in den folgenden Szenarien auf:

VPC CNI im Status „Ausstehend“

Aufgrund von Sicherheitsregelkonfigurationen oder Anwendungsfehlern kann es zu Fehlern beim Live- und Bereitschaftstest kommen. Die Erschöpfung der Ressourcen kann ebenfalls zu Verzögerungen führen. Normalerweise können die Fehler auftreten, wenn DISABLE_TCP_EARLY_DEMUX auf „falsch“ gesetzt ist, während POD_SECURITY_GROUP_ENFORCING_MODE im Strict-Modus ist.

Wenn du Sicherheitsgruppen pro Pods und Live- oder Bereitschaftstests verwendest, setze DISABLE_TCP_EARLY_DEMUX im Strict-Modus auf „wahr“. Dadurch kann das Kubelet TCP verwenden, um eine Verbindung zu Pods auf Zweignetzwerkschnittstellen herzustellen.

Probleme mit von CNI verwalteten Plug-ins

Der aws-node schlägt bei Tests fehl, wenn er als verwaltetes Plug-in zur AWS-Managementkonsole hinzugefügt wird. Das passiert, weil verwaltete Plug-ins das Servicekonto überschreiben.

Gehe wie folgt vor, um dieses Problem zu beheben:

Entferne das verwaltete Add-on aus der AWS-Managementkonsole. Erstelle es dann erneut mit der richtigen IAM-Rolle, welche die erforderliche AmazonEKS_CNI_Policy-IAM-Richtlinie bereitstellt.
Bearbeite das vorhandene aws-node-Servicekonto, um es der richtigen IAM-Rolle zuzuordnen, die über die erforderlichen CNI-Berechtigungen verfügt.
Wenn du Pod Identity auf dem Cluster verwendest, erstelle die erforderliche Pod-Identity-Zuordnung, die das aws-node-Servicekonto an die IAM-Rolle bindet, die von der VPC-CNI verwendet werden soll.

Zusätzliche Empfehlungen:

Verwende die neuesten Versionen von VPC CNI (aws-node), kube-proxy und coredns.

Fehler „Failed to setup network for sandbox“

Wenn du in den VPC-CNI-Pods (aws-node) die Option „Enable Prefix delegation“ (Präfixdelegierung aktivieren) verwendest, wird möglicherweise die folgende Fehlermeldung angezeigt:

„Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox“

Weitere Informationen zu diesem Problem findest du in den IP Address Management Daemon (IPAMD)-Protokollen unter /var/log/aws-routed-eni/ipamd.log in deinem Worker-Knoten.

Selbst wenn das Subnetz über verfügbare IP-Adressen verfügt, tritt ein Fehler auf, wenn das Subnetz keine zusammenhängenden /28-Blöcke von IP-Adressen zur Verfügung hat. Der Fehler tritt auf, wenn sich die Fragmentierung vorhandener sekundärer IP-Adressen über ein Subnetz ausbreitet. Der Fehler erscheint im Amazon-VPC-CNI-Plug-in für Kubernetes-Protokolle oder in den CloudTrail-Ereignissen für den betroffenen Worker-Knoten. Möglicherweise erhältst du die folgende Fehlermeldung:

„InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request“

Führe eine der folgenden Optionen aus, um diesen Fehler zu beheben:

Erstelle ein neues Subnetz und starte dann dort die Pods.

-oder-

Verwende eine CIDR-Reservierung des Amazon-EC2-Subnetzes, um Speicherplatz innerhalb eines Subnetzes für die Verwendung mit einer Präfixzuweisung zu reservieren.

Wenn du von der IP-Adresszuweisung zur IP-Präfixzuweisung wechselst, erstelle neue Knotengruppen. Dann kannst du die Anzahl der verfügbaren IP-Adressen erhöhen, anstatt die vorhandenen Knoten fortlaufend zu ersetzen.

Wenn du Pods auf einem Knoten ausführst, dem sowohl IP-Adressen als auch Präfixe zugewiesen sind, kann dies zu Inkonsistenzen bei der beworbenen IP-Adresskapazität führen. Dieses Szenario kann sich auf die zukünftigen Workloads auf dem Knoten auswirken. Um dieses Problem zu lösen, befolge die Schritte unter Zuweisen weiterer IP-Adressen zu Amazon-EKS-Knoten mit Präfixen.

Fehler „Container image authentication“

Wenn die Container-Laufzeit nicht über die erforderlichen Berechtigungen verfügt, um ein Image abzurufen, erhältst du möglicherweise eine Fehlermeldung ähnlich der folgenden:

„pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials“

Um diesen Fehler zu beheben, überprüfe Folgendes:

Überprüfe die IAM-Rolle, die dem EKS-Worker-Knoten zugeordnet ist. Wenn die IAM-Richtlinie AmazonEC2ContainerRegistryReadOnly fehlt, hänge diese Richtlinie an.
Wenn du Images aus einem ECR-Repository aus einem anderen Konto abrufst, siehe Wie erlaube ich einem sekundären Konto, Bilder in meine Amazon-ECR-Bild-Repositorys mithilfe von Push oder mithilfe von Pull zu übertragen? Stelle sicher, dass die Repository-Richtlinie mit den richtigen Berechtigungen konfiguriert ist.
Wenn du ECR-VPC-Endpunkte zum Abrufen von Images verwendest. Stelle sicher, dass die Sicherheitsgruppe des VPC-Endpunkts eingehenden HTTPS-Datenverkehr auf Port 443 von der Sicherheitsgruppe des EKS-Knotens zulässt. Weitere Informationen findest du unter VPC-Endpunkte der Amazon ECR-Schnittstelle (AWS PrivateLink).
Bei containerd wird das Pause-Image nur während des Bootstrap-Vorgangs abgerufen. Das Image muss danach auf der Instance beibehalten werden. Verwende keine benutzerdefinierten Bereinigungsskripte oder manuellen Löschbefehle wie crictl rmi —prune, um die Pause-Images zu entfernen. Lasse kubelet die Garbage Collection (gc) durchführen, die automatisch alle 1–2 Minuten ausgeführt wird. Wenn du containerd-Pause-Container-Images entfernst, können neue Pods nicht gestartet werden. Aktuelle Pods laufen ohne Probleme auf den Knoten und die kubelet-Protokolle zeigen den Fehler „Failed to create pod sandbox“.

Wenn du das Pause-Container-Image von deinem EKS-Worker-Knoten gelöscht hast, führe die folgenden Schritte aus:

Um zu überprüfen, ob dein EKS-Worker-Knoten Pause-Images enthält, führe den folgenden Befehl aus:

ctr -n k8s.io images ls | grep -o "602401143452.dkr.ecr.YOUR-REGION.amazonaws.com/eks/pause:3.10"

Hinweis: Ersetze YOUR-REGION durch deine AWS-Region.

Wenn der EKS-Worker-Knoten Pause-Images enthält, sieht die Ausgabe etwa wie folgt aus:

602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10
602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:3.10

Um zu überprüfen, ob dein EKS-Worker-Knoten gelöscht wurde, führe den folgenden Befehl aus:

ctr -n k8s.io images ls | grep -o "localhost/kubernetes/pause:latest"

Wenn die Images gelöscht wurden, sieht die Ausgabe etwa wie folgt aus:

ctr -n k8s.io images list |grep -i pause

Um das Image abzurufen und das ECR-Authentifizierungstoken zu erhalten, führe die folgenden Befehle aus:

ECR_REGION=YOUR-REGION
ECR_PASSWORD=$(aws ecr get-login-password --region $ECR_REGION)

Hinweis: Ersetze YOUR-REGION durch deine AWS-Region.

Rufe das Pause-Image aus ECR ab. Stelle sicher, dass du die richtige Pause-Image-Version verwendest. Wenn du dir bei der Image-Version nicht sicher bist, melde dich bei einem deiner Worker-Knoten an und ermittle dort die Image-Version.

Zum Beispiel:

sudo ctr -n k8s.io image pull --user "AWS:$ECR_PASSWORD" 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion>

Hinweis: Du kannst die neueste Image-Version unter Versionen auf der GitHub-Website auswählen.

Tagge das Image für EKS als localhost.

Zum Beispiel:

sudo ctr -n k8s.io image tag 602401143452.dkr.ecr.aws.example.region.amazonaws.com/eks/pause:<ImageVersion> localhost/kubernetes/pause:latest

Nachdem das Pause-Image wieder vorhanden ist, starten neue Pods wieder ohne Probleme.

Fehler „Container image authentication“

Wenn die Container-Laufzeit nicht über die erforderlichen Berechtigungen verfügt, um ein Image abzurufen, erhältst du möglicherweise eine Fehlermeldung ähnlich der folgenden:

„pull access denied, repository does not exist or may require authorization: authorization failed: no basic auth credentials“

Um diesen Fehler zu beheben, überprüfe Folgendes:

Überprüfe die IAM-Rolle, die dem EKS-Worker-Knoten zugeordnet ist. Wenn die IAM-Richtlinie AmazonEC2ContainerRegistryReadOnly fehlt, hänge diese Richtlinie an.
Wenn du Images aus einem ECR-Repository aus einem anderen Konto abrufst, siehe Wie erlaube ich einem sekundären Konto, Bilder in meine Amazon-ECR-Bild-Repositorys mithilfe von Push oder mithilfe von Pull zu übertragen? Stelle sicher, dass die Repository-Richtlinie mit den richtigen Berechtigungen konfiguriert ist.
Wenn du ECR-VPC-Endpunkte zum Abrufen von Images verwendest, stelle sicher, dass die Sicherheitsgruppe des VPC-Endpunkts eingehenden HTTPS-Datenverkehr auf Port 443 von der Sicherheitsgruppe des EKS-Knotens zulässt. Weitere Informationen findest du unter VPC-Endpunkte der Amazon ECR-Schnittstelle (AWS PrivateLink).
Bei containerd wird das Pause-Image nur während des Bootstrap-Vorgangs abgerufen. Das Image muss danach auf der Instance beibehalten werden. Verwende keine benutzerdefinierten Bereinigungsskripte oder manuellen Löschbefehle wie crictl rmi —prune, um die Pause-Images zu entfernen. Lasse kubelet die Garbage Collection (gc) durchführen, die automatisch alle 1–2 Minuten ausgeführt wird. Wenn du containerd-Pause-Container-Images entfernst, können neue Pods nicht gestartet werden. Aktuelle Pods laufen ohne Probleme auf den Knoten und die kubelet-Protokolle zeigen den Fehler „Failed to create pod sandbox“.

Fehler „Pod does not have label“ auf Windows-Knoten

Wenn ein Pod keinen geplanten nodeSelector auf einem Windows-Knoten hat, wird möglicherweise eine Fehlermeldung angezeigt, die der folgenden ähnelt:

„Failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address" or "Pod does not have label vpc.amazonaws.com/PrivateIPv4Address“

Um das Problem zu beheben, stelle sicher, dass die PodSpec die folgenden Bezeichnungen für den nodeSelector-Parameter enthält:

nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/arch: amd64

Vergewissere dich, dass du den Parameter enable-windows-ipam in der amazon-vpc-cni-ConfigMap auf wahr gesetzt hast.

Wenn du keine amazon-vpc-cni-ConfigMap hast, verwende die folgende Vorlage und lade sie in deinen Cluster hoch:

apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"

Starte die aws-node- und node-windows-Pods neu.

Weitere Informationen zur Bereitstellung von Windows-Knoten auf Amazon-EKS-Clustern findest du unter Bereitstellen von Windows-Knoten auf EKS-Clustern.

Sicherheitsgruppenfehler

Wenn du ein Sicherheitsgruppenproblem hast, erhältst du einen Fehler, der dem folgenden ähnelt:

„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.“

Diese Fehlermeldung kann auf ein Problem mit der health.kubernetes-Steuerebene hinweisen. Wende dich an den AWS Support, um dieses Problem zu beheben.