Warum verbinden sich meine Pods nicht mit anderen Pods in Amazon EKS?

Kurzbeschreibung

**Hinweis:**Wenn Sie beim Ausführen von Befehlen der AWS Command Line Interface (AWS CLI) Fehler erhalten, stellen Sie sicher, dass Sie die neueste AWS CLI-Version verwenden.

Wenn Ihre Pods keine Verbindung zu anderen Pods herstellen können, erhalten Sie je nach Anwendung möglicherweise die folgenden Fehler.

Wenn die Sicherheitsgruppe eines Worker-Knotens die Kommunikation zwischen den Knoten nicht zulässt, erhalten Sie die folgende Fehlermeldung:

curl: (7) Failed to connect to XXX.XXX.XX.XXX port XX: Connection timed out

Wenn der DNS nicht funktioniert, erhalten Sie die folgende Fehlermeldung:

curl nginx  
curl: (6) Could not resolve host: nginx

Wenn das DNS funktioniert, aber ein Pod-Verbindungsproblem vorliegt, erhalten Sie die folgende Fehlermeldung:

Error: RequestError: send request failed caused by: Post  dial tcp 1.2.3.4.5:443: i/o timeout

Wenn Sie versuchen, das DNS für den Pod aufzulösen, der nicht über einen Dienst verfügbar ist, erhalten Sie die folgende Fehlermeldung:

kubectl exec -it busybox -- nslookup nginx
Server:   10.100.0.10
Address:  10.100.0.10:53
** server can't find nginx.default.svc.cluster.local: NXDOMAIN
*** Can't find nginx.svc.cluster.local: No answer
*** Can't find nginx.cluster.local: No answer
*** Can't find nginx.ap-southeast-2.compute.internal: No answer
*** Can't find nginx.default.svc.cluster.local: No answer
*** Can't find nginx.svc.cluster.local: No answer
*** Can't find nginx.cluster.local: No answer
*** Can't find nginx.ap-southeast-2.compute.internal: No answer

Um diese Fehler zu beheben, überprüfen Sie, ob Ihre Umgebung korrekt eingerichtet ist:

• Ihre Sicherheitsgruppen erfüllen die Amazon-EKS-Richtlinien.
• Die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) verweigert die Verbindung nicht.
• Ihr Subnetz verfügt über eine lokale Route für die Kommunikation innerhalb Ihrer Amazon Virtual Private Cloud (Amazon VPC).
• Im Subnetz sind genügend IP-Adressen verfügbar.
• Ihre Sicherheitsgruppen für Pods ermöglichen es Pods, miteinander zu kommunizieren.
• Auf Ihren Worker-Knoten ist die IP-Weiterleitung aktiviert.
• Sie erfüllen die Netzwerkanforderungen für Kubernetes (mit Ausnahme beabsichtigter NetworkPolicy).
• Ihre Pods verwenden DNS korrekt, um miteinander zu kommunizieren.
• Ihre Pods sind geplant und befinden sich im Status RUNNING.
• Sie haben die empfohlene Version des Amazon VPC Container Network Interface (CNI)-Plug-ins für Kubernetes.

Behebung

Ihre Sicherheitsgruppen erfüllen die Amazon-EKS-Richtlinien.

Um den Datenverkehr einzuschränken, den Sie auf der Sicherheitsgruppe Ihres Worker-Knotens zulassen, erstellen Sie Regeln für eingehenden Datenverkehr. Erstellen Sie diese Regeln für jedes Protokoll oder alle Ports, die Ihre Worker-Knoten für die Kommunikation zwischen den Knoten verwenden.

Es hat sich bewährt, den gesamten Datenverkehr für die Sicherheitsgruppe Ihres Worker-Knotens zuzulassen. Sie müssen die Sicherheitsgruppenregeln nicht jedes Mal ändern, wenn ein neuer Pod mit einem neuen Port erstellt wird.

Weitere Informationen finden Sie unter Anforderungen und Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

Die Netzwerk-ACL weist die Verbindung nicht zurück.

1.    Vergewissern Sie sich, dass der Datenverkehr zwischen Ihrem Amazon-EKS-Cluster und VPC CIDR über Ihre Netzwerk-ACL ungehindert fließt.

2.    (Optional) Um Ihrer VPC eine zusätzliche Sicherheitsebene hinzuzufügen, sollten Sie Netzwerk-ACLs mit Regeln einrichten, die Ihren Sicherheitsgruppen ähneln.

Ihr Subnetz hat eine lokale Route für die Kommunikation innerhalb Ihrer VPC.

Vergewissern Sie sich, dass Ihre Subnetze über die Standardroute für die Kommunikation innerhalb der VPC verfügen.

Im Subnetz sind genügend IP-Adressen verfügbar.

Stellen Sie sicher, dass Ihre angegebenen Subnetze über genügend verfügbare IP-Adressen für die kontoübergreifenden elastischen Netzwerkschnittstellen und Ihre Pods verfügen.

Weitere Informationen finden Sie unter Amazon EKS: VPC- und Subnetz-Anforderungen und -Überlegungen.

Führen Sie den folgenden AWS-CLI-Befehl aus, um nach verfügbaren IP-Adressen zu suchen:

$ aws ec2 describe-subnets --subnet-id YOUR-SUBNET-ID --query 'Subnets[0].AvailableIpAddressCount'

Ihre Sicherheitsgruppen für Pods ermöglichen es Pods, miteinander zu kommunizieren.

Wenn Sie Sicherheitsgruppen für Pods oder benutzerdefinierte CNI-Netzwerke verwenden, können Sie Pods beliebige Sicherheitsgruppen zuweisen. Stellen Sie in diesem Szenario sicher, dass die Sicherheitsgruppen die Kommunikation zwischen den Pods korrekt zulassen.

Auf Ihren Worker-Knoten ist die IP-Weiterleitung aktiviert.

Wenn Sie ein benutzerdefiniertes AMI verwenden, müssen Sie sicherstellen, dass die Kernelvariable „net.ipv4.ip_forward“ aktiviert ist. Führen Sie einen der folgenden Befehle aus, um diese Einstellung auf einem Worker-Knoten zu überprüfen:

# sysctl net.ipv4.ip_forward

# cat /proc/sys/net/ipv4/ip_forward

Wenn die Ausgabe 0 ist, verwenden Sie einen der folgenden Befehle, um die Kernelvariable „net.ipv4.ip_forward“ zu aktivieren.

# sysctl -w net.ipv4.ip_forward=1

# echo 1 > /proc/sys/net/ipv4/ip_forward

Informationen zur Aktivierung der Einstellung finden Sie in den Zeilen 184-188 des Skripts install-worker.sh (auf GitHub) für Amazon-EKS-AMIs in containerd-Laufzeit. Da containerd die Standardlaufzeit in Amazon-EKS-Versionen ab 1.24 ist, ist dieser Schritt zur Fehlerbehebung bei der Pod-zu-Pod-Netzwerkkonnektivität erforderlich.

Sie erfüllen die Netzwerkanforderungen für Kubernetes (mit Ausnahme beabsichtigter NetworkPolicy)

Vergewissern Sie sich, dass Sie die Kubernetes-Netzwerkanforderungen erfüllen (auf der Kubernetes-Website).

Standardmäßig sind Pods nicht isoliert. Pods akzeptieren Datenverkehr von jeder Quelle. Pods werden isoliert, indem sie über eine NetworkPolicy ausgewählt werden.

Hinweis: Informationen zu NetworkPolicy-Konfigurationen finden Sie unter Installieren des Add-Ons für die Calico-Netzwerkrichtlinien-Engine.

Ihre Pods verwenden DNS korrekt, um miteinander zu kommunizieren.

Sie müssen Ihre Pods zuerst über einen Dienst verfügbar machen. Wenn Sie dies nicht tun, können Ihre Pods keine DNS-Namen erhalten und sind nur über ihre spezifischen IP-Adressen erreichbar.

Die folgende Beispielausgabe zeigt einen Versuch, den DNS-Namen für den nginx-Dienst aufzulösen. In diesem Fall wird die ClusterIP 10.100.94.70 zurückgegeben:

$ kubectl run nginx --image=nginx --replicas=5 -n web
deployment.apps/nginx created

$ kubectl expose deployment nginx --port=80 -n web
service/nginx exposed

$ kubectl get svc -n web
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   10.100.94.70   <none>        80/TCP    2s

# kubectl exec -ti busybox -n web -- nslookup nginx
Server:    10.100.0.10
Address 1: 10.100.0.10 ip-10-100-0-10.ap-southeast-2.compute.internal
Name:      nginx
Address 1: 10.100.94.70 ip-10-100-94-70.ap-southeast-2.compute.internal

Wenn Ihre Pods das DNS immer noch nicht auflösen können, finden Sie weitere Informationen unter How do I troubleshoot DNS failures with Amazon EKS (Wie behebe ich DNS-Fehler mit Amazon EKS?).

Hinweis: Weitere Informationen finden Sie unter Pods, Service (Dienst) und Headless Services (monitorlose Dienste) auf der Kubernetes-Website.

Ihre Pods sind geplant und befinden sich im Status RUNNING.

Vergewissern Sie sich, dass Ihre Pods geplant sind und sich im Status RUNNING befinden.

Informationen zur Behebung Ihres Pod-Status finden Sie unter How can I troubleshoot the pod status in Amazon EKS? (Wie kann ich den Pod-Status in Amazon EKS beheben?).

Sie haben die empfohlene Version des Amazon-VPC-CNI-Plug-ins für Kubernetes.

Wenn Sie nicht über die empfohlene Version des Amazon-VPC-CNI-Plug-ins für Kubernetes verfügen, führen Sie ein Upgrade auf die aktuelle Version durch.

Wenn Sie die empfohlene Version haben, aber Probleme damit haben, finden Sie weitere Informationen unter How do I resolve kubelet or CNI plugin issues for Amazon EKS (Wie löse ich Probleme mit Kubelet- oder CNI-Plug-ins für Amazon EKS?).