SessionPersistence based on URL

[pierreozoux]

What would you like to be added:

In GEP 1619 - Session Persistence via BackendLBPolicy, 3 ways to achieve session persistence are discussed:

• cookie
• header
• url encoded

But in the GEP, only cookie and header are in the spec.

I'd like to also have url encoded session persistence in the spec.

Why this is needed:

Use case / Problem space:

My use case is that I'm coming from ingress-nginx, and I use this annotation upstream-hash-by in different places:

nginx.ingress.kubernetes.io/upstream-hash-by: $arg_room
nginx.ingress.kubernetes.io/upstream-hash-by: $request_uri
nginx.ingress.kubernetes.io/upstream-hash-by: $arg_WOPISrc

Usually, it is a collaboration server where the collaboration on a document happens in one pod, and you want to direct traffic there based on the docId so that users can collaborate on this document on this server. (Or could be a visio room, you get the idea.)

Alternative solutions considered:

• nginx in front of the servers, but somehow this would be a kind of small nginx-ingress just for that logic
• have an Application LoadBalancer that would be aware of "documents" and "servers" and keep the mapping somehow, and set a cookie in the response so that next request can be directed with session persistence

(So it would be easier if that would be implemented in the kubernetes gateway api spec!)

Already existing implementations:

I didn't find any in cilium nor kgateway (nor open issues to direct to).

Historic Istio seems to have something:
https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB

Envoy Gateway just merged one implementation:
https://github.com/envoyproxy/gateway/pull/7428/files

[howardjohn]

One thing to note is there are two very related but distinct things in this space. One is to take an ~arbitrary parameter from the request and hash it to pick a semi-stable destination. It's semi-stable since as backends are added and removed it can be shuffled (generally there are "consistent hashing" algorithms such that shuffling is reduced, but not removed). The gep calls this "affinity"

Then there is full session persistence where there is a deterministic mapping from the session identifier in the request. The gep calls this "persistence".

I believe what you are looking for is actually session affinity based on URL, not session persistence. Is that accurate?

[pierreozoux]

I read the GEP and the distinction between affinity and persistence.

I will not pretend to be an expert in this area.

Let's say that in the request URL there is a param: docId.
We want that requests that have the same param, end in the same backend.
Currently we use nginx.ingress.kubernetes.io/upstream-hash-by and I'm 99% confident that it works the way we want.
(But yeah, thinking a bit more, I'm wondering about the edge cases, server starting, server shutting down, maybe this architecture is flawed in these edge cases, and we would be better off having a proper application aware loadbalancer.
But also, maybe this is good enough, and in case of errors, the client can recover, and it is fine!)

(I could give you real world examples of applications, some with application aware loadbalancer and some without).

That said, I think this use case requires persistence, not just affinity.

But I would also understand that you'd say that this is not the best architecture for this usecase, and that for what I describe the proper way would be an application aware loadbalancer.

[howardjohn]

upstream-hash-by is affinity, not persistence. It will take /?docID=blah, do hash(blah) % len(backends) to get the backend (more or less, its more complex in practice). If the backends change, so does the selected backend.

I struggle to see how you could do persistence with docID like you said. Generally how session persistence works is the server itself returns a value to the client, and the client is expected to return it in subsequent requests (hence why cookies are often used).

So you could have a flow like...

> GET /?docID=blah

< 200 OK
< session-id: abc123

> GET /?docID=blah&session-id=abc123

But I don't see how you could otherwise do persistence on docID.

[pierreozoux]

To be more specific, we use it for these software:

• https://tiptap.dev/docs/hocuspocus/guides/scalability
• https://github.com/ONLYOFFICE/Kubernetes-Docs-Shards/blob/8a6faab1b87a3bda38f70584a3ef594639922c99/values.yaml#L1593
• https://sdk.collaboraonline.com/docs/installation/Proxy_settings.html#example-with-nginx

These are 3 software where users need to meet on the same backend based on a docId in the URL in order to be able to collaborate.

If it is affinity (and not persistence), I trust you and let you change the title to better reflect the idea.

Thanks for your help!

[howardjohn]

Gotcha, thanks for the additional insights. Yeah this is definitely "affinity" with the language in the GEP. but overall the goal makes sense