Fehlerbehebung bei ungleichmäßiger Traffic-Verteilung

In diesem Dokument erfahren Sie, wie Sie Probleme mit einer ungleichmäßigen Traffic-Verteilung auf Kubernetes-Dienste beheben.

Symptome einer ungleichmäßigen Traffic-Verteilung erkennen

Eine ungleichmäßige Traffic-Verteilung, oft als Hotspots bezeichnet, tritt auf, wenn eine Teilmenge von Pods oder Knoten einen unverhältnismäßigen Teil der gesamten Arbeitslast verarbeitet, während andere unterlastet bleiben.

Zu den häufigsten Symptomen gehören:

  • Leistungsengpässe: Nutzer können bei überlasteten Netzwerkverbindungen zeitweise Zeitüberschreitungen, HTTP 5xx-Fehler oder Paketverluste feststellen.
  • Ressourcenerschöpfung: Bei bestimmten Pods oder Knoten ist die CPU- oder Arbeitsspeicherauslastung deutlich höher als beim Rest der Flotte.
  • Muster für Traffic-Ungleichgewichte:
    • Ungleichgewicht pro Pod: Der Traffic erreicht nur eine kleine Teilmenge der verfügbaren Pods, obwohl alle Pods als fehlerfrei und bereit gemeldet werden.
    • Ungleichgewicht pro Knoten: Ein oder mehrere Knoten empfangen deutlich mehr Pakete oder Anfragen als andere. Dies ist häufig der Fall, wenn externalTrafficPolicy: Local mit ungleichmäßiger Pod-Platzierung verwendet wird.
    • Sticky-Client-Sitzungen: Alle Anfragen von einem einzelnen Client mit hohem Volumen werden konsistent an denselben Backend-Pod weitergeleitet.

Diagnose mit Cloud Monitoring

Um diese Symptome zu bestätigen, können Sie die Traffic-Muster anhand der folgenden Messwerte visualisieren:

  • Für Layer 7 (Ingress/Gateway): Stellen Sie loadbalancing.googleapis.com/backend/request_count dar und gruppieren Sie nach backend_target, um das Anfragevolumen für verschiedene Back-Ends zu vergleichen.

Häufige Ursachen für eine ungleichmäßige Trafficverteilung

In diesem Abschnitt werden häufige Ursachen für eine ungleichmäßige Verteilung des Traffics auf Kubernetes-Dienste beschrieben. Dieses Ungleichgewicht kann zu Leistungsengpässen, Ressourcenerschöpfung bei bestimmten Pods und einer geringeren Anwendungsverfügbarkeit führen. Einige Pods erhalten deutlich mehr Traffic als andere, während einige sehr wenig oder gar keinen Traffic erhalten.

Sitzungsaffinität führt zu ungleichmäßiger Verteilung

Das folgende Problem tritt auf, wenn Load-Balancer mit aktivierter Sitzungsaffinität Anfragen vom selben Client immer an denselben Backend-Pod weiterleiten. Wenn ein bestimmter Client ein großes Traffic-Volumen generiert, wird der entsprechende Pod überlastet. Es entsteht ein Hotspot, an dem der Pod deutlich mehr Last empfängt als andere, während andere Pods unterlastet bleiben.

Sie können die Sitzungsaffinität in Kubernetes-Dienstobjekten mit dem Feld sessionAffinity konfigurieren.

Wenn sessionAffinity auf ClientIP festgelegt ist, sorgt der Dienst dafür, dass alle Verbindungen, die von derselben Client-IP-Adresse stammen, immer an denselben Backend-Pod weitergeleitet werden. Dadurch wird eine echte Client-IP-basierte Sitzungsaffinität bereitgestellt.

Wenn sessionAffinity auf None festgelegt ist (Standardverhalten), verteilen Layer 4-Load-Balancer Verbindungen in der Regel mithilfe eines Hash verschiedener Netzwerkparameter, z. B. eines 4-Tupels (Client-IP-Adresse, Ziel-IP-Adresse, Zielport, Protokoll) oder eines 5-Tupels (einschließlich Quellport). Dieses Hashing kann zwar für eine gewisse „Beständigkeit“ der Verbindung sorgen, indem Verbindungen mit identischen Tupelwerten immer an dasselbe Back-End weitergeleitet werden. Es wird jedoch nicht garantiert, dass alle Verbindungen von einer bestimmten Client-IP-Adresse immer an denselben Pod gesendet werden, wenn sich andere Tupel-Elemente ändern.

Weitere Informationen finden Sie unter Sitzungsaffinität.

Für GKE Gateway wird die Sitzungsaffinität mit der GCPTrafficDistributionPolicy-CRD konfiguriert. Weitere Informationen finden Sie unter Gateway-Ressourcen mithilfe von Richtlinien konfigurieren.

Bei regionalen externen Passthrough-Network Load Balancern können Sie die Sitzungsaffinität verwenden, um die Verbindung zu einem bestimmten Backend aufrechtzuerhalten. Beachten Sie jedoch, dass die Sitzungsaffinität selbst zu einer ungleichmäßigen Verteilung führen kann, wenn einige Clients mehr Traffic generieren als andere.

Weitere Informationen finden Sie unter Sitzungsaffinität und Übersicht über den Backend-Dienst-basierten externen Passthrough-Network Load Balancer.

Das folgende Beispiel zeigt ein Dienstmanifest mit sessionAffinity: ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # This can cause uneven distribution
  ports:
  -   port: 80
    targetPort: 8080
  selector:
    app: my-app

Verbindungs-Pooling führt zu ungleichmäßiger Verteilung

Verbindungs-Pooling tritt auf, wenn Load-Balancer vorhandene Verbindungen zu bestimmten Pods wiederverwenden, auch wenn andere Pods freie Kapazität haben. Dieses Verhalten kann zu einem Ungleichgewicht führen, wenn einige Verbindungen länger bestehen oder deutlich mehr Anfragen als andere verarbeiten. Dadurch wird der Traffic auf bestimmte Pods konzentriert, ähnlich wie bei der Sitzungsaffinität. Es entstehen Hotspots, an denen diese Pods überlastet sind, während andere Pods unterlastet bleiben.

Load Balancer implementieren Verbindungs-Pooling, um die Leistung zu verbessern, indem der Aufwand für das Herstellen neuer Verbindungen reduziert wird. Wenn das Verbindungs-Pooling jedoch nicht richtig verwaltet wird, kann es zu einer ungleichmäßigen Verteilung des Traffics kommen, insbesondere bei Anwendungen mit langlebigen Verbindungen.

Um eine ungleichmäßige Verteilung aufgrund von Connection Pooling zu vermeiden, können Sie Strategien auf Anwendungs- oder Clientebene implementieren:

  • Clients für die Verwendung mehrerer Verbindungen konfigurieren: Anstatt sich auf eine einzelne langlebige Verbindung zu verlassen, sollten Sie Clients so konfigurieren, dass sie einen Pool mit mehreren Verbindungen zum Load Balancer öffnen und verwalten. So kann der Load Balancer neue Verbindungsversuche auf die verfügbaren Back-End-Pods verteilen, was die allgemeine Traffic-Verteilung verbessert.

  • Verbindungen regelmäßig schließen und wieder öffnen: Konfigurieren Sie Anwendungen, die von Natur aus langlebige Verbindungen aufrechterhalten, oder deren Clients so, dass Verbindungen regelmäßig geschlossen und wieder geöffnet werden. Dies führt zwar zu einem geringen Overhead durch das erneute Herstellen der Verbindung, bietet dem Load Balancer aber neue Möglichkeiten, nachfolgende Verbindungsversuche auf verschiedene, weniger ausgelastete Backend-Pods zu verteilen. Dieser Ansatz ist besonders effektiv für Dienste, bei denen das Beenden und Wiederherstellen von Verbindungen nicht zu störend ist.

  • Aggressiven Verbindungsausgleich implementieren: Achten Sie darauf, dass Ihre Pods für das ordnungsgemäße Herunterfahren und den Verbindungsausgleich konfiguriert sind. Wenn ein Pod ordnungsgemäß beendet wird (z. B. während eines Deployments oder einer Herunterskalierung), sollte der Load Balancer keine neuen Verbindungen mehr an ihn senden und bestehende Verbindungen abschließen oder ausgleichen. Dadurch kann der Traffic reibungsloser auf andere Pods verlagert werden und es wird verhindert, dass er sich auf beendete Pods konzentriert.

Durch die aktive Verwaltung des Verbindungsverhaltens können Sie Load Balancer dabei unterstützen, den Traffic gleichmäßiger zu verteilen, auch bei langlebigen Verbindungen.

5-Tupel-Hashing führt zu ungleichmäßiger Verteilung

Dies ist das Standardverhalten vieler Layer-4-Load-Balancer, wenn Sie die Sitzungsaffinität nicht explizit konfigurieren. Wenn viele Verbindungen vom selben Client stammen oder dieselben Portkombinationen verwenden, führt dies zu einer ungleichmäßigen Verteilung.

So beheben Sie Ungleichgewichte, die durch Hashing verursacht werden:

  • Layer-7-Load-Balancing verwenden: GKE Ingress und Gateway arbeiten auf Anfrageebene, sodass sie Anfragen von einem einzelnen Client auf mehrere Backend-Pods verteilen können.

  • Clientverhalten anpassen: Konfigurieren Sie Clients so, dass sie mehrere Verbindungen oder einen größeren Pool von Quellports verwenden.

Ungleichmäßige Pod-Verteilung auf Knoten führt zu ungleichmäßiger Verteilung

Dieses Problem tritt auf, wenn Pods nicht gleichmäßig auf Knoten verteilt sind und der Load Balancer kein containernatives Load-Balancing verwendet. Knoten mit mehr Pods erhalten mehr Traffic, was dazu führen kann, dass einige Knoten überlastet sind, während andere nicht ausgelastet sind.

Dieses Problem ist besonders relevant, wenn Sie externalTrafficPolicy: Local verwenden.

Einstellungen für die Richtlinie für externen Traffic führen zu ungleichmäßiger Verteilung

Die Einstellung externalTrafficPolicy für Ihren Dienst wirkt sich auf das Routing des Traffics aus.

  • Cluster: Ermöglicht es dem Load Balancer, Traffic an einen beliebigen Knoten im Cluster zu verteilen. Verwenden Sie die Einstellung Cluster für die gleichmäßigste Verteilung auf alle verfügbaren Knoten und Pods.
  • Lokal: Leitet Traffic nur an Pods weiter, die auf demselben Knoten ausgeführt werden, der den Traffic empfangen hat. Dies kann zu einer ungleichmäßigen Verteilung führen, wenn Sie Pods nicht gleichmäßig auf Knoten verteilen.

Knotenaffinität führt zu ungleichmäßiger Verteilung

Wenn Sie die Knotenaffinität verwenden, um Pods auf eine Teilmenge von Knoten zu beschränken, kann dies dazu führen, dass diese Knoten überlastet werden, insbesondere wenn die Arbeitslast nicht gleichmäßig auf sie verteilt ist.

Achten Sie darauf, dass Ihre Pods nicht an bestimmte Knoten angepinnt sind.