Add service_protocol field to Sidecar API #3452
Conversation
Signed-off-by: William <[email protected]>
|
😊 Welcome @wtzhang23! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
the
size/XS
|
Hi @wtzhang23. Thanks for your PR. I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
istio-testing
added
the
needs-rebase
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
| @@ -466,6 +466,10 @@ message IstioIngressListener { | |||
| // sidecar for requests originating from outside the mesh. | |||
| // Currently supports only SIMPLE and MUTUAL TLS modes. | |||
| ServerTLSSettings tls = 7; | |||
| // The protocol to use when proxying traffic to the service. This is useful | |||
| // when the incoming connection's protocol differs from the service, such as | |||
| // when `tls` is set. | |||
There was a problem hiding this comment.
Not sure I understand the comment. Usually service protocol is FTP or SMTP.
There was a problem hiding this comment.
Ya, I think the wording is improper. By saying "protocol" I'm coupling the transport (plaintext/TLS) and the application protocol (HTTP1/2), which as far as I can tell is the only reason why this field is desirable. This PR was proposed simply to address the case:
port protocol: HTTPS -> service protocol: HTTP. Maybe it is clearer if I just delete the second sentence?
|
How about using 'http_version' - if all you want to identify is the
version of http to use ?
My concern is with the field name - 'service protocol' can have many
meanings, there are many protocols that support proxy and even
'service' is
an overloaded term ( there are non http services - and k8s/Istio
'services' that implement their own protocols like WebDAV over http ).
HTTP/2 is not quite a different application protocol - just a
different version of the http protocol with different encoding.
Would also help a lot to include some examples of the naming used in
other APIs/servers.
No concern with the feature, seems a good thing - just naming and docs.
…On Fri, May 2, 2025 at 7:49 AM William T Zhang ***@***.***> wrote:
@wtzhang23 commented on this pull request.
________________________________
In networking/v1alpha3/sidecar.proto:
> @@ -466,6 +466,10 @@ message IstioIngressListener {
// sidecar for requests originating from outside the mesh.
// Currently supports only SIMPLE and MUTUAL TLS modes.
ServerTLSSettings tls = 7;
+ // The protocol to use when proxying traffic to the service. This is useful
+ // when the incoming connection's protocol differs from the service, such as
+ // when `tls` is set.
Ya, I think the wording is improper. By saying "protocol" I'm coupling the transport (plaintext/TLS) and the application protocol (HTTP1/2), which as far as I can tell is the only reason why this field is desirable. This PR was proposed simply to address the case:
port protocol: HTTPS -> service protocol: HTTP. Maybe it is clearer if I just delete the second sentence?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because your review was requested.Message ID: ***@***.***>
|
Istio supports Ingress Sidecar Termination, which allows configuring sidecars to terminate using certs provisioned elsewhere given that the
ENABLE_TLS_ON_SIDECAR_INGRESSfeature flag is set to true. This helps new users of Istio take advantage of Istio features such as inbound stats collection and injected EnvoyFilters while migrating their infrastructure stacks over the span of multiple years. Note that migration cannot be accelerated as it requires onboarding every client, and we have many services that have a high fan-in count (e.g. configuration services, facades over user databases).However, the current implementation only supports passing traffic to the service over HTTP/1.1. As gRPC and other HTTP2-based protocols gain popularity, this means that users cannot use this feature out-of-the-box. EnvoyFilters can be used to patch this.
This PR proposes an ergonomic change which allows specifying the
service_protocolthat differs from the protocol specified in the sidecar port. The following changes (original closed PR) show how this would be implemented:service_protocolto be either http or http2service_protocolto be a TCP protocol (e.g. Redis)