Support sticky sessions in KEDA HTTP Add-on interceptor

[rodrigoGA]

Proposal

I would like KEDA HTTP Add-on to support sticky sessions / session affinity when routing traffic from the interceptor to the target application pods.

Currently, when using the flow:

Load Balancer → KEDA HTTP interceptor → Application Service → Application Pods

the external load balancer can only apply session affinity to the KEDA interceptor, not to the final application pods. After that, the interceptor forwards traffic to the Kubernetes Service, and requests may be distributed across different pods.

It would be useful to have an option in HTTPScaledObject or InterceptorRoute to configure sticky routing based on a cookie, header, or request attribute.

Example desired configuration:

sessionAffinity:
  enabled: true
  type: cookie
  cookieName: JSESSIONID
  ttl: 60s

The interceptor could use this value to consistently route requests from the same user/session to the same ready endpoint, while still keeping the scale-to-zero behavior.

Use-Case

Some applications require temporary request affinity to ensure consistent request handling, even when running multiple replicas behind a Kubernetes Service.

Supporting sticky sessions in the KEDA HTTP interceptor would enable workloads to combine:

scale-to-zero

• HTTP activation
• multiple application replicas
• session affinity to application pods

This would simplify deployments that need predictable request routing without introducing additional proxies or custom routing logic.

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

[linkvt]

Thanks for the well written feature proposal! I'm always wondering how far we want to go considering reimplementing what actual ingress controllers already do but this makes IMO sense. If someone has a different opinion feel free to discuss 🙂

It does probably depend on issue #1473 which is currently WIP, I just checked today with the author who is working on that issue. Without that PR we would just be sending traffic to the ClusterIP of the Service which would let K8s effectively choose the target pod.

We might also benefit from some conceptual work to see what other ingress controllers consider today, this might also be relevant: https://gateway-api.sigs.k8s.io/geps/gep-1619/

Should I assign this ticket already to you as you were interested in working on this?

[rodrigoGA]

Thanks! To be honest, I’m not familiar with the internal implementation of keda yet.

I need to solve this scale to 0 + session affinity problem relatively soon for a client, so I could probably spend a couple of days trying to work on this feature instead of building a custom workaround in the client infrastructure.

That said, since I don’t know the project internals or the current development/review cycle, it’s hard for me to estimate whether a minimal implementation would be feasible in the short term.

The scope I had in mind would be a minimal best effort session affinity implementation based on cookie/header + consistent hashing, built on top of the direct to pod routing work.

If you think this is a reasonable and feasible direction, feel free to assign the issue to me when you think the direct to pod routing work is ready. I can then take a closer look at the project and start with a short design proposal to confirm the API shape before opening an implementation PR.

[linkvt]

No worries, I think the implementation will probably be a bit difficult as there is much to consider (e.g. it shouldn't be possible for clients to cause out of memory issues), the endpoint stuff also isn't ready yet so I wouldn't base my work on that at least for now.
I would prefer a solid implementation instead of an alpha feature as we're targeting a v1 release and have the time to think this through from a project perspective.

I was mostly asking as you answered the question about implementing this yourself in the issue description with "yes", but it's also fine to leave it open until another contributor or I will pick this up 👍