Standard Gateway names and namespaces, other help for Helm chart writers

[youngnick]

Quite a few times when I've been discussing Gateway API with folks, the question of how to make a standard Helm chart that includes a HTTPRoute instead of an Ingress comes up, and I don't have a good answer.

The level of magic in Ingress had the nice property that a Helm chart author could just include an Ingress object, and if there was a default Ingress implementation, everything would just work.

It would be nice to approximate something like that in Gateway API.

My proposal here is that we define a conventional default Gateway that will expose HTTPRoutes attached to it to the internet. Then implementations may choose to include that as part of their install, probably with a flag of some sort to be able to disable it.

Additionally, we provide some guidelines for Helm chart writers as to how to include a HTTPRoute (or other Route type) in their charts (basically, it will need a chart value for parent Gateway name and namespace, which will default to the conventional one).

If we do a conventional default Gateway, I would think it should look like this, to mirror Ingress functionality:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internet # Other options, external, public, or similar.
  namespace: default # The only namespace aside from kube-system that's basically guaranteed to exist
spec:
  gatewayClassName: implementationGWC # Each implementation will need to fill this out
  listeners:  
  - protocol: HTTP
    port: 80
    name: internet-http-gw
    allowedRoutes:
      namespaces:
        from: All

If an implementation does not wish to support this Ingress-style ease-of-use Gateway, then it is free to not supply it. But if supplied, it must at least:

• have at least one listener that can accept HTTPRoutes (only HTTPS is fine as well as only HTTP as above, but will require additional config and TLS certificate generation)
• Accept routes from all namespaces

This would also allow administrators to have a standard place to customize if they wish, or to delete if they want chart installers to have to take definite action to have their services exposed.

At the very least, if we don't want to do something like this, we should record that, and why not, so that implementations don't all end up doing their own things.

[shaneutt]

So just to be clear, you're proposing we provide more samples?

[youngnick]

Not really, I think that we should have a recommended something as a way to handle the "I want my HTTPRoutes in Helm (or similar app-distribution tool), and I want them to just work when installed" usecase.

The above proposal would be a recommendation for a conventional Gateway, nothing more.

[mikemorris]

Bikeshed alternative example Helm chart config?

infra: {
  // If set, will be templated into the `spec.gatewayClassName` field of a Gateway configuration defined by the Helm
  // chart author and used to create a new Gateway resource.
  gatewayClassName *string

  // If set, will be templated into a `ParentReference` in the `spec.parentRefs` field of an HTTPRoute configuration
  // defined by the Helm chart author for configuring to which gateway a route defined in the chart should bind. Can
  // be useful for exposing routes defined in a Helm chart on shared gateway infrastructure. If omitted, the HTTPRoute
  // defined in the chart will default to targeting the Gateway created by the chart from the `className` field.
  gateway: {
    name *string
    namespace *string
    sectionName *string
    port *int
  }
}

[howardjohn]

I am a bit worried about creation of Gateway. simply configuring class is not going to be enough I would think? You need ports, tls stuff, namespace scope, implementation specific things, etc.

[pleshakov]

You need ports, tls stuff, namespace scope, implementation specific things, etc.

is it reasonable to allow some application helm chart to have control over those things?

[pleshakov]

could exposing parentRef parameters of the HTTPRoute(s) of an application helm chart be enough?

[youngnick]

That may be enough, yeah, and that's what I was suggesting here:

Additionally, we provide some guidelines for Helm chart writers as to how to include a HTTPRoute (or other Route type) in their charts (basically, it will need a chart value for parent Gateway name and namespace, which will default to the conventional one).