External-dns: NodePort production readiness

[tbarrella]

Intended support for NodePort Services seems unclear. Some example issues are

• All nodes are considered, causing DNS queries to become slow above ~100 nodes
• Nodes are used as targets before the node is ready for the first time and after a node is drained
• In terms of design, it's unclear whether a node that's not ready should be considered as a target
• Private IPs can't be reached in a cluster with public nodes (#939, #1207)
• SRV records were initially implemented but are broken (#936)

Is there a shared understanding about what features ExternalDNS wants to support for NodePort? Are other people interested in having and/or implementing them? Based on comments on some existing PRs (#898, #916), it seems like people might be, although I'm reluctant to try to make changes since those PRs became stale. Is the stance that NodePort isn't meant to be supported?

[adampl]

You can add #1232 to the list. Definitely, NodePort should be supported.

It's the best way to expose services on bare-metal (non-cloud) clusters, as they don't have built-in load balancers, and in many cases _MetalLB_ is not an option.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[atamgp]

+1

[atamgp]

documentation: "An initial effort to support type NodePort was started as of May 2018 and it is in progress at the time of writing."
No other information is given on NodePort support. See also my comment (goal with NodePort) here.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rocketraman]

Adding https://github.com/kubernetes-sigs/external-dns/issues/1489 to the list.

[rocketraman]

For others wanting this functionality and are on GKE/Cloud DNS, I've created a simple bash script that can be deployed as a Deployment/Pod in a GKE environment:

https://gist.github.com/rocketraman/3f3f3925be3a346336a405e2a5d48df0

It will keep a DNS entry "nodes", in the configured zone, up-to-date with the IPs of the Ready nodes, and create and keep up-to-date CNAME records pointing to that DNS entry for every NodePort service registered in GKE:

It uses a simplified form of record ownership via TXT records, just like external-dns.

It can be run with the same service principal used for external-dns.

It's lightly tested for me at this point, but its a small easily debuggable bash script and does the job until the external DNS project supports this capability.

[seanmalloy]

/remove-lifecycle stale
/kind feature

[stefanlasiewski]

If NodePort is supported, then this is simply a documentation bug. We just need to fix places like https://github.com/kubernetes-sigs/external-dns/blob/747e362711d4ac7ffb65849fe0152e20914b21e3/docs/faq.md#which-kubernetes-objects-are-supported

Services exposed via type=LoadBalancer, type=ExternalName and for the hostnames defined in Ingress objects as well as headless hostPort services. An initial effort to support type NodePort was started as of May 2018 and it is in progress at the time of writing.

[oxr463]

If NodePort is supported, then this is simply a documentation bug. We just need to fix places like https://github.com/kubernetes-sigs/external-dns/blob/747e362711d4ac7ffb65849fe0152e20914b21e3/docs/faq.md#which-kubernetes-objects-are-supported

Services exposed via type=LoadBalancer, type=ExternalName and for the hostnames defined in Ingress objects as well as headless hostPort services. An initial effort to support type NodePort was started as of May 2018 and it is in progress at the time of writing.

Judging from the label added to this issue, I am not sure this is the case.

@seanmalloy can we get confirmation on whether NodePort is production ready or not yet?

[seanmalloy]

@seanmalloy can we get confirmation on whether NodePort is production ready or not yet?

@oxr463 I'm not sure. I try to help out with this project, but I'm not an official maintainer. I also haven't looked at the NodePort code much.

[Walther]

It's been a couple of months so I'm hazy on the details, but I believe I got NodePort working with external-dns just fine in a proof-of-concept project using Hetzner Cloud, so this could indeed just be a matter of documentation being out of date

[stefanlasiewski]

Seems like it worked in https://github.com/kubernetes-sigs/external-dns/issues/1263#issuecomment-726437551

[stefanlasiewski]

I'm trying to figure out if the problem I'm running into is happening because I did something wrong, if it's a bug with our Rancher implementation, or if it's a bug of External DNS.

If NodePort is not supported by ExternalDNS yet, then I need to pursue another solution. If it is supported, then I've run into a bug and I need to look at the code more.