Fehlerbehebung bei Ingress-Systemdiagnosen

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

Funktionsweise von Ingress-Systemdiagnosen

Bevor Sie mit der Fehlerbehebung fortfahren, kann es hilfreich sein, zu verstehen, wie Systemdiagnosen in GKE funktionieren und welche Überlegungen Sie berücksichtigen müssen, um erfolgreiche Systemdiagnosen zu gewährleisten.

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 Trusted 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 Backend-Dienst angegeben. While it's possible to use the same health check for all backend services of the load balancer, the health check reference isn't specified for the whole load balancer (at the Ingress object itself).

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 für den klassischen Application Load Balancer und den internen Application Load Balancer, die von einem Ingress erstellt werden.
  • 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 anhand 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 Readiness-Prü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:

Verwenden Sie eine BackendConfig-CRD, um die Einstellungen für die Load-Balancer-Systemdiagnose optimal zu steuern.

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 bei der Konfiguration einer BackendConfig-CRD oder der Verwendung eines Bereitschaftsprobes berücksichtigen sollten.

BackendConfig CRD

Beachten Sie beim Konfigurieren von BackendConfig CRDs Folgendes:

  • Wenn Sie containernatives Load-Balancing verwenden, muss der Systemdiagnoseport im BackendConfig-Manifest mit dem containerPort eines bereitstellenden Pods übereinstimmen.
  • Achten Sie bei Instanzgruppen-Back-Ends darauf, dass der Port für die Systemdiagnose im BackendConfig-Manifest mit dem vom Service 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 Systemdiagnoseprüfungen, um festzustellen, ob Ihre Anwendung ordnungsgemäß ausgeführt wird. Diese Systemdiagnoseprüfungen werden an den bestimmten 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 Portnummer der Bereitschaftsprüfung, die in spec.containers[].readinessProbe.httpGet.port angegeben ist, muss mit dem tatsächlichen Port übereinstimmen, den Ihre Anwendung im Container überwacht. Dieser Port wird im Feld containers[].spec.ports.containerPort Ihrer Pod-Konfiguration definiert.
  • Der containerPort des Bereitstellungs-Pods muss mit dem targetPort des Service übereinstimmen. So wird sichergestellt, dass der Traffic vom Dienst an den richtigen Port in 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 Systemdiagnosen beheben

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

Fehlerbehebung bei Ingress-Systemdiagnosen.
Abbildung: Fehlerbehebung bei Health Checks

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

  1. Pod-Status untersuchen: Wenn die Systemdiagnose fehlschlägt, prüfen Sie den Status der Bereitstellungs-Pods Ihres Dienstes. Wenn die Pods nicht ausgeführt werden und fehlerfrei sind:

    • Prüfen Sie die Pod-Logs auf Fehler oder Probleme, die die Ausführung verhindern.
    • Prüfen Sie den Status von Bereitschafts- und Aktivitätsprüfungen.

  2. Logging für Systemdiagnosen: Achten Sie darauf, dass Sie das Logging für Systemdiagnosen aktiviert haben.

  3. Firewallkonfiguration prüfen: Achten Sie darauf, dass Ihre Firewallregeln zulassen, dass Systemdiagnoseprüfungen Ihre Pods erreichen. Falls nicht:

    • Prüfen Sie Ihre Firewallregeln, um zu bestätigen, dass sie eingehenden Traffic aus den IP-Adressbereichen für Systemdiagnoseprüfungen zulassen.
    • Passen Sie die Firewallregeln nach Bedarf an diese IP-Adressbereiche an.

  4. 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 zeigt, wenden Sie sich bitte an denTrusted Cloud by S3NS Support.

  5. Fehlerbehebung bei der Anwendung: Wenn die Paketerfassung keine erfolgreiche Antwort zeigt, untersuchen 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 untersuchen Sie Anwendungslogs, Konfigurationsdateien und Abhängigkeiten. Wenn Sie den Fehler nicht finden können, wenden Sie sich an den Trusted Cloud by S3NS -Support.

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 den konfigurierten Port oder Pfad nicht.
    • Es gibt Probleme mit der Netzwerkverbindung, 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 Einrichtung so vor:

Für NEGs:

  1. Mit kubectl exec auf einen Pod zugreifen:

    kubectl exec -it pod-name -- command

    Das Flag -it stellt eine interaktive Terminalsitzung bereit (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 zu erhalten.

  2. 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:

  1. Prüfen Sie, ob die Knoten fehlerfrei sind und auf Standard-Systemdiagnoseprüfungen reagieren.
  2. Wenn die Knoten fehlerfrei sind, der Anwendungs-Pod aber nicht reagiert, untersuchen Sie die Anwendung genauer.
  3. Wenn Anfragen die Pods nicht erreichen, liegt möglicherweise ein GKE-Netzwerkproblem vor. Wenden Sie sich an den Trusted Cloud by S3NS -Support, um Unterstützung zu erhalten.

Fehler beim Bearbeiten des Readiness-Probe auf dem Pod

Wenn Sie versuchen, die Bereitschaftsprüfung für einen Pod zu bearbeiten, um Systemdiagnoseparameter zu ändern, wird ein Fehler wie der folgende angezeigt:

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-Objekt (und dem entsprechenden Load-Balancer) verknüpft ist, aktualisiert GKE die Systemdiagnosekonfiguration des Load-Balancers nicht automatisch. Dies führt zu einer Diskrepanz zwischen der Bereitschaftsprüfung des Pods und der Systemdiagnose des Load-Balancers, wodurch die Systemdiagnose fehlschlägt.

Stellen Sie die Pods und die Ingress-Ressource neu bereit, um das Problem zu beheben. Dadurch wird GKE gezwungen, den Load-Balancer und seine Systemdiagnosen neu zu erstellen und die neuen Einstellungen für die Bereitschaftsprüfung zu berücksichtigen.

Bereitstellung und Load Balancer können nicht gestartet werden

Wenn Ihre Bereitstellung nicht gestartet wird und die Back-End-Dienste hinter dem Load-Balancer Ihres Ingress-Controllers als fehlerhaft markiert sind, kann dies an einem Fehler bei der Bereitschaftsprüfung liegen.

Möglicherweise wird die folgende Fehlermeldung angezeigt, in der ein Fehler bei einem Bereitschaftsprobing erwähnt wird:

Readiness probe failed: connection refused

Die Anwendung im Pod reagiert nicht richtig auf die Readiness-Probe, die in der YAML-Konfiguration des Pods konfiguriert ist. Das kann verschiedene Ursachen haben, z. B. wenn die Anwendung nicht richtig gestartet wird, der falsche Port verwendet wird oder bei der Initialisierung ein Fehler auftritt.

Um dieses Problem zu beheben, müssen Sie alle Unstimmigkeiten in der Konfiguration oder dem Verhalten Ihrer Anwendung untersuchen und korrigieren. Gehen Sie dazu so vor:

  • Prüfen Sie, ob die Anwendung richtig konfiguriert ist und auf dem Pfad und Port reagiert, die in den Bereitschaftsprüfungsparametern angegeben sind.
  • Prüfen Sie die Anwendungslogs und beheben Sie alle Startprobleme oder Fehler.
  • Prüfen Sie, ob der containerPort in der Pod-Konfiguration mit dem targetPort im Service 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 erstellt werden, wenn eine Ingress-Ressource erstellt wird, 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 eingehenden Traffic 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 die automatische Erstellung auszulösen.
  • Achten Sie darauf, dass die Firewallregeln Traffic über die entsprechenden Ports und Protokolle zulassen, wie in Ihrer Ingress-Ressource definiert.

Falsches Protokoll im BackendConfig-Manifest verwendet

Wenn Sie eine BackendConfig-CRD mit einem TCP-Protokoll konfigurieren, wird der folgende Fehler 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.

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: