Fehlerbehebung bei ungleichmäßiger Traffic-Verteilung

In diesem Dokument wird beschrieben, wie Sie Probleme mit einer ungleichmäßigen Verteilung des Traffics auf Kubernetes-Dienste beheben.

Symptome einer ungleichmäßigen Traffic-Verteilung erkennen

Eine ungleichmäßige Verteilung des Traffics, 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 unterausgelastet bleiben.

Häufige Symptome sind:

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

Diagnose mit Cloud Monitoring

Um diese Symptome zu bestätigen, visualisieren Sie Traffic-Muster mit den folgenden Messwerten:

  • Für Ebene 7 (Ingress/Gateway): zeichnen Sie loadbalancing.googleapis.com/backend/request_count auf und gruppieren Sie nach backend_target, um die Anfragevolumina für verschiedene Back-Ends zu vergleichen.

Häufige Ursachen für eine ungleichmäßige Traffic-Verteilung

In diesem Abschnitt werden häufige Ursachen für eine ungleichmäßige Traffic-Verteilung 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 verursacht ungleichmäßige 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 hohes Traffic-Volumen erzeugt, wird dieser Pod überlastet. Dadurch entsteht ein Hotspot, bei dem er deutlich mehr Last erhält als andere, während andere Pods unterausgelastet 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 von derselben Client-IP-Adresse immer an denselben Backend-Pod weitergeleitet werden. Dadurch wird eine echte Client-IP-basierte Sitzungsaffinität erreicht.

Wenn sessionAffinity auf None festgelegt ist (Standardverhalten), verteilen Load-Balancer der Ebene 4 Verbindungen in der Regel mithilfe eines Hashs 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 eine gewisse Verbindungsaffinität bieten, indem Verbindungen mit identischen Tupelwerten immer an dasselbe Backend weitergeleitet werden. Es garantiert jedoch nicht, dass alle Verbindungen von einer bestimmten Client-IP-Adresse immer an denselben Pod weitergeleitet 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 mit Richtlinien konfigurieren.

Für regionale externe Passthrough-Netzwerk-Load-Balancer können Sie die Sitzungsaffinität verwenden, um die Verbindungsaffinität zu einem bestimmten Backend aufrechtzuerhalten. Die Sitzungsaffinität kann jedoch selbst zu einer ungleichmäßigen Verteilung führen, wenn einige Clients mehr Traffic erzeugen als andere.

Weitere Informationen finden Sie unter Sitzungsaffinität und Übersicht über Backend-Dienst-basierte externe Passthrough-Netzwerk-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 verursacht ungleichmäßige 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 verarbeiten als andere. Dadurch wird der Traffic auf bestimmte Pods konzentriert, ähnlich wie bei der Sitzungsaffinität. Es entstehen Hotspots, bei denen diese Pods überlastet werden, während andere Pods unterausgelastet 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 führen, insbesondere bei Anwendungen, die lang andauernde Verbindungen aufrechterhalten.

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

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

  • Verbindungen regelmäßig schließen und wieder öffnen: Konfigurieren Sie Anwendungen, die von Natur aus lang andauernde Verbindungen aufrechterhalten, oder ihre Clients so, dass Verbindungen regelmäßig geschlossen und wieder geöffnet werden. Dadurch entsteht zwar ein geringer Aufwand für das erneute Herstellen der Verbindung, aber der Load-Balancer hat neue Möglichkeiten, nachfolgende Verbindungsversuche auf andere, weniger ausgelastete Backend-Pods zu verteilen. Dieser Ansatz ist besonders effektiv für Dienste, bei denen das Beenden und erneute Herstellen von Verbindungen nicht zu großen Unterbrechungen führt.

  • 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 einer Bereitstellung oder einer Herunterskalierung), sollte der Load-Balancer keine neuen Verbindungen mehr an ihn senden und vorhandene Verbindungen abschließen oder ausgleichen. So kann der Traffic reibungsloser zu anderen Pods verlagert werden und es wird verhindert, dass sich der Traffic auf Pods konzentriert, die beendet werden.

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

5-Tupel-Hashing verursacht ungleichmäßige Verteilung

Dies ist das Standardverhalten für viele Load-Balancer der Ebene 4, 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:

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

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

Ungleichmäßige Pod-Verteilung auf Knoten verursacht ungleichmäßige 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 unterausgelastet sind.

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

Einstellungen für die Richtlinie für externen Traffic verursachen ungleichmäßige Verteilung

Die Einstellung externalTrafficPolicy für Ihren Dienst wirkt sich auf die Weiterleitung des Traffics aus.

  • Cluster: Ermöglicht dem Load-Balancer, Traffic an einen beliebigen Knoten in the cluster zu verteilen. Verwenden Sie die Einstellung Cluster für die gleichmäßigste Verteilung auf alle verfügbaren Knoten und Pods.
  • Local: 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 verursacht ungleichmäßige Verteilung

Wenn Sie die Knotenaffinität verwenden, um Pods auf eine Teilmenge von Knoten zu beschränken, können 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.