Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion networking/v1alpha3/gateway.pb.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

3 changes: 2 additions & 1 deletion networking/v1alpha3/gateway.proto
Original file line number Diff line number Diff line change
Expand Up @@ -339,7 +339,8 @@ message Port {

// REQUIRED: The protocol exposed on the port.
// MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TLS.
// TLS is used to indicate secure connections to non HTTP services.
// TLS implies the connection will be routed based on the SNI header to
// the destination without terminating the TLS connection.
string protocol = 2;

// Label assigned to the port.
Expand Down
16 changes: 13 additions & 3 deletions networking/v1alpha3/istio.networking.v1alpha3.pb.html
Original file line number Diff line number Diff line change
Expand Up @@ -2360,7 +2360,8 @@ <h2 id="Port">Port</h2>
<td>
<p>REQUIRED: The protocol exposed on the port.
MUST BE one of HTTP|HTTPS|GRPC|HTTP2|MONGO|TCP|TLS.
TLS is used to indicate secure connections to non HTTP services.</p>
TLS implies the connection will be routed based on the SNI header to
the destination without terminating the TLS connection.</p>

</td>
</tr>
Expand Down Expand Up @@ -3020,7 +3021,7 @@ <h2 id="ServiceEntry">ServiceEntry</h2>
<p>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.</p>

Expand All @@ -3033,7 +3034,7 @@ <h2 id="ServiceEntry">ServiceEntry</h2>
<p>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
Expand Down Expand Up @@ -3168,6 +3169,15 @@ <h2 id="ServiceEntry-Endpoint">ServiceEntry.Endpoint</h2>
(that bridges networks n1 and n2), or the IP associated with a
standard service endpoint.</p>

</td>
</tr>
<tr id="ServiceEntry-Endpoint-weight">
<td><code>weight</code></td>
<td><code>uint32</code></td>
<td>
<p>The load balancing weight associated with the endpoint. Endpoints
with higher weights will receive proportionally higher traffic.</p>

</td>
</tr>
</tbody>
Expand Down
104 changes: 71 additions & 33 deletions networking/v1alpha3/service_entry.pb.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 6 additions & 2 deletions networking/v1alpha3/service_entry.proto
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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;
Copy link
Contributor

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?

Copy link
Member Author

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).

Copy link
Contributor

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The 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

Copy link
Contributor

Choose a reason for hiding this comment

The 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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its part of endppint

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, missed the indentation.
/lgtm

};

// One or more endpoints associated with the service.
Expand Down
29 changes: 18 additions & 11 deletions python/istio_api/networking/v1alpha3/service_entry_pb2.py

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.