Probleme mit dem Load-Balancing in Google Kubernetes Engine (GKE) können zu Dienstunterbrechungen wie HTTP-502-Fehlern führen oder den Zugriff auf Anwendungen verhindern.
In diesem Dokument erfahren Sie, wie Sie 502-Fehler von externem Ingress beheben und wie Sie Load-Balancer-Logs und Diagnosetools wie check-gke-ingress verwenden, um Probleme zu identifizieren.
Diese Informationen sind wichtig für Plattformadministratoren und ‑operatoren sowie Anwendungsentwickler, die Load-Balanced-Dienste in GKE konfigurieren und verwalten. Weitere Informationen zu den gängigen Rollen und Beispiel aufgaben, auf die wir in Cloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE Nutzerrollen und -aufgaben.
Externer Ingress erzeugt HTTP-502-Fehler
Folgen Sie der nachstehenden Anleitung, um HTTP-502-Fehler mit externen Ingress-Ressourcen zu beheben:
- Aktivieren Sie Logs für jeden Backend-Dienst, der jedem GKE-Dienst zugeordnet ist, auf den der Ingress verweist.
- Verwenden Sie Statusdetails, um Ursachen für HTTP-502-Antworten zu identifizieren. Statusdetails, die angeben, dass die HTTP-502-Antwort vom Backend stammt, erfordern eine Fehlerbehebung innerhalb der Bereitstellungs-Pods, nicht im Load-Balancer.
Nicht verwaltete Instanzgruppen
Es können HTTP-502-Fehler mit externen Ingress-Ressourcen auftreten, wenn Ihr externes Ingress nicht verwaltete Instanzgruppen-Back-Ends verwendet. Dieses Problem tritt auf, wenn alle der folgenden Bedingungen erfüllt sind:
- Der Cluster hat eine große Gesamtzahl von Knoten unter allen Knotenpools.
- Die Bereitstellungs-Pods für einen oder mehrere Services, auf die vom Ingress verwiesen wird, befinden sich nur auf wenigen Knoten.
- Dienste, auf die vom Ingress verwiesen wird, verwenden
externalTrafficPolicy: Local.
So ermitteln Sie, ob Ihr externes Ingress nicht verwaltete Instanzgruppen-Back-Ends verwendet:
Rufen Sie in der Cloud de Confiance Console die Seite Ingress auf.
Klicken Sie auf den Namen Ihres externen Ingress.
Klicken Sie auf den Namen des Load-Balancers. Die Seite Details zum Load-Balancing wird angezeigt.
Prüfen Sie in der Tabelle im Abschnitt Backend-Dienste, ob Ihr externes Ingress NEGs oder Instanzgruppen verwendet.
Verwenden Sie eine der folgenden Lösungen, um dieses Problem zu beheben.
- Verwenden Sie einen VPC-nativen Cluster.
- Verwenden Sie
externalTrafficPolicy: Clusterfür jeden Service, auf den der externe Ingress verweist. Bei dieser Lösung gehen die ursprüngliche Client-IP-Adresse in den Quellen des Pakets verloren. - Verwenden Sie die Annotation
node.kubernetes.io/exclude-from-external-load-balancers=true. Fügen Sie den Knoten oder Knotenpools, die keinen Bereitstellungs-Pod ausführen, die Annotation für einen Dienst hinzu, auf den von einem externen Ingress- oderLoadBalancer-Dienst in Ihrem Cluster verwiesen wird.
Logging-Konfiguration für L4-Load-Balancer
In diesem Abschnitt finden Sie Informationen zur Fehlerbehebung, wenn Sie das Logging für Ihren externen Passthrough-Network-Load-Balancer oder internen Passthrough-Network-Load-Balancer aktiviert haben.
Status der Logging-Konfiguration überwachen
Der GKE-L4LB-Controller gibt über den Typ status.conditions des Dienstes Feedback zum Status des Logging-Abgleichs. Sie können diesen Status prüfen, indem Sie den folgenden Befehl ausführen:
kubectl get svc SERVICE_NAME -o yaml
Ersetzen Sie Folgendes:
SERVICE_NAME: der Name des Clusters.
Suchen Sie in der Ausgabe nach dem Bedingungstyp LoggingConfigManaged. In der folgenden Tabelle werden die möglichen Gründe für die Bedingung beschrieben:
| Bedingungsstatus | Grund | Beschreibung |
|---|---|---|
| Wahr | Abgeglichen | Der Controller erzwingt aktiv die in der L4LBConfig-CRD definierte Logging-Konfiguration. |
| Falsch | Nicht verwaltet | Der Abschnitt logging fehlt in der L4LBConfig-CRD oder die Annotation wurde entfernt. Der
Controller hat die Verwaltung beendet und den Backend-Dienst im letzten
bekannten Zustand belassen. |
| Falsch | Fehlt | Die in der Dienstannotation referenzierte L4LBConfig-Ressource wurde nicht gefunden. |
| Falsch | Ungültig | Die L4LBConfig-Ressource hat die
Cross-Validation des optionalFields Parameters nicht bestanden. |
| Falsch | Fehler | Beim Abgleich des Backend-Dienstes ist ein Fehler aufgetreten. |
Coast-Verhalten
Wenn die Annotation networking.gke.io/l4lb-config aus dem Servicemanifest entfernt oder die referenzierte L4LBConfig-Ressource gelöscht wird, wechselt die Konfiguration in den Status Coast.
In diesem Status beendet der GKE-Controller die Verwaltung der Logging Einstellungen, setzt den Cloud de Confiance by S3NS Backend-Dienst aber nicht auf die Standard einstellungen zurück. Stattdessen verbleibt der Backend-Dienst im letzten bekannten funktionsfähigen Zustand. In der Regel wird ein Warnungsereignis ausgegeben, um Sie darüber zu informieren, dass Kubernetes die Konfiguration nicht mehr steuert.
Load-Balancer-Logs zur Fehlerbehebung verwenden
Sie können Logs von internen Passthrough-Network-Load-Balancern und Logs von externen Passthrough-Network-Load-Balancer dazu verwenden, Probleme mit Load-Balancern zu beheben und Traffic von Load Balancern mit GKE-Ressourcen zu korrelieren.
Logs werden pro Verbindung zusammengefasst und nahezu in Echtzeit exportiert. Logs werden sowohl für eingehenden als auch für ausgehenden Traffic für jeden GKE-Knoten generiert, der am Datenpfad eines LoadBalancer-Dienstes beteiligt ist. Logeinträge umfassen zusätzliche Felder für GKE-Ressourcen, z. B.:
- Cluster name
- Clusterstandort
- Dienstname
- Dienst-Namespace
- Pod-Name
- Pod-Namespace
Diagnosetools zur Fehlerbehebung verwenden
Das Diagnosetool check-gke-ingress prüft Ingress-Ressourcen auf häufige Fehlkonfigurationen. Sie können das Tool check-gke-ingress auf folgende Weise verwenden:
- Führen Sie das
gcpdiagBefehlszeilentool in Ihrem Cluster aus. Ingress-Ergebnisse werden im Abschnitt der Prüfregelgke/ERR/2023_004angezeigt. - Sie können das
check-gke-ingressTool allein oder als kubectl-Plug-in verwenden. Folgen Sie dazu der Anleitung unter check-gke-ingress.