Add support for registering Pod IPs

[linki]

Triggered by #187 @hjacobs came up with the idea of a PodSource instead of scraping Services for Endpoints.

One could annotate a Pod (or more likely, a PodSpec in a Deployment) with a desired hostname or a fqdn-template.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    metadata:
      annotations:
        external-dns.alpha.kubernetes.io: foo.example.org
    spec:
      ...

ExternalDNS could find them and add their Pod IPs to the DNS provider. In this case three A records pointing to the three pods.

Why not use Headless Services?

• Add DNS entry for Endpoint IP (if not using type loadbalancer) #187 (comment)

[tamalsaha]

@linki, any plans on supporting this or Headless service? Without either of these, folks on bare metal cluster can't really use external-dns.

[hjacobs]

I think this is a duplicate of #315 and might be closed?

[alfredkrohmer]

@hjacobs If I understand this correctly, the #315 is doing something else.

Right now there are two possibilities:

• headless service with pods that have their hostname set (e.g. StatefulSet); when you set the hostname annotation on the corresponding service to foo.bar, external-dns will create records pod-1.foo.bar, pod-2.foo.bar, etc.
• headless service with pods that do not have their hostname set (e.g. Deployment); when you set the hostname annotation on the corresponding service to foo.bar, external-dns will create one record foo.bar, which points to all the pods in the deployment (at least since Support A record for multile IPs for a headless services. #645 was merged, before it was only one pod)

I think what OP wants (and what we would need as well) is:

• no service necessary; when you set the hostname annotation on the pod itself to foo.bar, external-dns will create one record per pod, e.g. pod-d139d9ad-29a9s.foo.bar, pod-d139d9ad-xs023.foo.bar, etc. that point to the corresponding pod IPs.
• bonus points: add a custom pod condition that only becomes ready once the DNS records has been created (e.g. in Route53, when the zone update has propagated)

We currently would need that because we are terminating TLS in the pods, so we need a valid hostname on the pod itself.

[kevincox]

I was interpreting this differently. I want to register the IP of all pods in DNS so that the client will connect to one of the pods. Basically a poor man's load balancing. So if I have pods on 10.0.0.{1,2,3} I would want three A records for the hostname I have set for the pod.

[alfredkrohmer]

But this is already working?

[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.