Help Center/ Cloud Container Engine/ User Guide (Kuala Lumpur Region)/ Best Practices/ Networking/ Implementing Sticky Session Through Load Balancing
Updated on 2024-07-27 GMT+08:00

Implementing Sticky Session Through Load Balancing

Concepts

Sticky sessions ensure continuity and consistency when you access applications. If a load balancer is deployed between a client and backend servers, connections may be forwarded to different servers for processing. Sticky sessions can resolve this issue. After sticky session is enabled, requests from the same client will be continuously distributed to the same backend server through load balancing.

For example, in most online systems that require user identity authentication, a user needs to interact with the server for multiple times to complete a session. These interactions require continuity. If sticky session is not configured, the load balancer may allocate certain requests to different backend servers. Since user identity has not been authenticated on other backend servers, interaction exceptions such as a user login failure may occur.

Therefore, select a proper sticky session type based on the application environment.

Table 1 Sticky session types

OSI Layer

Listener Protocol and Networking

Sticky Session Type

Stickiness Duration

Scenarios Where Sticky Sessions Become Invalid

Layer 4

TCP- or UDP-compliant Services

Source IP address: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hashing key, and all backend servers are numbered. The system allocates the client to a particular server based on the generated key. This allows requests from the same IP address are forwarded to the same backend server.

  • Default: 20 minutes
  • Maximum: 60 minutes
  • Range: 1 minute to 60 minutes
  • Source IP addresses of the clients have changed.
  • Requests from the clients exceed the session stickiness duration.

Layer 7

HTTP- or HTTPS-compliant ingresses

  • Load balancer cookie: The load balancer generates a cookie after receiving a request from the client. All subsequent requests with the cookie will be routed to the same backend server.
  • Application cookie: The application deployed on the backend server generates a cookie after receiving the first request from the client. All subsequent requests with the same cookie will be routed to the same backend server.
  • Default: 20 minutes
  • Maximum: 1440 minutes
  • Range: 1 minute to 1440 minutes
  • If requests sent by the clients do not contain a cookie, sticky sessions will not take effect.
  • Requests from the clients exceed the session stickiness duration.

When creating a load balancer, configure sticky sessions by setting kubernetes.io/elb.lb-algorithm to ROUND_ROBIN or kubernetes.io/elb.lb-algorithm to LEAST_CONNECTIONS. If you set kubernetes.io/elb.lb-algorithm is to SOURCE_IP, source IP address-based sticky sessions are supported. In this case, you do not need to configure sticky sessions again.

Layer 4 Sticky Sessions for Services

In Layer 4 mode, source IP address-based sticky sessions can be enabled, where hash routing is performed based on the client IP address.

Layer 7 Sticky Sessions for Ingresses

In Layer 7 mode, sticky sessions can be enabled using HTTP cookies or application cookies.