fix: pin consistent-hash clients across weighted backendRefs - #9629
Open
guanchzhou wants to merge 1 commit into
Open
fix: pin consistent-hash clients across weighted backendRefs#9629guanchzhou wants to merge 1 commit into
guanchzhou wants to merge 1 commit into
Conversation
When a route splits traffic across multiple weighted backendRefs and uses a ConsistentHash load balancer, Envoy Gateway rendered the split as a weighted_clusters route action whose cluster selection is random per request. The route hash policy only pinned endpoint selection within a cluster, so a client was not pinned to a single backend across the split. Set WeightedCluster.use_hash_policy on the generated weighted clusters when a hash policy is present, so Envoy selects the weighted cluster deterministically from the request's hash policy instead of at random. Gated on a hash policy being configured, so non-ConsistentHash weighted routes are unaffected. Fixes envoyproxy#9626 Signed-off-by: Andrey Maltsev <maltsev.andrey@gmail.com>
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9629 +/- ##
==========================================
+ Coverage 76.04% 76.06% +0.02%
==========================================
Files 259 259
Lines 43275 43278 +3
==========================================
+ Hits 32907 32919 +12
+ Misses 8178 8170 -8
+ Partials 2190 2189 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Makes
ConsistentHashload balancing pin a client to a single backend when a route splits traffic across multiple weightedbackendRefs.Problem
When a route has more than one weighted backend that needs a cluster-per-setting (e.g. per-
backendReffilters, mixed endpoint types, weighted zones), Envoy Gateway renders the split as aweighted_clustersroute action. The cluster selection among those weighted clusters is random per request. A route-levelhash_policy(built from aConsistentHashload balancer) only makes endpoint selection sticky within the chosen cluster — it does not govern which weighted cluster is picked. So with a canary/primary-backup split, a client can land on backend A for one request and backend B for the next, defeating consistent hashing.Envoy exposes
WeightedCluster.use_hash_policy: "If set, the router will use the request's hash policy to select the cluster." Envoy Gateway never set it.Fixes #9626.
Change
In
buildXdsRoute, after the routehash_policyis built, setuse_hash_policyon the weighted clusters when the route action is aweighted_clustersaction and a hash policy is present:Gated on a hash policy being present, so weighted routes without a
ConsistentHashload balancer are unaffected (their cluster selection stays random-by-weight, as before).Testing
http-route-weighted-backend-consistent-hash— a weighted split across two backends (cluster-per-setting via per-backend filters) with a header-basedConsistentHashLB. The generated route now carriesuseHashPolicy: truealongside thehashPolicy.http-route-weighted-zonesgolden updated: only the route that has both aConsistentHashLB and weighted clusters gainsuseHashPolicy: true; weighted routes without a hash policy are untouched — demonstrating the gating.