Codecov Report

Attention: Patch coverage is 89.65517% with 12 lines in your changes missing coverage. Please review.

Project coverage is 65.22%. Comparing base (20371d1) to head (856ad34).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #5299      +/-   ##
==========================================
+ Coverage   65.11%   65.22%   +0.10%     
==========================================
  Files         212      212              
  Lines       33605    33675      +70     
==========================================
+ Hits        21883    21965      +82     
+ Misses      10399    10390       -9     
+ Partials     1323     1320       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@arkodg mind taking a first-pass look? If possible I'd prefer to limit the scope here to enabling zone aware routing with future plans to implement something similar to Istio's locality failover or weighted distribution.

Enabling both would require some more API design and I imagine changes to BackendTrafficPolicy but my current PR will enable zone aware routing usage without breaking or changing existing routing behavior (please correct me there).

Edit: scratch that implementation wasn't too bad

hey hoping we can get #5269 in first to avoid large merge conflicts

Will split the initContainer implementation to a separate PR

/retest

/retest

I'm finding some issues with this breaking weighted backends. @guydc or @arkodg could you have a look please?

From https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/endpoint/v3/endpoint_components.proto#config-endpoint-v3-localitylbendpoints:

load_balancing_weight
([UInt32Value](https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#uint32value)) Optional: Per priority/region/zone/sub_zone weight; at least 1. The load balancing weight for a locality is divided by the sum of the weights of all localities at the same priority level to produce the effective percentage of traffic for the locality. The sum of the weights of all localities at the same priority level must not exceed uint32_t maximal value (4294967295).

Locality weights are only considered when [locality weighted load balancing](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight#arch-overview-load-balancing-locality-weighted-lb) is configured. These weights are ignored otherwise. If no weights are specified when locality weighted load balancing is enabled, the locality is assigned no load.

Which means the current logic of setting locality.LoadBalancingWeight to ds.Weight will be ignored. I then tried also setting each individual endpoint's load balancing weight to ds.Weight which did bring some weighted backend routing back but the conformance tests still fail and it's not clear to me why yet. The backends are receiving close to the desired weights so something it's partially working but something is off.

I also found an open Envoy issue which could be relevant regarding whether zone aware routing respects weights. I'm beginning to read through the loadbalancer code to build a better understanding but would either of you happen to know why zone aware lb config degrades routing for weighted backendRefs on xRoutes?

2025-02-27T04:27:54.5165617Z     httproute-weight.go:72: Traffic distribution test failed (5/10): backend "infra-backend-v1" weighted traffic of 0.64 not within tolerance 0.7 (+/-0.050000)
2025-02-27T04:27:54.5166035Z         backend "infra-backend-v2" weighted traffic of 0.36 not within tolerance 0.3 (+/-0.050000)

/retest

/retest

@jukie as a workaround can you

1. rm
2. touch
3. make testdata
4. commit those changes and push

/retest

/retest

/retest

@jukie is there a flaky? https://github.com/envoyproxy/gateway/actions/runs/13677062142/job/38239825535

need sort to make a stable result?