Gateway v1alpha2 Implementation Feedback

[jpeach]

Now that v1alpha2 has been released and a number of projects have implemented the API, let's collect feedback on their experience. Any and all feedback is really valuable!

Some suggestions

• parts of the API that were ambiguous
• behaviors that were hard to implement in a particular proxy
• assumptions that were necessary but not described in the API

[Jeff-Apple]

Here are some of the issues we have encountered. I think we have a few more but our lead engineer is on vacation. I'll see if has has anything to add.

GatewayClass

• Status => Listeners => Conflicted =>
  • RouteConflict:
    • Didn’t use due to the spec's confusion between when to accept a route or not. We choose not to accept routes that don't match whatever routing support the listener has.
• Status => Listeners => Detached
  • PortUnavailable:
    • Unused, as the only time a port will be unavailable is if we can't schedule the Gateway due to host port binding, which will result in a gateway Schedule status of NoResources
  • UnsupportedExtension:
    • Unused, not sure what the spec is referring to by "extensions" for listeners
• Status => Listeners => ResolvedRefs
  • RefNotPermitted:
    • This is unclear from the spec, talks about setting RefNotPermitted on the route in one place, and on the listener in another -- pretty sure it shouldn't be on the listener

[evankanderson]

Not sure if this is still open, but I've started working on getting the Contour Gateway implementation passing the Knative Ingress conformance tests. We may be a little bit more picky than some, but we have the following setup with Contour and Istio currently:

1. A single wildcard DNS entry pointing at a single pool of envoy pods
2. A wild-card Listener on the Gateway corresponding to that pool of pods
3. Add a Listener to the same Gateway for each HTTPS Route we create, with a NamespaceSelector pointing to the specific namespace the Route is in. (Our Route is backed by an HTTPRoute created in the user's namespace.)

We also create a second (internal) Gateway and pool of envoy pods which uses a ClusterIP (or annotated "internal" load-balancer) for exposing Services which want to be reachable only within the cluster, but which still want tho other benefits of Knative. This means we have two "live" Gateways (potentially of the same gatewayClass), one of which is only visible within the cluster. There's currently no way to request a Spec.Addresses that lives within the cluster; we have work-arounds which manually configure gateways and gatewayclasess to achieve this, but it would be nice to be able to explicitly request an internal-only Gateway.

I'll be opening specific discussions on these, and I'll link them here.