External-dns: Feature request: Specifying public vs. private IPs for NodePort targets

[tbarrella]

Hello,

Currently for NodePort services, node IPs in the A record created by ExternalDNS are specified to be

• If there any, public IPs of all nodes that have one
• Otherwise, all node private IPs

While this makes sense as a default, I think it would be really helpful to be able to customize this somehow. For example, in the current scenario,

• I'm not sure of a way to have some services that I only want to route to via private IPs with ExternalDNS on a cluster that also has nodes with public IPs
• In a cluster that currently only contains private nodes, accidentally creating one with a public IP could cause all communication through ExternalDNS-managed addresses to suddenly switch to using the public internet

Would it make sense to have something like an annotation for NodePort services that specifies a node label for restricting node targets, and/or an annotation that specifies whether public or private IPs should be used for the A record?

Sorry if people have already thought about this, or if there are ways around this that I missed

[justinwalz]

I think this addresses part of this issue, however only allows setting public/private globally, not via annotations per object. Issue https://github.com/kubernetes-incubator/external-dns/issues/881, PR https://github.com/kubernetes-incubator/external-dns/pull/898

[tbarrella]

Ah, thank you! Not sure if people want to keep this issue around, but that PR will definitely help me; with that it seems could just use multiple controllers for internal vs. external

[tbarrella]

Actually, having a general way to restrict node targets seems important to use ExternalDNS with NodePort for large/dynamic clusters, more than just for being able to specify public vs. private IPs:

• Frequent node scale downs increase the chance of selecting an invalid node IP address from the A record, so it would be helpful to restrict to nodes that aren't part of an autoscaled group
• AWS API request ChangeResourceRecordSets limits to 1000 resource records per API request, with UPSERT causing each record to count twice. This means means even with --aws-batch-change-size=1, only up to 500 nodes is supported

Would something like a

external-dns.alpha.kubernetes.io/match-labels: '{"key": "value"}'

annotation make sense, for limiting to a subset of nodes? I know it's a big ugly...

I'd be interested in making this change if it seemed acceptable

Edit: Never mind, just found https://github.com/kubernetes-incubator/external-dns/pull/916 which implements this!

[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

[tbarrella]

/remove-lifecycle stale

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.