How make sticky sessions path based for ALB, when using it in front of EKS

Question

I am using an EKS cluster and direcly in front of it an ALB.

Now, there are many requests of the form https://my-domain.com/some-service/<document_id>, where document_id is varying.

Now, I would like to route traffic in EKS for document_id1 to pod1, for document_id2 to pod2, for document_id3 perhaps again to pod1 etc. In any case, I would like to send traffic for each fixed document_id to just one or at most a few pods in the Kubernetes cluster.

Is that or something similar possible by using sticky sessions for ALB? Or is there an alternative to it?

Answer 1

The scenario you’re describing sounds like you want to achieve session affinity based on a specific path parameter (document_id), which is not the typical use case for sticky sessions. Sticky sessions on an AWS Application Load Balancer (ALB) are typically used to route requests from a specific client to the same target (such as an EC2 instance or a pod in EKS) based on a session cookie. However, this mechanism does not differentiate traffic based on path parameters or URIs; it’s designed to maintain session state for a particular client.

For your use case, where you want to route to a specific pod based on the document_id, you’d need a more sophisticated routing mechanism, such as a service mesh or custom ingress logic that can inspect the path and make routing decisions accordingly.

Here’s an overview of possible approaches:

1. Service Mesh (e.g., Istio, Linkerd, AWS App Mesh):

• Service meshes can provide more advanced traffic routing capabilities, such as routing based on request attributes, including headers and path parameters.

• You can define rules to route traffic to different services or versions of services based on the document_id.

2. Custom Ingress Controller or Reverse Proxy:

• You could deploy a reverse proxy (such as NGINX or HAProxy) within your EKS cluster that has custom routing logic based on the document_id.

• The proxy would inspect the path, extract the document_id, and then route the request to the appropriate service or pod based on your custom rules.

3. Kubernetes Ingress with Rewrite Annotations:

• Some Kubernetes Ingress controllers allow you to specify rewrite annotations that can manipulate the request before it is routed to the appropriate service.

• This won’t provide direct routing to a specific pod based on document_id, but you can use it in combination with other techniques.

4. Pod Affinity and Anti-Affinity:

• While pod affinity and anti-affinity rules don’t provide direct routing, you can use them to control the placement of your pods across nodes in your cluster.

• This could be used to ensure that certain pods are scheduled together or separately based on labels, which could then indirectly influence routing by proximity.

5. Consistent Hashing:

• If you have control over the client or can customize the load balancer logic, you could use consistent hashing based on the document_id to route requests to a specific pod.

• This approach requires that your load balancing layer supports consistent hashing and can be customized based on your requirements.

6. Sticky Sessions (AWS ALB):

• While sticky sessions will not achieve routing based on document_id, they could still be useful if you want to maintain session affinity for a particular client.

• This can be configured in ALB target group attributes by enabling stickiness and setting a duration for the sticky sessions.

to summarise, the most appropriate solution will depend on the specifics of your traffic patterns, your application architecture, and your operational requirements. It’s important to consider the complexity and maintenance overhead of each option. Service meshes, in particular, can provide powerful traffic management features but can also add significant complexity to your infrastructure.