Durch die Nutzung von AWS re:Post stimmt du den AWS re:Post Nutzungsbedingungen

Warum steckt mein Amazon EKS-Pod im Status ContainerCreating fest mit dem Fehler "failed to create pod sandbox"?

Lesedauer: 6 Minute
0

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

Auflösung

Sie erhalten diesen Fehler, wenn ein Netzwerkproblem oder eine falsche Konfiguration der Systemressourcenlimits vorliegt.

Wenn Sie diesen Fehler erhalten und sich Ihre Pods im StatusContainerCreating befinden, überprüfen Sie zunächst den Status des Pods. Führen Sie dann den folgenden Befehl aus, um weitere Informationen zu erhalten. Ersetzen Sie podname durch den Namen Ihres Pods:

kubectl describe pod podname

In den folgenden Abschnitten finden Sie Schritte zur Problembehandlung je nach Ausgabe.

Fehlermeldung „Resource temporarily unavailable“

Wenn Sie ein Ressourcenproblem haben, erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

"kubelet, ip-##-##-##-##.##-#####-#.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"

Diese Fehlermeldung tritt auf, wenn die definierten Kerneleinstellungen für die maximale PID oder die maximale Anzahl von Dateien eine Betriebssystemeinschränkung verursachen.

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

Führen Sie die folgenden Aufgaben aus, um das Problem zu beheben:

  • Sammeln Sie die Knotenprotokolle.
  • Überprüfen Sie die Docker-Logs für die Fehlerantwort „dockerd[4597]: runtime/cgo: pthread_create failed: Fehlermeldung „Resource temporarily unavailable“.
  • Überprüfen Sie 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)“
  • Führen Sie den Befehl ps aus, um die Zombie-Prozesse zu identifizieren. Zombie-Prozesse sind alle Prozesse, die in der Ausgabe mit dem Z-Zustand aufgeführt sind.

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

Wenn Sie ein Netzwerkproblem haben, erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:

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

Diese Fehlerantwort bedeutet, dass das Container Network Interface (CNI) dem neu erstellten Pod keine IP-Adresse zuweisen kann.

Sie kann von einer Instance ausgelöst werden, die die maximal zulässigen elastischen Netzwerkschnittstellen und IP-Adressen verwendet. Außerdem können Sie diese Fehlermeldung erhalten, wenn die Amazon Virtual Private Cloud (Amazon VPC)-Subnetze eine IP-Adressen-Anzahl von Null haben.

Folgendes Beispiel zeigt Maximalgrenzen für die Anzahl an IP-Adressen für Netzwerkschnittstellen an:

Instance type    Maximum network interfaces    Private IPv4 addresses per interface    IPv6 addresses per interfacet3.medium        3                             6                                       6

In diesem Beispiel hat die t3.medium-Instance maximal drei Netzwerkschnittstellen und jede Netzwerkschnittstelle hat maximal sechs IP-Adressen. Die erste IP-Adresse wird für den Knoten verwendet und Sie können sie nicht zuweisen. Diese Netzwerkschnittstelle hat dann 17 IP-Adressen, die sie zuweisen kann.

Wenn die Netzwerkschnittstelle keine IP-Adressen mehr zur Verfügung hat, wird in den Protokollen des lokalen IP Address Management Daemon (ipamD) die folgende Meldung angezeigt:

„"ipamd/ipamd.go:1285","msg":"Total number of interfaces found: 3 ""AssignIPv4Address: IP address pool stats: total: 17, assigned 17" "AssignPodIPv4Address: ENI eni-abc123 does not have available addresses“

Sehen Sie sich beispielsweise die folgende Ausgabe an:

Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-##-##-##-##.##-#####-#.compute.internal (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "provisioning-XXXXXXXXXXXXXXX": networkPlugin cni failed to set up pod "provisioning-XXXXXXXXXXXXXXX" network: add cmd: failed to assign an IP address to container

Überprüfen Sie das Subnetz, um festzustellen, ob es nicht mehr über freie IP-Adressen verfügt. Sie können die verfügbaren IP-Adressen für jedes Subnetz in der Amazon-VPC-Konsole im Abschnitt Subnetze einsehen.

Subnet: ##########IPv4 CIDR Block 10.2.1.0/24   Number of allocated ips 254  ; Free address count 0

Verwenden Sie folgende Lösungen, um dieses Problem zu beheben:

Fehlermeldung „Error while dialing“

Wenn Sie ein Dial-Problem haben, erhalten Sie einen Fehler, der dem folgenden ähnelt:

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

Dieser Fehler zeigt an, dass der aws-node-Pod nicht mit IPAM kommunizieren konnte, weil der aws-node-Pod auf dem Knoten nicht ausgeführt werden konnte.

Um dieses Problem zu beheben, stellen Sie sicher, dass Sie die richtige Version des VPC-CNI-Plugins für die Cluster-Version ausführen.

Die Pods könnten sich im Status Ausstehend befinden aufgrund von Fehlern bei den Liveness- und Readiness-Probes. Stellen Sie sicher, dass Sie die neueste Add-ons-Version der VPC-CNI nutzen.

Das Problem kann auch auftreten, weil der Mountingpunkt Dockershim (bis EKS-Version 1.23) nicht gemountet werden kann. Die folgende Beispielmeldung weist darauf hin, dass der Pod var/run/dockershim.sock nicht gemountet wurde:

Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\Not able to get local pod sandboxes yet (attempt 1/5): rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or director

Gehen Sie wie folgt vor, um dieses Problem zu beheben:

  • Starten Sie den aws-node-Pod neu, um den Mountingpunkt neu zuzuordnen.
  • Markieren Sie den Knoten als unplanbar (cordon), und skalieren Sie die Knoten in der Knotengruppe.
  • Aktualisieren Sie die Amazon-VPC-Netzwerkschnittstelle auf die neueste unterstützte Cluster-Version.

Wenn Sie das CNI als verwaltetes Plugin in der AWS-Managementkonsole hinzugefügt haben, schlägt der aws-node die Probes fehl. Verwaltete Plugins überschreiben das Dienstkonto. Das Servicekonto ist jedoch nicht mit der ausgewählten Rolle konfiguriert. Um dieses Problem zu beheben, schalten Sie das Plugin in der AWS-Managementkonsole aus und erstellen Sie dann das Servicekonto mit einer Manifestdatei. Oder bearbeiten Sie das aktuelle aws-node-Servicekonto, um die Rolle hinzuzufügen, die für das verwaltete Add-on verwendet wird.

Fehlermeldung „Pod does not have label“

Wenn Sie ein Label-Problem haben, erhalten Sie einen Fehler, der dem folgenden ähnelt:

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

Dieses Problem tritt auf, wenn ein Pod keinen geplanten nodeSelector auf einem Windows-Knoten hat.

Um das Problem zu beheben, stellen Sie sicher, dass die PodSpec für den nodeSelector die folgenden Labels enthält:

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

Sicherheitsgruppenfehler

Wenn Sie ein Sicherheitsgruppenproblem haben, erhalten Sie 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. Wenden Sie sich an den AWS Support, um dieses Problem zu beheben.

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 5 Monaten