Support the Istio Service Mesh GW API Implementation

[conradhanson]

Today the gateway api plugin only supports *Routes with backendRefs of type k8s Service. This is a significant limitation for those leveraging Istio and wanting to perform canary deployment strategies on other backend types that Istio supports in their Gateway API implementation.

We should add support for Istio's implementation of the Gateway API specification for other backendRef types. More specifically, Istio's Gateway API implementation supports the following backendRef types:

1. k8s service
2. networking.istio.io/Hostname - specific to hostnames defined in istio ServiceEntry CRs
3. multicluster.x-k8s.io/ServiceImport
4. sigs.k8s.io/gateway-api-inference-extension/InferencePool

Each of these backendRef types are supported by Istio for use in HTTPRoute, GRPCRoute, TLSRoute, and TCPRoute.

Additional Context:

• supporting this is pretty critical for users currently using Argo Rollouts with its first-class support of Istio's VirtualService and DestinationRule subset, and who want to migrate to the k8s Gateway API.

[kostis-codefresh]

While I understand the need, I am not sure how it would actually work in practice.

The plugin only implements a very basic interface as offered from the Argo Rollouts core controller. The assumption that it works with services is deep into the code from the "canaryService" and "stableService" parameters to the assumption of the controller that a deployment works with pod hashes.

The one exception is the Istio DestinationRule support of the controller, but this is already implemented in the istio specific code in the controller and does things a bit differently than the rest of the traffic providers.

So, how exactly can the plugin work with the Istio-specific implementations while still being a generic gateway API plugin?

Because if you are asking for the plugin to start including Istio-specific code, I am not sure this is the correct direction.

Either the existing Istio support in the main controller must be extended in some way, or a brand new Istio specific plugin must be created.

[zachaller]

Yea I would probably go with a new plugin, I could see a spec explosion quit quickly with a bunch of istio specific config and behavior.