A sticky session is necessary in order to support load balancing websockets connections. Nginx allows for a sticky cookie to be added to route traffic to the correct server, but there doesn’t seem to be a way to support this with kong. I see there is the option to hash_on IP, but we haven’t been able to get this working, and our consumers for the service with websockets are all behind the same NAT gateway, so we really need to use cookie injection to load balance correctly.
If something like this is already supported, please point me in the right direction, but as stands, this is blocking us from fully integrating with kong.
when the handshake is completed the connection turns into an non-http socket connection. Hence, if the first request (containing the upgrade-request) is properly hashed, then each following request (websocket or not) should end up on the same server as long as the hashing is configured properly. Or stated otherwise, there is no difference in sticky sessions between a regular http request and a websocket from Kong perspective.
To answer the question: we do not currently support that.
First thoughts would be to extend the consistent hashing with the option to hash on a cookie value (besides IP and headers), combined with a plugin that inserts the actual cookie.
Thanks for the reply! I agree with your first thoughts on supporting this use case. I notice there are a couple of community plugins that could provide something closer to this when combined.
the device uid plugin adds a cookie with a uid to the client’s device the cookies-to-headers plugin converts cookies to headers (only for the authorization header, but could be modified to make a sticky header)
We might try some approach of combining these as a workaround.
As for supporting hashing on cookies, is this something you’d be amenable to as a PR to the project, or is further discussion required from the core team? In other words, how can I help to make this dream a reality?
had a quick look at those plugins. I think you can make it work like this:
Update the deviceuid plugin to generate the cookie on incoming requests, and also reinserting the same one on outging (otherwise the first request will not have a cookie yet, and won’t be picked up by the consistent-hashing algorithm)
Update the cookies-to-headers plugin, to make the headername configurable
make sure the priority is set such that deviceuid runs before cookies-to-headers
Thanks for looking at that! We’ll be writing the plugin in the next couple of weeks (or finding some alternative way to fix our websockets while using kong). Will post the results here.
We could alternatively modify the core, and add it as a generic option, if you’re willing to create a PR for that? (and be eligible for the famous Kong contributor t-shirt!)
That would be the ideal solution
Are you thinking of making hash_on: cookie an option, with sticky cookies as a plugin? Or were you considering making sticky sessions an option like the k8s nginx ingress controller does with affinity annotations?
I would definitely be up for working on this. If there’s anything we can do to kick this off, please let me know.
