Sticky Session

Sticky session, or session persistence occurs when the load balancer creates a connection between a network and a user for a direction of the session.

Requests for sessions from a client in a sticky session means all requests go to the same machine that received the first request.

Sticky sessions ensure that the connection between the client and the network during a session is not lost as a result of requests being routed to different servers.

However, sticky sessions can cause uneven load distributions across servers.

Kubernetes

Available in: 1.11.x and later

Sticky sessions send subsequent requests from the same client to the same REPLACE-SERVERTYPE by setting a cookie with a configurable name and TTL (Time-To-Live) duration. The TTL parameter defines the duration the cookie remains valid in the client’s browser. This option is useful for application sessions that rely on connecting to the same REPLACE-SERVERTYPE for each request.

• Sticky sessions will route consistently to the same nodes, not pods, so you should avoid having more than one pod per node serving requests.
• Sticky sessions require your service to configure externalTrafficPolicy: Local to preserve the client source IP addresses when forwarding incoming traffic to other nodes.

Use the do-loadbalancer-sticky-sessions-type annotation to explicitly enable (cookies) or disable (none) sticky sessions, otherwise the load balancer defaults to disabling sticky sessions:

    
        
            
metadata:
  name: sticky-session-snippet
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-protocol: "http"
    service.beta.kubernetes.io/do-loadbalancer-sticky-sessions-type: "cookies"
    service.beta.kubernetes.io/do-loadbalancer-sticky-sessions-cookie-name: "example"
    service.beta.kubernetes.io/do-loadbalancer-sticky-sessions-cookie-ttl: "60"

        
    

See a full configuration example for sticky sessions.

Load Balancer

If user sessions depend on the client always connecting to the same backend, you can send a cookie to the client to enable sticky sessions.

Sticky sessions are only visible at the load balancer layer; the cookies used for sticky sessions are both set and stripped at the load balancer. Because those cookies are not present in the request sent to the backend Droplets, backend applications cannot use them.

Sticky sessions send subsequent requests from the same client to the same Droplet by setting a cookie with a configurable name and TTL (Time-To-Live) duration. The TTL parameter defines the duration the cookie remains valid in the client’s browser. This option is useful for application sessions that rely on connecting to the same Droplet for each request.

Sticky sessions do not work with SSL passthrough (port 443 to 443). However, they do work with SSL termination (port 443 to 80) and HTTP requests (port 80 to 80).