Warum hängt mein Amazon-EKS-Pod im Status ContainerCreating mit dem Fehler „Pod-Sandbox konnte nicht erstellt werden“ fest?

Auflösung

Ihre Amazon-EKS-Pods hängen möglicherweise aus mehreren Gründen im Status ContainerCreating mit einem Netzwerkverbindungssfehler fest. Führen Sie je nach Fehlermeldung die folgenden Schritte zur Fehlerbehebung aus.

Fehlerantwort vom Daemon: Shim konnte nicht gestartet werden: fork/exec /usr/bin/containerd-shim: Ressource vorübergehend nicht verfügbar: unbekannt

Dieser Fehler tritt aufgrund einer Betriebssystembeschränkung auf, die durch die definierten Kerneleinstellungen für maximale PID oder maximale Anzahl von Dateien verursacht wird.

Führen Sie den folgenden Befehl aus, um Informationen über Ihren Pod abzurufen:

$ kubectl describe pod example_pod

Beispielausgabe:

kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.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

Um das Problem vorübergehend zu beheben, starten Sie den Knoten neu.

Gehen Sie wie folgt vor, um das Problem zu beheben.

• Sammeln Sie die Knoten-Protokolle.
• Überprüfen Sie die Docker-Protokolle auf den Fehler „dockerd [4597]: runtime/cgo: pthread_create fehlgeschlagen: Ressource vorübergehend nicht verfügbar“.
• Überprüfen Sie das Kubelet-Protokoll auf die folgenden Fehler:
  • „kubelet [5267]: Laufzeit: konnte keinen neuen Betriebssystem-Thread erstellen (ich habe schon 2; errno=11)“
  • „kubelet [5267]: Laufzeit: Möglicherweise muss die maximale Anzahl von Benutzerprozessen erhöht werden (ulimit -u)“.
• Identifizieren Sie die Zombie-Prozesse, indem Sie den Befehl ps ausführen. Alle Prozesse, die in der Ausgabe mit dem Zustand Z aufgeführt sind, sind die Zombie-Prozesse.

Netzwerk-Plug-In cni konnte kein Pod-Netzwerk einrichten: cmd hinzufügen: dem Container konnte keine IP-Adresse zugewiesen werden

Dieser Fehler weist darauf hin, dass das Container Network Interface (CNI) keine IP-Adresse für den neu bereitgestellten Pod zuweisen kann.

Im Folgenden sind die Gründe aufgeführt, warum das CNI dem neu erstellten Pod keine IP-Adresse zur Verfügung stellt:

• Die Instanz verwendete die maximal zulässigen Elastic Network-Schnittstellen und IP-Adressen.
• Die Amazon-Virtual-Private-Cloud-Subnetze (Amazon VPC) haben eine Anzahl von IP-Adressen von Null.

Im Folgenden finden Sie ein Beispiel für die Erschöpfung der IP-Adresse der Netzwerkschnittstelle:

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

In diesem Beispiel hat die Instance t3.medium maximal 3 Netzwerkschnittstellen und jede Netzwerkschnittstelle hat maximal 6 IP-Adressen. Die erste IP-Adresse wird für den Knoten benutzt und ist nicht zuweisbar. Damit bleiben 17 IP-Adressen übrig, die die Netzwerkschnittstelle zuweisen kann.

Die Protokolle des Local IP Address Management Daemon (iPAMD) zeigen die folgende Meldung an, wenn die Netzwerkschnittstelle keine IP-Adressen mehr hat:

"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"

Führen Sie den folgenden Befehl aus, um Informationen über Ihren Pod abzurufen:

$ kubectl describe pod example_pod

Beispielausgabe:

Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.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 dem Subnetz die freien IP-Adressen ausgegangen sind. Sie können verfügbare IP-Adressen für jedes Subnetz in der Amazon-VPC-Konsole im Abschnitt Subnetze anzeigen.

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

Um dieses Problem zu beheben, reduzieren Sie einen Teil der Workload, um verfügbare IP-Adressen freizugeben. Wenn zusätzliche Subnetzkapazität verfügbar ist, können Sie den Knoten skalieren. Sie können auch ein zusätzliches Subnetz erstellen. Weitere Informationen finden Sie unter Wie verwende ich mehrere CIDR-Bereiche mit Amazon EKS? Befolgen Sie die Anweisungen im Abschnitt Subnetze mit einem neuen CIDR-Bereich erstellen.

Fehler beim Wählen des Wählvorwahls tcp 127.0.0.1:50051: Verbinden: Verbindung verweigert

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

Führen Sie die folgenden Befehle aus, um Informationen über den Pod abzurufen:

$ kubectl describe pod example_pod

$ kubectl describe pod/aws-node-XXXXX -n kube-system

Beispiel-Ausgaben:

Warning  FailedCreatePodSandBox  51s  kubelet, ip-xx-xx-xx-xx.ec2.internal  Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to set up pod "example_pod" network: add cmd: Error received from AddNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused", failed to clean up sandbox container

"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to teardown pod "example_pod" network: del cmd: error received from DelNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"]

Um dieses Problem zu beheben, stellen Sie sicher, dass der aws-node-Pod bereitgestellt ist und sich im Status Wird ausgeführt befindet:

kubectl get pods --selector=k8s-app=aws-node -n kube-system

Hinweis: Stellen Sie sicher, dass Sie die richtige Version des VPC-CNI-Plugins für die Clusterversion ausführen.

Die Pods befinden sich möglicherweise aufgrund von Liveness- und Readiness-Prüffehlern im Status Ausstehend. Stellen Sie sicher, dass Sie über die neueste empfohlene CNI-Add-On-Version von VPC gemäß der Kompatibilitätstabelle verfügen.

Führen Sie den folgenden Befehl aus, um die letzte Protokollmeldung vom aws-node-Pod anzuzeigen:

kubectl -n kube-system exec -it aws-node-XXX-- tail -f /host/var/log/aws-routed-eni/ipamd.log | tee ipamd.log

Das Problem kann auch auftreten, weil der Dockershim-Einhängepunkt nicht gemountet werden kann. Im Folgenden finden Sie eine Beispielmeldung, die Sie erhalten können, wenn dieses Problem auftritt:

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

Die vorherige Meldung weist darauf hin, dass der Pod var/run/dockershim.sock die Bindungsbereitstellung nicht gemountet hat.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

• Starten Sie den AWS-Node-Pod neu, um den Mount-Punkt neu zuzuordnen.
• Kordnen Sie den Knoten ab und skalieren Sie die Knoten in der Knotengruppe.
• Führen Sie ein Upgrade der Amazon-VPC-Netzwerkschnittstelle auf die neueste unterstützte Clusterversion durch.

Wenn Sie das CNI als verwaltetes Add-On in der AWS-Managementkonsole hinzugefügt haben, schlägt der AWS-Knoten die Prüfungen 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 über die AWS-Managementkonsole aus und erstellen Sie das Servicekonto mithilfe einer Manifestdatei. Oder bearbeiten Sie das aktuelle **AWS-Knoten-**Servicekonto, um die Rolle hinzuzufügen, die im verwalteten Plugin verwendet wird.

Netzwerk-Plug-In-cni konnte das Pod-Netzwerk „my-app-xxbz-zz“ nicht einrichten: Kubernetes-Argvalle konnten nicht analysiert werden: Pod hat keine Markierung vpc.amazonaws.com/PrivateIPv4Address

Sie erhalten diesen Fehler möglicherweise aus einem folgenden Gründen:

• Der Pod läuft nicht richtig.
• Das Zertifikat, das der Pod verwendet, wurde nicht erfolgreich erstellt.

Dieser Fehler bezieht sich auf den Webhook der Amazon-VPC-Zugangssteuerung, der auf Amazon-EKS-Clustern zum Ausführen von Windows-Workloads erforderlich ist. Der Webhookl ist ein Plug-In, das einen Pod im Namensraum des Kube-Systems ausführt. Die Komponente läuft auf Linux Knoten und ermöglicht Netzwerke für eingehende Pods auf Windows-Knoten.

Führen Sie den folgenden Befehl aus, um die Liste der betroffenen Pods abzurufen:

kubectl get pods

Beispielausgabe:

my-app-xxx-zz        0/1     ContainerCreating   0          58m   <none>            ip-XXXXXXX.compute.internal   <none>
my-app-xxbz-zz       0/1     ContainerCreating   0          58m   <none>

Führen Sie den folgenden Befehl aus, um Informationen über den Pod abzurufen:

$ kubectl describe pod my-app-xxbz-zz

Beispielausgabe:

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "<POD_ANME>": networkPlugin cni failed to set up pod "example_pod" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address

Reconciler worker 1 starting processing node ip-XXXXXXX.compute.internal.
Reconciler checking resource vpc.amazonaws.com/PrivateIPv4Address warmpool size 1 desired 3 on node ip-XXXXXXX.compute.internal.
Reconciler creating resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal.
Reconciler failed to create resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal: node has no open IP address slots.

Windows-Knoten unterstützen eine Netzwerkschnittstelle pro Knoten. Jeder Windows-Knoten kann so viele Pods ausführen, wie pro Netzwerkschnittstelle verfügbar sind, minus eins. Um dieses Problem zu beheben, skalieren Sie die Anzahl der Windows-Knoten.

Wenn die IP-Adressen nicht das Problem sind, überprüfen Sie das Ereignis und die Protokolle des Amazon-VPC-Zugangscontroller-Pods.

Führen Sie den folgenden Befehl aus, um zu bestätigen, dass der Amazon-VPC-Zugangssteuerungs-Pod erstellt wurde:

$ kubectl get pods -n kube-system  OR kubectl get pods -n kube-system | grep "vpc-admission"

Beispielausgabe:

vpc-admission-webhook-5bfd555984-fkj8z     1/1     Running   0          25m

Führen Sie den folgenden Befehl aus, um Informationen über den Pod abzurufen:

$ kubectl describe pod vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Beispielausgabe:

  Normal  Scheduled  27m   default-scheduler  Successfully assigned kube-system/vpc-admission-webhook-5bfd555984-fkj8z to ip-xx-xx-xx-xx.ec2.internal
  Normal  Pulling    27m   kubelet            Pulling image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7"
  Normal  Pulled     27m   kubelet            Successfully pulled image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7" in 1.299938222s
  Normal  Created    27m   kubelet            Created container vpc-admission-webhook
  Normal  Started    27m   kubelet            Started container vpc-admission-webhook

Führen Sie den folgenden Befehl aus, um die Pod-Protokolle auf Konfigurationsprobleme zu überprüfen:

$ kubectl logs vpc-admission-webhook-5bfd555984-fkj8z -n kube-system

Beispielausgabe:

I1109 07:32:59.352298       1 main.go:72] Initializing vpc-admission-webhook version v0.2.7.
I1109 07:32:59.352866       1 webhook.go:145] Setting up webhook with OSLabelSelectorOverride: windows.
I1109 07:32:59.352908       1 main.go:105] Webhook Server started.
I1109 07:32:59.352933       1 main.go:96] Listening on :61800 for metrics and healthz
I1109 07:39:25.778144       1 webhook.go:289] Skip mutation for  as the target platform is .

Die vorherige Ausgabe zeigt, dass der Container erfolgreich gestartet wurde. Der Pod fügt dann das Label vpc.amazonaws.com/privateIPv4Address zum Anwendungs-Pod hinzu. Das Manifest für den Anwendungs-Pod muss jedoch einen Knotenselektor oder eine Affinität enthalten, damit der Pod auf den Windows-Knoten geplant wird.

Weitere Optionen zur Behebung des Problems umfassen die Überprüfung der folgenden Punkte:

• Sie haben den Amazon-VPC-Zugangscontroller-Pod im Namespace des kube-Systems bereitgestellt.
• Protokolle oder Ereignisse deuten nicht auf ein abgelaufenes Zertifikat hin. Wenn das Zertifikat abgelaufen ist und Windows-Pods im Status Container-Erstellung hängen bleiben, müssen Sie die Pods löschen und erneut bereitstellen.
• Es gibt keine Timeouts oder DNS-bezogene Probleme.

Wenn Sie den Amazon-VPC-Zugangscontroller nicht erstellen, aktivieren Sie die Windows-Unterstützung für Ihren Cluster.

Wichtig: Für Amazon EKS müssen Sie den Amazon-VPC-Zugangscontroller nicht aktivieren, um Windows-Knotengruppen zu unterstützen. Wenn Sie den Amazon-VPC-Zugangscontroller aktiviert haben, entfernen Sie die Legacy-Windows-Unterstützung aus Ihrer Datenebene.

---

Relevante Informationen

Amazon-EKS-Netzwerk