New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cluster-level hash policy for sticky routing #23060
Comments
Yeah, there is support in the If not, I think the idea of having some cluster-wide control might have merit, but is a deeper discussion that would require @envoyproxy/api-shepherds and @mattklein123 to weigh in. |
@htuch Thanks for chiming in. There was a similar request for mirroring traffic. |
Yeah, there are others, e.g. fault injection. One thing I can offer here is a workaround - you can loopback the ext_authz cluster through a listener bound to localhost and have that apply a standard route table before hitting the real backend cluster. This is a total kludge, but if it helps your use case it might be worth considering. I think we should leave this issue open to gauge wider interest. The API design here would require some careful thought. |
Thanks, @htuch! That's exactly what we are doing right now for mirroring & splitting the traffic :) One more question if you know the answer on top of your head - If we have |
In both cases Envoy is using an independent per-cluster HTTP async client with its own pseudo-config, so I strongly suspect the answer is it will ignore the original route hash policy. |
Description
Currently, the hashing policy is defined on the per-route basis [Link] using
hash_policy
.We have a use-case where we want to do sticky routing for all the incoming traffic for the external ExtAuthZ and RateLimit services but, there is no good way to achieve it.
We can benefit a lot from a consistent hash Load Balancing like Ring Hash and Maglev by hashing on one of the HTTP headers to achieve consistent hashing and leverage the in-memory cache we have per-replica in these upstream services.
Is it possible to support LB hashing policy on the cluster-level (for all the routes)?
The text was updated successfully, but these errors were encountered: