Evaluate K8S Gateway API to model sidecar behavior

[louiscryan]

Describe the feature request
Kubernetes is working on a new API proposal to evolve the state of ingress into the cluster ...

https://docs.google.com/presentation/d/1s0scrQCCFLJMVjjGXGQHoV6_4OIZkaIGjwj4wpUUJ7M/edit#slide=id.g78ea0eff1a_0_80

details ...

https://docs.google.com/document/d/1BxYbDovMwnEqe8lj8JwHo8YxHAt3oC7ezhlFsG_tyag/edit#heading=h.gs76b1pp1evi

Istio will support this API just as we have for the current Ingress API. Looking at the API and comparing it with the Sidecar API it might be possible to use it to model that scenario as well. Doing so would have obvious benefits to users in terms of the universe of APIs they need to understand.

Some important points in that design that seem relevant:

• The definition of 'classes' is quite powerful and allows for implementation & default variation within the concrete API more easily. Might have applications for versioning in addition to behavior defaults.
• Gateway has a polymorphic reference to 'routes'. This seems like it could accommodate references to the types in the docs as well as VirtualService and Service/ServiceEntry. This is important for egress.
• The spec has adopted a model for 'extensions' that can be defined in-line contextual to elements in the API. The examples in the doc show extension of listeners. Could be used to support a wildcard ingress
• The use of 'endpoint' in the spec might not be general enough to handle capture for things like

Strawman for discussion:

• Define a Gateway class as ~ 'istio/sidecar'
• Can model scoped egress to services as Gateway -- [ref] --> Service / Service Entry. Other reference types could be useful here beyond the ones called out in the spec. E.g. a name matching rule against sets of services.
• To model a restrictive ingress either use an extension to reference the local backend (no need to use a resource ref for a route given context) or make a route type (a little verbose probably).

An alternative would be to expand the Istio Sidecar resource to support referencing XXXRoute types just as we would extend the Istio Gateway resource for the same. This would share the routing API model with K8S even if Sidecar was kept as a specialization in Istio.

Describe alternatives you've considered

Status quo

[X] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience

Additional context

[hzxuzhonghu]

/cc