AWS re:Post Knowledge Center Feedback Survey

Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.

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

Lesedauer: 8 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-Protkollsammler-Skript, um die Worker-Knotenprotokolle zu sammeln. Weitere Informationen findest du unter EKS Logs Collector (Linux) (EKS-Protkollsammler (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 Präfix-Delegierungs-Modus. 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 „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.