catalog: allow root service selector to match backend pods #4303
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4303 +/- ##
==========================================
- Coverage 69.25% 69.22% -0.03%
==========================================
Files 211 211
Lines 14241 14226 -15
==========================================
- Hits 9862 9848 -14
+ Misses 4331 4330 -1
Partials 48 48
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
LGTM. One overall question: how does load balancing work when an apex service's selector matches pods for different backends? e.g. if I have apex service SA splitting between S1 with weight 10 and S2 with weight 90 and a selector on SA matching pods for both services, is that weight defined in the traffic split always honored?
| // of services. An upstream service is associated with another service if it is a backend for an apex/root service | ||
| // in a TrafficSplit config. This function returns a list consisting of the given upstream services and all apex | ||
| // services associated with each of those services. | ||
| func (mc *MeshCatalog) getUpstreamServicesIncludeApex(upstreamServices []service.MeshService) []service.MeshService { |
There was a problem hiding this comment.
Great naming! Crisp and clear!
Thanks for the comment too!
Traffic splitting weights are associated with the backend services and not the pods backing those services. So in the above example, traffic directed to the apex will be split S1(10)-S2(90), where S1 and S2 are clusters in envoy, whose endpoints are the pods backing S1 and S2. Traffic to endpoints of a cluster are load balanced equally. |
Allows root service in a traffic split to have a selector that matches the pods backing the leaf services. This scenario was not tested before. The change updates the inbound policy generation code in a way such that policies are built for each upstream service (including root service), where the upstream service is guaranteed to be unique. Additionally, traffic directed to the root service are routed to a cluster corresponding to the root service and not the leaf service. Resolves openservicemesh#4296 Signed-off-by: Shashank Ram <[email protected]>
Signed-off-by: Shashank Ram <[email protected]>
shashankram
force-pushed
the
fix-split
branch
from
c1b5a33 to
21ed388
Compare
…cemesh#4303) Allows root service in a traffic split to have a selector that matches the pods backing the leaf services. This scenario was not tested before. The change updates the inbound policy generation code in a way such that policies are built for each upstream service (including root service), where the upstream service is guaranteed to be unique. Additionally, traffic directed to the root service are routed to a cluster corresponding to the root service and not the leaf service. Resolves openservicemesh#4296 Signed-off-by: Shashank Ram <[email protected]>
Description:
Allows root service in a traffic split to have a selector
that matches the pods backing the leaf services. This
scenario was not tested before.
The change updates the inbound policy generation code
in a way such that policies are built for each upstream
service (including root service), where the upstream
service is guaranteed to be unique. Additionally,
traffic directed to the root service are routed to
a cluster corresponding to the root service and not
the leaf service.
Resolves #4296
Testing done:
Affected area:
Please answer the following questions with yes/no.
Does this change contain code from or inspired by another project?
noIs this a breaking change?
no