I have a requirement to route requests to a specific pod in a replica set. The scenario is an HTTP client invokes a Kubernetes service SvcA. SvcA passes back in a header something like the host address of the pod or some other piece of information that can be used later by another client to access that same pod. The issue here is that I want to keep a database session open in SvcA with a local transaction already started. The connection/transaction will remain open until another client calls SvcA with the provided header. I need that second client call to end up on the same SvcA replica that the original request went to. Are there any out of the box solutions to do this? I know about Istio consistent hash, but it isn’t consistent across changes in the number of replicase.
Regards,
Todd
Did you ever figure out how to do this?
Kube Services do not support this (L4 vs L7). We have affinity by client IP, but anything higher than that requires a protocol-aware proxy.
Actually it looks like Session affinity might almost achieve what I’m looking for. My goal is to improve canary testing by ensuring that followup requests from the canary are also sent to the canary pod when possible (and vice versa), so that over time we could see if there is a problem with our canary.
The only problem is that we interact with both 3rd-party servers and browser clients, so client IP affinity won’t associate the browser IP with the same node that we passed. So I’ll keep pondering. Do you have suggestions for a protocol-aware proxy we might be able to use?
(For context, I’m very new to kubernetes and am just learning the ropes.)
I think you want a solution based on Gateway API or Ingress, rather than simple Services. That’s where all the L7 functionality lives, including things like cookie-awareness.
1 Like