-
Notifications
You must be signed in to change notification settings - Fork 594
Adding weights to service entry endpoints #704
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
Changes from all commits
af1dbba
25639d3
8870dd0
c17ca5f
1609757
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -288,15 +288,15 @@ message ServiceEntry { | |
| // REQUIRED. The hosts associated with the ServiceEntry. Could be a DNS | ||
| // name with wildcard prefix (external services only). DNS names in hosts | ||
| // will be ignored if the application accesses the service over non-HTTP | ||
| // protocols such as mongo/opaque TCP/even HTTPS. In such scenarios, the | ||
| // protocols such as mongo/opaque TCP/HTTPS. In such scenarios, the | ||
| // IP addresses specified in the Addresses field or the port will be used | ||
| // to uniquely identify the destination. | ||
| repeated string hosts = 1; | ||
|
|
||
| // The virtual IP addresses associated with the service. Could be CIDR | ||
| // prefix. For HTTP services, the addresses field will be ignored and | ||
| // the destination will be identified based on the HTTP Host/Authority | ||
| // header. For non-HTTP protocols such as mongo/opaque TCP/even HTTPS, | ||
| // header. For non-HTTP protocols such as mongo/opaque TCP/HTTPS, | ||
| // the hosts will be ignored. If one or more IP addresses are specified, | ||
| // the incoming traffic will be identified as belonging to this service | ||
| // if the destination IP matches the IP/CIDRs specified in the addresses | ||
|
|
@@ -419,6 +419,10 @@ message ServiceEntry { | |
| // (that bridges networks n1 and n2), or the IP associated with a | ||
| // standard service endpoint. | ||
| string locality = 5; | ||
|
|
||
| // The load balancing weight associated with the endpoint. Endpoints | ||
| // with higher weights will receive proportionally higher traffic. | ||
| uint32 weight = 6; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Didn't Envoy just go through a whole exercise in defining multi-dimensional weights for load balancing? Should we use the same here?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And to answer my own question: not yet. They still use a uint32 today, and must be in the range 1-128. We should probably add a comment about the allowed range here.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we can normalize in code across all endpoints in a cluster. No point in asking users to normalize
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't make sense - why would the weight be associated with the ServiceEntry ( the full set of endpoints) ? I think it needs to be part of the endpoint.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Its part of endppint
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, missed the indentation. |
||
| }; | ||
|
|
||
| // One or more endpoints associated with the service. | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work in conjunction with route destination weights? When do you use which?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Route destination weights are for a set of endpoints.. a service version etc. This is within an envoy cluster (i.e. a route destination if you will), where you can have one single service instance receive more traffic than other service instances in the same version.
The weights here are used in the multicluster scenario where you use the ingress gateway address as the endpoint for a host (foo.ns1.global) in the remote cluster. If the service is present in many clusters, then you would have multiple ingrss gateway endpoints here. In such a scenario, we need a way to specify the weight associated with each gateway (proportional to the number of pods of that service in that cluster).