Kubernetes Session Affinity: Sticky Sessions im Service – einfach erklärt

Kubernetes Session Affinity (auch Session-Affinität oder Sticky Sessions) sorgt dafür, dass ein Service alle Verbindungen von derselben Quell-IP an denselben Pod schickt. Ohne Affinität verteilt der Service jede neue Verbindung über alle bereiten Pods. Mit ClientIP-Affinität bleibt ein Client für eine Weile „kleben“ – wichtig für Anwendungen, die Sitzungsdaten im Speicher des Pods halten.

So aktivierst du Session Affinity

Das Feld sessionAffinity unter spec eines Service kennt zwei Werte: None (Standard, keine Klebrigkeit) und ClientIP. Zusätzlich legt sessionAffinityConfig.clientIP.timeoutSeconds fest, wie lange die Zuordnung gilt – der Standardwert ist 10800 Sekunden (3 Stunden).

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800
  ports:
    - port: 80

Wie kube-proxy das umsetzt

kube-proxy programmiert die Weiterleitungsregeln auf jedem Knoten. Bei aktivierter Affinität merkt er sich die Zuordnung Quell-IP → Pod-IP und nutzt sie, bis der Timeout abläuft oder der Pod verschwindet. Die Ziel-IPs stammen dabei aus den EndpointSlices des Services.

Grenzen

  • Auf Service-Ebene gibt es nur die Client-IP als Kriterium – Cookies oder Nutzer-IDs kennt der Service nicht.
  • Steht vor dem Cluster ein Load Balancer, kann dieser die Client-IP maskieren; dann sieht kube-proxy nur die LB-IP und alle Clients kleben am selben Pod. Mit externalTrafficPolicy: Local bleibt die echte Quell-IP erhalten.
  • Stirbt der Pod, verliert der Client seinen Sitzungspartner – die Affinität schützt nicht vor Pod-Ausfällen.

Wer Stickiness auf HTTP-Ebene mit Cookies möchte, nutzt die Affinitäts-Annotationen des Ingress-Controllers – welcher Controller zuständig ist, bestimmt die IngressClass.

Verwandte Grundlagen: Kubernetes Service, Pod, EndpointSlice, Ingress.