Wie behebe ich den Fehler HTTP 503 (Service nicht verfügbar), wenn ich in einem Amazon-EKS-Cluster auf einen Kubernetes-Service zugreife?
Ich erhalte der Fehler HTTP 503 (Service nicht verfügbar), wenn ich eine Verbindung zu einem Kubernetes Service herstelle, der in meinem Amazon Elastic Kubernetes Service (Amazon EKS)-Cluster ausgeführt wird.
Kurzbeschreibung
HTTP 503-Fehler sind serverseitige Fehler. Sie treten auf, wenn Sie eine Verbindung zu einem Kubernetes-Service-Pod herstellen, der sich in einem Amazon-EKS-Cluster befindet, der für eine Lastenverteilung konfiguriert ist.
Informationen zur Behebung von HTTP-504-Fehlern finden Sie unter Wie behebe ich HTTP-504-Fehler in Amazon EKS?
Führen Sie die folgenden Schritte zur Fehlerbehebung aus, um HTTP-503-Fehler zu beheben.
Auflösung
Prüfen Sie, ob die Pod-Markierung mit dem Wert übereinstimmt, der in der Kubernetes-Service-Auswahl angegeben ist
1. Führen Sie den folgenden Befehl aus, um den Wert des Selektors abzurufen:
$ kubectl describe service service_name -n your_namespace
Hinweis: Ersetzen Sie service_name durch Ihren Servicenamen und your_namespace durch Ihren Service-Namespace.
Beispielausgabe:
Name: service-name Namespace: pod-name Labels: none Annotations: none Selector: app.kubernetes.io/name=namespace Type: NodePort IP Families: none IP: 10.100.17.189 IPs: 10.100.17.189 Port: unset 80/TCP TargetPort: 80/TCP NodePort: unset 31560/TCP Endpoints: none Session Affinity: none External Traffic Policy: Cluster Events: none
In der vorhergehenden Ausgabe ist der Beispiel-Selektorwert app.kubernetes.io/name=namespace.
2. Prüfen Sie, ob Pods mit der Markierung app.kubernetes.io/name=namespace vorhanden sind:
$ kubectl get pods -n your_namespace -l "app.kubernetes.io/name=namespace"
Beispielausgabe:
No resources found in your_namespace namespace.
Wenn mit dem von Ihnen gesuchten Wert keine Ressourcen gefunden werden, erhalten Sie einen HTTP-503-Fehler.
Stellen Sie sicher, dass die für den Kubernetes-Service definierten Pods ausgeführt werden
Verwenden Sie die Markierung im Kubernetes-Service-Selektor, um zu überprüfen, ob die Pods vorhanden sind und sich im Status Wird ausgeführt befinden:
$ kubectl -n your_namespace get pods -l "app.kubernetes.io/name=your_namespace"
Ausgabe:
NAME READY STATUS RESTARTS AGE POD_NAME 0/1 ImagePullBackOff 0 3m54s
Prüfen Sie, ob die Pods die Bereitschaftsprüfung für Ihre Kubernetes-Bereitstellung bestehen können
1. Stellen Sie sicher, dass die Anwendung-Pods die Bereitschaftsprüfung bestehen können Weitere Informationen finden Sie unter Konfigurieren von Live-, Bereitschafts- und Startupprüfungen (auf der Kubernetes-Website).
2. Prüfen Sie die Bereitschaftssonde für den Pod:
$ kubectl describe pod pod_name -n your_namespace | grep -i readiness
Hinweis: Ersetzen Sie pod_name durch Ihren Pod-Namen und your_namespace durch Ihren Namespace.
Beispielausgabe:
Readiness: tcp-socket :8080 delay=5s timeout=1s period=2s #success=1 #failure=3 Warning Unhealthy 2m13s (x298 over 12m) kubelet Readiness probe failed:
In der vorhergehenden Ausgabe sehen Sie, dass die Bereitschaftsprüfung fehlgeschlagen ist.
Hinweis: Dieser Schritt liefert nur dann eine hilfreiche Ausgabe, wenn die Anwendung auf dem richtigen Pfad und Port wartet. Überprüfen Sie die curl-Ausgabe mit dem Befehl curl -Ivik und stellen Sie sicher, dass der auf dem Service-Level definierte Pfad eine gültige Antwort erhält. Zum Beispiel sind 200 ms eine gute Antwort.
Prüfen Sie die Kapazität für Ihren Classic Load Balancer
Wenn Sie einen intermittierenden HTTP-503-Fehler erhalten, verfügt Ihr Classic Load Balancer nicht über genügend Kapazität, um die Anfrage zu bearbeiten. Um dieses Problem zu beheben, stellen Sie sicher, dass Ihr Classic Load Balancer über genügend Kapazität verfügt und Ihre Worker-Knoten die Anforderungsrate verarbeiten können.
Stellen Sie sicher, dass Ihre Instances registriert sind
Sie erhalten auch einen HTTP-503-Fehler, wenn keine registrierten Instances vorhanden sind. Um dieses Problem zu beheben, versuchen Sie die folgenden Lösungen:
- Stellen Sie sicher, dass die Sicherheitsgruppen für den Worker-Knoten über eine eingehende Regel verfügen, die den Port-Zugriff auf den Knotenport zu Worker-Knoten ermöglicht Stellen Sie außerdem sicher, dass keine NAT-Regeln den Netzwerkverkehr auf den Knoten-Portbereichen blockieren.
- Stellen Sie sicher, dass die benutzerdefinierte Sicherheitsgruppe, die für den Classic Load Balancer angegeben ist, eingehenden Zugriff auf die Worker-Knoten hat.
- Stellen Sie sicher, dass in jeder Availability Zone, die von den Subnetzen angegeben wird, Worker-Knoten vorhanden sind.
Relevante Informationen
HTTP 503: Service nicht verfügbar
Überwachen Sie Ihren Classic Load Balancer
Überwachen Sie Ihre Application Load Balancer
Führen Sie eine Fehlerbehebung für Classic Load Balancer durch: HTTP-Fehler

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 10 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren