Das passende Training Microservices Training – Architektur, Docker und Kubernetes in 5 Tagen
Sticky Sessions sind ein Architekturproblem. Kubernetes macht es nur sichtbar
Ganz ehrlich: Hol die Session aus dem Pod raus.
Leg den Zustand zentral ab, zum Beispiel in der Datenbank. Dann ist es egal, auf welchem Pod dein Nutzer landet. Damit kriegst du nach meiner Einschätzung rund 95 Prozent aller Sticky Sessions weg.
Ja, ich hör dich schon: „Dafür muss ich an die Anwendung ran!“ Stimmt meistens. Genau da liegt das Problem, nicht im Cluster.
Der Stammkellner
Stell dir ein Restaurant vor, in dem nur dein Kellner deine Bestellung kennt. Die hat er im Kopf, nicht auf dem Bon. Also musst du jedes Mal auf genau ihn warten. Die anderen Kellner haben genug zu tun, aber helfen können sie dir nicht. Sie wissen ja nicht, was du willst.
Genau das ist eine Sticky Session. Klassische Anwendungen merken sich, wer eingeloggt ist, auf dem Server selbst: im Arbeitsspeicher oder in einer lokalen Datei. Deshalb muss jede Anfrage zu genau diesem Server zurück. Mit festen Servern im eigenen Rechenzentrum klebt der Load Balancer den Kunden halt an seinen Server, fertig.
In Kubernetes ist der Server ein Pod. Und Pods sind Wegwerfware. Rolling Update, Node weg, Autoscaler räumt auf: Schon ist der Kellner nach Hause gegangen. Mit deiner Bestellung im Kopf.
Kubernetes hat das Problem also nicht erfunden. Es hat nur das Licht angemacht.
Der Kleber hält, aber er heilt nichts
Klar kannst du dir den alten Kleber in Kubernetes wieder anrühren. Traefik kann das, ein Service mit der passenden Einstellung auch. Für den Umzug? Meinetwegen.
Aber mach dir nix vor: Die Session hängt dann immer noch an einem Pod. Du hast den Stammkellner bloß ins neue Restaurant mitgeschleppt.
| Variante | Woran erkennt der Cluster den Nutzer? | Was passiert, wenn der Pod weg ist? |
|---|---|---|
Service mit sessionAffinity: ClientIP (Kubernetes-Doku) | an der Quell-IP, die beim Service ankommt (hinter NAT oder SNAT oft nicht die des Nutzers), Standard-Timeout 10800 Sekunden (3 Stunden) | Anfrage geht an einen anderen Pod, die Session auf dem alten Pod ist weg |
| Traefik mit Sticky-Cookie (Traefik-Doku) | an einem Cookie im Browser | Traefik leitet an einen gesunden Server weiter und merkt sich den, die Session auf dem alten Pod ist trotzdem weg |
| Zustand zentral, z. B. in der Datenbank | gar nicht nötig | die Session bleibt, der nächste Pod holt sie zentral |
Die ersten beiden Zeilen sorgen bestenfalls dafür, dass du wieder bei deinem Kellner landest. Ist der weg, schickt dir der Laden brav einen anderen. Deine Bestellung kennt der trotzdem nicht.
Warum ich trotzdem auf den Umbau dränge
Weil Kubernetes vor allem nach außen skaliert. Mehr Last? Noch ein Pod daneben.
Ein Kollege baut seine Services genau so. Jeder arbeitet die Anfragen schön der Reihe nach ab. Wird’s eng? Kommt ein zweiter Pod dazu. Ich hab’s mal andersrum gemacht. Eine API mit mehreren Threads gleichzeitig, den Speicher pro Thread falsch eingeschätzt. Ergebnis: Speichergrenze erreicht, der OOM-Killer hat aufgeräumt. Punkt für den Kollegen.
Sein Rezept hat nur einen Haken, den keiner laut sagt. Der zweite Pod nützt nur was, wenn es egal ist, welcher Pod antwortet. Mit Sticky Sessions ist es nicht egal. Der neue Kellner kriegt nur die Gäste ab, die neu reinkommen. Die Stammgäste bleiben bei ihren alten Kellnern sitzen, auch wenn die längst schwitzen.
Mit zentralem Zustand dagegen schreibt jeder Kellner die Bestellung auf den Bon in der Küche. Egal, wer dir das Essen bringt: Er weiß, was du bestellt hast. Genau das meine ich: Die Anwendung holt sich die Session-Daten von einem zentralen Punkt, und dem Nutzer ist schnuppe, auf welchem Pod er landet.
Wie du so einen Schnitt durch einen gewachsenen Monolithen sauber setzt, üben wir fünf Tage lang in meinem Microservices-Training mit Docker und Kubernetes.
Und die anderen 5 Prozent?
Ich geb’s zu: Einen Kundenfall, bei dem der Umbau gar nicht ging, hatte ich noch nicht. Die 95 Prozent sind meine Einschätzung, keine Statistik. Trotzdem sage ich nicht 100.
Im Einführungstraining erkläre ich das mit der SQL-Normalisierung. Theoretisch kannst du deine Datenbank bis zur vierten Normalform aufräumen, alles schön auseinandergedröselt. Praktisch ist das manchmal nicht performant. Dann bleibt’s eben ein bisschen unordentlich, mit Absicht.
Bei Sessions ist es dasselbe. Zentraler Zustand heißt: Jede Anfrage fragt erst mal in der Küche nach dem Bon. Das ist ein zusätzlicher Weg übers Netz, bei jedem Klick. Meistens merkt das keiner. Manchmal schon.
Meine Regel deshalb: Stickiness darf die Brücke sein, über die du nach Kubernetes umziehst. Wohnen solltest du da nicht. Plan den Umbau gleich mit, sonst schleppst du den Stammkellner noch Jahre mit dir rum.