Simplify Gateway Route Binding

[robscott]

At our last community meeting, we talked about ways we could simplify Gateway Route binding. That was centered around a relatively lengthy doc I'd written covering a few different options. Thanks to some great feedback in that meeting and in the doc, I think we've reached an option that makes a lot of sense. I wanted to raised this as an issue just so we had a bit more visibility on this and could track progress towards v1alpha2.

Here are the key parts of this proposal:

• Expand Gateway selection config in Routes to mirror Route selection config from Gateways.
• Introduce a new from field in both cases with All or Selector options.
• Empty selector does not select anything.
• Default from to All on Gateway (bind to anything by default).
• Default from to Selector on Routes (don't bind to anything by default, selector needs to be specified).
• SameNamespace is default on Gateway and new Routes.

Simple Example

kind: Gateway
metadata:
  name: simple-gateway
  labels:
    gateway: xlb
spec:
  gatewayClassName: acme-lb
  listeners:
  - protocol: HTTP
    port: 80
    routes:
      kind: HTTPRoute
---
kind: HTTPRoute
metadata:
  name: simple-route
  namespace: gateway-api-example-ns2
spec:
  gateways:
    from: Selector
    selector:
      gateway: xlb
  rules:
  - matches:
    - path:
        type: Prefix
        value: /
    forwardTo:
    - serviceName: my-bar-service1
      port: 8080

Multi-Listener Example

kind: Gateway
metadata:
  name: simple-gateway
  labels:
    gateway: xlb
spec:
  gatewayClassName: acme-lb
  listeners:
  - protocol: HTTP
    port: 80
    routes:
      kind: HTTPRoute
      from: Selector
      selector:
        http-gateway: yes
  - protocol: HTTPS
    port: 443
    routes:
      kind: HTTPRoute
      from: Selector
      selector:
        https-gateway: yes
---
kind: HTTPRoute
metadata:
  name: simple-route
  namespace: gateway-api-example-ns2
  labels:
    http-gateway: yes
spec:
  gateways:
    from: Selector
    selector:
      gateway: xlb
  rules:
  - matches:
    - path:
        type: Prefix
        value: /
    forwardTo:
    - serviceName: my-bar-service1
      port: 8080

[howardjohn]

  listeners:
  - protocol: HTTP
    port: 80
    from: Selector
    selector:
      http-gateway: yes
    routes:
      kind: HTTPRoute

Should this instead be:

  listeners:
  - protocol: HTTP
    port: 80
    routes:
      from: Selector
      selector:
        http-gateway: yes
      kind: HTTPRoute

?

[robscott]

@howardjohn thanks for catching that! Updated examples above.

[youngnick]

This looks great! Great flexibility, and the defaults make sense too. Solid +1 from me.

[hbagdi]

To clarify, we now have 4 selectors for the most verbose case:
Gateway listener:

• A selector for namespaces from which routes can be selected
• A selector for the route within the above namespaces which can be selected
  Route's Gateway selector:
• A selector for namespaces in which a Gateway is allowed to bind to this Route
• A selector for Gateways within those namespaces which is allowed to bind to this Route

Can someone verify if this understanding is correct?

[robscott]

Yep, you're completely right, the most verbose case is both very verbose and complex. I think the most common case is quite simple though - Route owners select the Gateway(s) they want to bind to. In many cases, this would be based on labels provided to them by Gateway admins.

I think the more verbose/complex combination you mentioned above would likely only be used by teams where Gateway admins and Route admins were on different teams. In that scenario, Gateway admins would describe where they wanted to accept Routes from, and potentially add different label selection per listener. Route admins would still select Gateways as normal. I agree that this is a pretty complex use case, but I think it's something at least some organizations would find useful.

[hbagdi]

My gut feeling is that the most complex case with 4 selectors at the same time will be rarely used, maybe never. All other cases with a subset of 4 selectors do make a lot of sense and I think they will be used based on the organization design of our users.

With that said, I'd like endorse the proposal.

[howardjohn]

Just want to write out a use case this would not cover - allowing routes to select which listener is applied. It may or may not be something we care about.

For example:

kind: Gateway
listeners:
- port: 80
- port: 90
- port: 100

Currently, a route can only select all or none of the gateway.

A gateway can extend its selector to allow a route to sort of implicitly select itself:

kind: Gateway
listeners:
- port: 80
  routes:
    selector:
      port: 80
- port: 90
- port: 100
---
kind: Route
metadata:
   labels:
     port: 80

But this is not great for a couple of reasons:

• Routes are now "selecting" a gateway in two different ways, sometimes a mix of these two.
• We don't have a way for the gateway to select "port unset or port=80", so this would require the route to specify the port instead of enabling them to restrict it.

[robscott]

@howardjohn That's a good point. Maybe ports are more similar in concept to hostname in that they could be represented with a matcher on Routes. So instead of Gateway binding, this would become more of request matching, even if the end result is nearly identical.

[robscott]

Closing in favor of continuing discussion in #724.

/close

[k8s-ci-robot]

@robscott: Closing this issue.

In response to this:

Closing in favor of continuing discussion in #724.

/close

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/test-infra repository.