external-dns
external-dns copied to clipboard
kubernetes-sigs
Support hostnames in K8S Gateway
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.
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
@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 https://github.com/kubernetes-sigs/gateway-api/pull/3213, may have some implications for using Gateways Listener as a source.
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.
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.
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.