Wie löse ich Verbindungs-Timeouts, wenn ich mich mit meinem Service verbinde, der in Amazon EKS gehostet wird?

Lesedauer: 4 Minute
0

Ich erhalte Verbindungs-Timeouts, wenn ich mich mit meinem Service verbinde, der in meinem Amazon Elastic Kubernetes Service (Amazon EKS)-Cluster gehostet wird.

Kurzbeschreibung

Zwei der häufigsten Gründe, warum Sie sich in Ihrem Amazon-EKS-Cluster nicht mit Ihrem Service verbinden können, sind:

  • Die Beschränkungen der Sicherheitsgruppe oder der Netzwerkzugriffssteuerungsliste (Netzwerk-ACL) verhindern, dass der Datenverkehr die Pod-Endpunkte erreicht.
  • Der Service wählt die Pod-Endpunkte nicht aus, da die Beschriftungen nicht übereinstimmen.

Um diese Probleme zu beheben, überprüfen Sie die Sicherheitsgruppen und Netzwerk-ACLs, die mit Ihren Worker-Knoten-Instances und der Lastenverteilung verknüpft sind. Stellen Sie außerdem sicher, dass Ihr Service die richtigen Bezeichnungen für Ihre Pods ausgewählt hat.

Hinweis: Die Fehlerbehebung ist für verschiedene Service-Typen unterschiedlich. Die folgenden Lösungen gelten für den Fall, dass Sie Fehler bei unzugänglichen Services beheben. Weitere Informationen zu Kubernetes-Service-Typen finden Sie unter Wie stelle ich die Kubernetes-Services bereit, die auf meinem Amazon-EKS-Cluster ausgeführt werden?

Auflösung

Prüfen Sie Ihre Sicherheitsgruppe und Netzwerk-ACLs

Cluster-IP

Der Cluster-IP-Service-Typ wird für die Kommunikation zwischen Microservices verwendet, die im selben Amazon-EKS-Cluster ausgeführt werden. Stellen Sie sicher, dass die Sicherheitsgruppe, die an die Instance angehängt ist, in der sich der Ziel-Pod befindet, über eine eingehende Regel verfügt, die die Kommunikation von der Client-Pod-Instance ermöglicht.

In den meisten Fällen gibt es eine Selbstregel, die die gesamte Kommunikation über alle Ports in den Sicherheitsgruppen des Worker-Knotens ermöglicht. Wenn Sie mehrere Knotengruppen verwenden, jede mit ihrer eigenen Sicherheitsgruppe, stellen Sie sicher, dass Sie die gesamte Kommunikation zwischen den Sicherheitsgruppen zulassen. Auf diese Weise können die Microservices, die über die mehreren Knoten laufen, problemlos kommunizieren.

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

Knoten-Port

Die Sicherheitsgruppe des Worker-Knotens sollte eingehenden Datenverkehr auf dem Port zulassen,der in der Definition des NodePort-Services angegeben wurde. Wenn er nicht in der Service-Definition angegeben ist, stimmt der Wert des Port-Parameters mit dem TargetPort-Parameter überein. Der Port ist auf allen Knoten im Amazon-EKS-Cluster verfügbar.

Überprüfen Sie die Netzwerk-ACLs, die mit den Worker-Knoten-Subnetzen verknüpft sind. Stellen Sie sicher, dass Ihre Client-IP-Adresse über den vom Service verwendeten Port in der Zulassungsliste steht.

Wenn Sie über das Internet auf den Kubernetes-Service zugreifen, stellen Sie sicher, dass Ihre Knoten über eine öffentliche IP-Adresse verfügen. Um auf den Service zuzugreifen, müssen Sie die Kombination aus öffentlicher IP-Adresse und Port des Knotens verwenden.

Lastenverteilung

Stellen Sie sicher, dass die Sicherheitsgruppe der Lastenverteilung die Listener-Ports zulässt. Stellen Sie außerdem sicher, dass die Sicherheitsgruppe des Worker-Knotens eingehenden Datenverkehr von der Lastenverteilung-Sicherheitsgruppe über den Port zulässt, auf dem der Anwendungscontainer ausgeführt wird.

Wenn sich der in der Service-Definition angegebene Port vom TargetPort unterscheidet, müssen Sie den eingehenden Datenverkehr über den Port in der Sicherheitsgruppe des Worker-Knotens für die Sicherheitsgruppe der Lastenverteilung zulassen. Der Port und TargetPort sind in der Regel in der Service-Definition identisch.

Die Netzwerk-ACLs müssen es Ihrer Client-IP-Adresse ermöglichen, die Lastenverteilung am Listener-Port zu erreichen. Wenn Sie über das Internet auf der Lastenverteilung zugreifen, stellen Sie sicher, dass Sie eine öffentliche Lastenverteilung erstellt haben.

Prüfen Sie, ob Ihr Service die Pod-Endpunkte richtig ausgewählt hat

Wenn Ihre Pods nicht als Backends für den Service registriert sind, können Sie einen Timeout-Fehler erhalten. Dies kann passieren, wenn Sie über einen Browser auf den Service zugreifen oder wenn Sie den Befehl curl podip:PodPort ausführen.

Überprüfen Sie die Beschriftungen für die Pods und stellen Sie sicher, dass der Service über die entsprechenden Markierungs-Selektoren (von der Kubernetes-Website) verfügt.

Führen Sie die folgenden Befehle aus, um zu überprüfen, ob Ihr Kubernetes-Service Ihre Pods richtig ausgewählt und registriert hat.

Befehl:

kubectl get pods -o wide

Beispielausgabe:

NAME                    READY   STATUS    RESTARTS   AGE       IP                           NODE                         NOMINATED NODE   READINESS GATES
nginx-6799fc88d8-2rtn8   1/1     Running     0       3h4m   172.31.33.214   ip-172-31-33-109.us-west-2.compute.internal       none          none

Befehl:

kubectl describe svc your_service_name -n your_namespace

Hinweis: Ersetzen Sie Ihren your_service_name durch Ihren Servicenamen und your_namespace durch Ihren Namespace.

Beispielausgabe:

Events:            none
Session Affinity:  none
Endpoints:         172.31.33.214:80
....

In der vorherigen Beispielausgabe ist 172.31.33.214 die Pod-IP-Adresse, die beim Ausführen des Befehls kubectl get pods -o wide erhalten wurde. Die 172.31.33.214 IP-Adresse dient auch als Backend für einen Service, der in einem Amazon-EKS-Cluster ausgeführt wird.


AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren