Support hostnames in K8S Gateway

[costinm]

What would you like to be added:

Use hostnames from the Gateway CR.

Why is this needed:

Current API supports using hostnames in HttpRoute - however users who want more security would define them in Gateway and specify allowRoutes - with the namespace where the Gateway is defined having stricter RBAC.

It's a relatively small change.

[abursavich]

External-DNS has always respected Gateway Listener Hostname and AllowedRoutes. Do you have a case where this isn't working?

https://github.com/kubernetes-sigs/external-dns/blob/v0.14.2/source/gateway.go#L328-L358

[gcs278]

@costinm Are you asking to use the Gateway CR as an External DNS source?

@abursavich do you know if that ever been requested yet or discussed? I'm curious about the situation in which hostnames are specified on the Gateway Listener, but not in the xRoute. I don't believe External DNS has a way to create records using the Gateway CR, but it's a valid GWAPI configuration.

Gateway Listener Merging, currently being discussed in kubernetes-sigs/gateway-api#3213, may have some implications for using Gateways Listener as a source.

[abursavich]

According to the GW-API spec, hostnames are essentially the intersection or overlap of those allowed by the Route and those allowed by the Listener. I believe this is what is being requested, but this is what the External DNS implementation has always done.

[costinm]

Last time I checked, defining the hostname in Gateway CR and not in route didn't work.

If gateway owner created the Gateway object and no route is present - I think DNS should still reflect the name. The routes may come and go as apps are deployed - for example certmanager may create a route to solve the challenge, remove it after. And once the user has certs they may deploy apps including HttpRoutes that attach to the internet gateway without knowing the hostname.

AFAIK routes don't need to include the hostname.

[abursavich]

I see what you mean. The implementation does require the combination of Gateway Listeners and Routes. It won't use a Gateway without a Route.

I still think it's reasonable to be serving a domain (with a Gateway Listener and Route) before creating a record for it. The intent is very clear at that point. Otherwise we're making assumptions that may not be true.

As a concrete example, I wouldn't want to create wildcard records just because a Gateway Listener includes some wildcard (e.g. *.foo.com). It might be the Gateway creator's intent to allow users to create specific routes (e.g. bar.foo.com), but they may not actually want a wildcard record. If they add a matching wildcard Route, then we create the wildcard record.

[Miciah]

As a concrete example, I wouldn't want to create wildcard records just because a Gateway Listener includes some wildcard (e.g. *.foo.com).

I'm actually interested in exactly this. In my situation, the gateway represents a proxy with an associated domain and load-balancer. As the gateway owner, I want a wildcard DNS record for that domain, pointing to that proxy/load-balancer. Route owners can attach routes with host names that fall under the domain name. As a gateway owner, I want a single wildcard DNS record for the gateway itself, not a DNS record for each route.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.