Diese Seite wurde von der Cloud Translation API übersetzt.

Fehlerbehebung bei Ingress-Systemdiagnosen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit Ingress-Überprüfungen in der Google Kubernetes Engine (GKE) beheben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Funktionsweise von Ingress-Systemdiagnosen

Bevor Sie mit den Schritten zur Fehlerbehebung fortfahren, sollten Sie sich mit der Funktionsweise von Systemdiagnosen in GKE und den Voraussetzungen für erfolgreiche Systemdiagnosen vertraut machen.

Wenn Sie einen oder mehrere Services über einen Ingress mithilfe des Standard-Ingress-Controllers verfügbar machen, erstellt GKE einen klassischen Application Load Balancer oder einen internen Application Load Balancer. Beide Load Balancer unterstützen mehrere Back-End-Dienste für eine einzelne URL-Zuordnung. Jeder dieser Back-End-Dienste entspricht einem Kubernetes-Dienst und jeder Back-End-Dienst muss auf eine Google Cloud -Systemdiagnose verweisen. Diese Systemdiagnose unterscheidet sich von einer Kubernetes-Aktivitätsprüfung oder -Bereitschaftsprüfung, da die Systemdiagnose außerhalb des Clusters implementiert wird.

Load Balancer-Systemdiagnosen werden pro Backenddienst angegeben. Es ist zwar möglich, dieselbe Systemdiagnose für alle Backend-Dienste des Load Balancers zu verwenden, die Referenz für die Systemdiagnose wird jedoch nicht für den gesamten Load Balancer (im Ingress-Objekt selbst) angegeben.

GKE erstellt Systemdiagnosen anhand einer der folgenden Methoden:

BackendConfig-CRD: Eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD), mit der Sie genau steuern können, wie Ihre Dienste mit dem Load Balancer interagieren. Mit BackendConfig-CRDs können Sie benutzerdefinierte Einstellungen für die Systemdiagnose des entsprechenden Back-End-Dienstes angeben. Diese benutzerdefinierten Einstellungen bieten mehr Flexibilität und Kontrolle über Systemdiagnosen sowohl für den klassischen Application Load Balancer als auch für den internen Application Load Balancer, der von einem Ingress erstellt wurde.
Bereitschaftsprüfung: Eine Diagnoseprüfung, mit der ermittelt wird, ob ein Container in einem Pod bereit ist, Traffic zu verarbeiten. Der GKE-Ingress-Controller erstellt die Systemdiagnose für den Back-End-Dienst des Dienstes basierend auf der Bereitschaftsprüfung, die von den Bereitstellungs-Pods dieses Dienstes verwendet wird. Sie können die Systemdiagnoseparameter wie Pfad, Port und Protokoll aus der Definition der Bereitschaftsprüfung ableiten.
Standardwerte: Die Parameter, die verwendet werden, wenn Sie keine BackendConfig-CRD konfigurieren oder keine Attribute für die Bereitschaftsprüfung definieren.

Best Practice:

Mit einer BackendConfig-CRD haben Sie die beste Kontrolle über die Einstellungen für die Load-Balancer-Systemdiagnose.

GKE erstellt anhand des folgenden Verfahrens eine Systemdiagnose für jeden Back-End-Dienst entsprechend einem Kubernetes-Service bereit:

Wenn der Dienst auf eine BackendConfig-CRD mit healthCheck-Informationen verweist, verwendet GKE diese zum Erstellen der Systemdiagnose. Sowohl der GKE Enterprise-Ingress-Controller als auch der GKE-Ingress-Controller unterstützen die Erstellung von Systemdiagnosen auf diese Weise.
Wenn der Service nicht auf eine BackendConfig-CRD verweist:
- GKE kann einige oder alle Parameter für eine Systemdiagnose ableiten, wenn die Bereitstellungs-Pods eine Pod-Vorlage mit einem Container verwenden, dessen Bereitschaftsprüfung Attribute enthält, die als Systemdiagnoseparameter interpretiert werden können. Weitere Informationen zur Implementierung finden Sie unter Parameter aus einer Bereitschaftsprüfung. Unter Standardparameter und abgeleitete Parameter finden Sie eine Liste der Attribute, mit denen Systemdiagnoseparameter erstellt werden können. Nur der GKE-Ingress-Controller unterstützt das Ableiten von Parametern aus einer Bereitschaftsprüfung.
- Wenn die Pod-Vorlage für die Bereitstellungs-Pods des Service keinen Container mit einer Bereitschaftsprüfung haben, deren Attribute als Systemdiagnoseparameter interpretiert werden können, werden die Standardwerte zum Erstellen der Systemdiagnose verwendet. Sowohl der GKE Enterprise-Ingress-Controller als auch der GKE-Ingress-Controller können eine Systemdiagnose erstellen, die nur die Standardwerte verwendet.

Hinweise

In diesem Abschnitt werden einige Aspekte beschrieben, die Sie beim Konfigurieren einer BackendConfig-CRD oder beim Verwenden eines Bereitschaftstests beachten sollten.

`BackendConfig` CRD

Beachten Sie beim Konfigurieren von BackendConfig-CRDs Folgendes:

Wenn Sie containernatives Load Balancing verwenden, muss der Port für die Systemdiagnose im BackendConfig-Manifest mit dem containerPort eines Bereitstellungs-Pods übereinstimmen.
Achten Sie bei Instanzgruppen-Back-Ends darauf, dass der Port für die Systemdiagnose im BackendConfig-Manifest mit dem vom Dienst bereitgestellten nodePort übereinstimmt.
Ingress unterstützt kein gRPC für benutzerdefinierte Systemdiagnosekonfigurationen. Die BackendConfig unterstützt nur das Erstellen von Systemdiagnosen mit den Protokollen HTTP, HTTPS oder HTTP2. Ein Beispiel für die Verwendung des Protokolls in einer BackendConfig-CRD finden Sie unter gke-networking-recipes.

Weitere Informationen finden Sie unter Wann sollten BackendConfig-CRDs verwendet werden?

Bereitschaftsprüfung

Wenn Sie GKE Ingress mit HTTP- oder HTTPS-Load Balancing verwenden, sendet GKE die Systemdiagnosetests, um festzustellen, ob Ihre Anwendung ordnungsgemäß ausgeführt wird. Diese Systemdiagnose-Prüfungen werden an den Port in Ihren Pods gesendet, den Sie im Abschnitt spec.containers[].readinessProbe.httpGet.port der YAML-Konfiguration Ihres Pods definiert haben, sofern die folgenden Bedingungen erfüllt sind:

Die in spec.containers[].readinessProbe.httpGet.port angegebene Portnummer der Bereitschaftsprüfung muss mit dem tatsächlichen Port übereinstimmen, auf den Ihre Anwendung im Container wartet. Dieser ist im Feld containers[].spec.ports.containerPort Ihrer Pod-Konfiguration definiert.
Der containerPort des Bereitstellungs-Pods muss mit dem targetPort des Dienstes übereinstimmen. So wird sichergestellt, dass der Traffic vom Dienst an den richtigen Port auf Ihren Pods weitergeleitet wird.
Die Ingress-Dienst-Backend-Portspezifikation muss auf einen gültigen Port aus dem Abschnitt spec.ports[] der Dienstkonfiguration verweisen. Dazu gibt es zwei Möglichkeiten:
- spec.rules[].http.paths[].backend.service.port.name im Ingress stimmt mit spec.ports[].name überein, das im entsprechenden Service definiert ist.
- spec.rules[].http.paths[].backend.service.port.number im Ingress stimmt mit spec.ports[].port überein, das im entsprechenden Service definiert ist.

Häufige Probleme bei der Systemdiagnose beheben

Anhand des folgenden Flussdiagramms zur Fehlerbehebung können Sie Probleme mit der Systemdiagnose ermitteln:

Fehlerbehebung bei Ingress-Systemdiagnosen — **Abbildung:** Fehlerbehebung bei Systemüberprüfungen

In diesem Flussdiagramm helfen Ihnen die folgenden Anleitungen zur Fehlerbehebung zu ermitteln, wo das Problem liegt:

Pod-Zustand prüfen: Wenn die Systemdiagnose fehlschlägt, prüfen Sie den Status der Bereitstellungs-Pods Ihres Dienstes. Wenn die Pods nicht ausgeführt werden und nicht fehlerfrei sind:
- Prüfen Sie die Pod-Logs auf Fehler oder Probleme, die den Start verhindern.
- Prüfen Sie den Status der Bereitschafts- und Aktivitätsprüfungen.
Logging für Systemdiagnosen: Achten Sie darauf, dass das Logging für Systemdiagnosen aktiviert ist.
Firewallkonfiguration prüfen: Achten Sie darauf, dass Ihre Firewallregeln es den Systemdiagnosen ermöglichen, Ihre Pods zu erreichen. Falls nicht:
- Prüfen Sie Ihre Firewallregeln, um sicherzustellen, dass sie eingehenden Traffic aus den IP-Adressbereichen der Systemdiagnoseprüfungen zulassen.
- Passen Sie die Firewallregeln nach Bedarf an diese IP-Adressbereiche an.
Paketerfassung analysieren: Wenn die Firewall richtig konfiguriert ist, führen Sie eine Paketerfassung durch, um zu sehen, ob Ihre Anwendung auf die Systemdiagnosen reagiert. Wenn die Paketerfassung eine erfolgreiche Antwort anzeigt, wenden Sie sich bitte an denGoogle Cloud -Support, um weitere Unterstützung zu erhalten.
Fehlerbehebung bei der Anwendung: Wenn in der Paketerfassung keine erfolgreiche Antwort angezeigt wird, prüfen Sie, warum Ihre Anwendung nicht richtig auf Systemdiagnoseanfragen reagiert. Prüfen Sie, ob die Systemdiagnose auf den richtigen Pfad und Port der Pods ausgerichtet ist, und prüfen Sie Anwendungsprotokolle, Konfigurationsdateien und Abhängigkeiten. Wenn Sie den Fehler nicht finden können, wenden Sie sich an den Support von Google Cloud .

Anwendung reagiert nicht auf Systemdiagnosen

Die Anwendung antwortet bei den Systemdiagnosen für den konfigurierten Pfad und Port nicht mit dem erwarteten Statuscode (200 OK für HTTP oder SYN, ACK für TCP).

Wenn Ihre Anwendung nicht richtig auf die Systemdiagnosen reagiert, kann das einen der folgenden Gründe haben:

Netzwerk-Endpunktgruppen(NEGs):
- Die Anwendung wird im Pod nicht richtig ausgeführt.
- Die Anwendung überwacht nicht den konfigurierten Port oder Pfad.
- Es gibt Netzwerkverbindungsprobleme, die verhindern, dass die Systemdiagnose den Pod erreicht.
Instanzgruppe:
- Die Knoten in der Instanzgruppe sind nicht fehlerfrei.
- Die Anwendung wird auf den Knoten nicht richtig ausgeführt.
- Die Systemdiagnoseanfragen erreichen die Knoten nicht.

Wenn Ihre Systemdiagnosen fehlschlagen, gehen Sie je nach Konfiguration so vor, um das Problem zu beheben:

Für NEGs:

So greifen Sie mit kubectl exec auf einen Pod zu:
```
kubectl exec -it pod-name -- command
```
Das Flag -it ermöglicht eine interaktive Terminalsitzung (i für „interaktiv“, t für „TTY“).

Ersetzen Sie Folgendes:
- pod-name: der Name Ihres Pods.
- command: Der Befehl, den Sie im Pod ausführen möchten. Der häufigste Befehl ist bash oder sh, um eine interaktive Shell aufzurufen.
Führen Sie curl-Befehle aus, um die Verbindung und die Reaktionsfähigkeit der Anwendung zu testen:
- curl localhost:<Port>/<Path>
- curl -v http://<POD_IP>/[Path configured in HC]
- curl http://localhost/[Path configured in HC]

Für Instanzgruppen:

Prüfen Sie, ob die Knoten fehlerfrei sind und auf die Standardprüfungen der Systemdiagnose reagieren.
Wenn die Knoten fehlerfrei sind, der Anwendungs-Pod aber nicht reagiert, untersuchen Sie die Anwendung genauer.
Wenn Anfragen die Pods nicht erreichen, kann es sich um ein GKE-Netzwerkproblem handeln. Wenden Sie sich an den Google Cloud -Support, um Hilfe zu erhalten.

Fehler beim Bearbeiten der Bereitschaftsprüfung für einen Pod

Wenn Sie versuchen, die Bereitschaftsprüfung eines Pods zu bearbeiten, um die Systemdiagnoseparameter zu ändern, führt dies zu einem Fehler wie dem folgenden:

Pod "pod-name" is invalid: spec: Forbidden: pod updates may not change fields

Wenn Sie die Bereitschaftsprüfung von Pods ändern, die mit einem Dienst verknüpft sind, der bereits mit einem Ingress (und dem entsprechenden Load Balancer) verknüpft ist, wird die Systemdiagnosekonfiguration auf dem Load Balancer von GKE nicht automatisch aktualisiert. Dies führt zu einer Abweichung zwischen der Bereitschaftsprüfung des Pods und der Systemdiagnose des Load Balancers, wodurch die Systemdiagnose fehlschlägt.

Um das Problem zu beheben, stellen Sie die Pods und die Ingress-Ressource neu bereit. Dadurch muss GKE den Load Balancer und seine Systemdiagnosen neu erstellen und die neuen Einstellungen für die Bereitschaftsprüfung einbinden.

Bereitstellung und Load Balancer können nicht gestartet werden

Wenn Ihre Bereitstellung nicht gestartet werden kann und die Back-End-Dienste hinter dem Load Balancer Ihres Ingress-Controllers als fehlerhaft gekennzeichnet sind, ist möglicherweise ein Fehler bei der Bereitschaftsprüfung die Ursache.

Möglicherweise wird die folgende Fehlermeldung angezeigt, in der ein Fehler bei der Bereitschaftsprüfung erwähnt wird:

Readiness probe failed: connection refused

Die Anwendung im Pod reagiert nicht richtig auf die in der YAML-Konfiguration des Pods konfigurierte Bereitschaftsprüfung. Das kann verschiedene Ursachen haben, z. B. dass die Anwendung nicht richtig gestartet wird, auf dem falschen Port wartet oder während der Initialisierung ein Fehler auftritt.

Um das Problem zu beheben, untersuchen und korrigieren Sie Abweichungen in der Konfiguration oder dem Verhalten Ihrer Anwendung. Gehen Sie dazu so vor:

Prüfen Sie, ob die Anwendung richtig konfiguriert ist und auf den in den Parametern der Bereitschaftsprüfung angegebenen Pfad und Port antwortet.
Prüfen Sie die Anwendungsprotokolle und beheben Sie alle Startprobleme oder Fehler.
Prüfen Sie, ob der containerPort in der Pod-Konfiguration mit dem targetPort im Dienst und dem im Ingress angegebenen Backend-Port übereinstimmt.

Fehlende automatische Firewallregeln für eingehenden Traffic

Sie haben eine Ingress-Ressource erstellt, aber der Traffic erreicht den Backend-Dienst nicht.

Die automatischen Ingress-Firewallregeln, die normalerweise von GKE beim Erstellen einer Ingress-Ressource erstellt werden, fehlen oder wurden versehentlich gelöscht.

So stellen Sie die Verbindung zu Ihrem Backend-Dienst wieder her:

Prüfen Sie, ob die automatischen Firewallregeln für den Eingang in Ihrem VPC-Netzwerk vorhanden sind.
Wenn die Regeln fehlen, können Sie sie manuell neu erstellen oder die Ingress-Ressource löschen und neu erstellen, um ihre automatische Erstellung auszulösen.
Achten Sie darauf, dass die Firewallregeln den Traffic auf den entsprechenden Ports und Protokollen zulassen, die in Ihrer Ingress-Ressource definiert sind.

Im `BackendConfig`-Manifest wird ein falsches Protokoll verwendet

Wenn Sie eine BackendConfig-CRD mit einem TCP-Protokoll konfigurieren, wird die folgende Fehlermeldung angezeigt:

Error syncing to GCP: error running backend syncing routine:
error ensuring health check: Protocol "TCP" is not valid, must be one of ["HTTP","HTTPS","HTTP2"]'

Die BackendConfig unterstützt nur das Erstellen von Systemdiagnosen mit den Protokollen HTTP, HTTPS oder HTTP/2. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP, HTTPS und HTTP/2.

Nächste Schritte

Informationen zum Einrichten benutzerdefinierter Systemdiagnosen für Ingress in einem einzelnen Cluster finden Sie unter GKE-Netzwerkrezepte.