Kubernetes Load Balancer mit Sticky Session sendet Verkehr immer an einen Pod

Question

Ich habe ein Problem mit meinem Load Balancer-Setup, bei dem der meiste Verkehr (etwa 99 %) immer auf einen Pod umgeleitet wird. Grundsätzlich ist die Infrastruktur wie abgebildetauf diesem Diagramm. Das Ziel besteht darin, dass Sticky Sessions aktiviert werden müssen, egal ob auf Nginx oder Google Load Balancer, und dass mein Datenverkehr gleichmäßig auf die verfügbaren Pods verteilt wird.

Kurz gesagt, ich habe 2 RCs und 2 Dienste in meinem Cluster. 1 Pod von nginx, der hinter einem Google Loadbalancer (nginx-lb) und einem weiteren Loadbalancer (app-lb) bereitgestellt wird, um den Verkehr auf 2 App-Pods zu verteilen. Das dachte ich mir über die Konfiguration:

• nginx-lb: Ich habe nginx-lb auf sessionAffinity: Noneund gesetzt externalTrafficPolicy: Local, weil ich denke, dass ich jetzt keine Sticky Session brauche, aber ich mussIP des Benutzers weitergeben. Ab diesem Punkt wird der gesamte eingehende Datenverkehr gleich behandelt, aber wir versuchen, die IP des Benutzers durch die Einstellung beizubehalten externalTrafficPolicy: Local.

• nginx: Der nginx selbst hat aktiviertngx_http_realip_moduleum die IP des Benutzers weitergeleitet zu lassen, aber ich habe hier ip_hash nicht verwendet, da ich immer noch der Meinung bin, dass wir hier noch keine Sticky Session brauchen. Genau wie bei nginx-lb versuche ich, den gesamten eingehenden Datenverkehr durchzulassen, aber die IP des Benutzers beizubehalten. Das nginx ist hier hauptsächlich für Proxy und SSL-Handler gedacht.

• app-lb: Dann kommt zu app-lb, wo ich sessionAffinity: ClientIPfür Sticky Session aktiviert habe und externalTrafficPolicy: ClusterfürLastverteilung. Ich glaube, hier findet der eigentliche Lastausgleich durch ClientIP statt, da dies der einzige Dienst ist, der zwei Pods dahinter hat/kennt.

Ich habe diese Konfiguration einen Tag lang mit ungefähr 50 Benutzern getestet, die immer noch auf einen Pod umgeleitet haben, während der andere Pod im Leerlauf war und im Vergleich zum ersten eine geringere CPU- und Speicherauslastung aufwies.

Ich möchte fragen, ob ich mit dem Setup das erreiche, was ich erreichen möchte. Gibt es eine Konfiguration, die ich übersehen habe? Für jede Anregung bin ich sehr dankbar.

PS. Ich habe die ganze Frage neu geschrieben, um weitere Fakten hinzuzufügen, die ich nicht verstanden habe, die aber im Grunde immer noch für die ursprüngliche Frage relevant sind, nur mit anderen Formulierungen.

Answer 1

Dies geschieht, weil Sie verwenden sessionAffinity: ClientIP. Dies ist die Affinität zum Dienst und basiert auf IP. Der Dienst erhält also die IP Ihres Loadbalancers. Versuchen Sie, diese zu verwenden. sessionAffinity: NoneWenn Sie Sticky Sessions verwenden möchten, verwenden Sie den Nginx Ingress Controller.

Answer 2

Haben Sie versucht, Ihre Apps mit einer größeren Anzahl von Clients als Ihrem Handy und Ihrem Laptop zu testen?
Vielleicht könnten Sie es von mehreren Google Compute Engine-Instanzen aus testen.

Da Sie sowohl Sticky Sessions als auch Lastenausgleich implementieren, ip_hashliegt die Wahrscheinlichkeit bei 50 %, dass zwei Geräte vom selben Pod bedient werden, und selbst wenn Sie die Seite neu laden, wird sie immer vom selben Pod bedient, bis Sie die IP ändern.

Bei IP-Hash wird die IP-Adresse des Clients als Hash-Schlüssel verwendet, um zu bestimmen, welcher Server in einer Servergruppe für die Anfragen des Clients ausgewählt werden soll. Diese Methode stellt sicher, dass die Anfragen desselben Clients immer an denselben Server weitergeleitet werden, es sei denn, dieser Server ist nicht verfügbar. http://nginx.org/en/docs/http/load_balancing.html