DNS updates to trigger on changes to selector targets, not only to resource with external-dns annotations

[efitzgerald-atlassian]

What would you like to be added:

Given a headless service that has external-dns annotations, and a selector to determine the target IP address(es) for the DNS record, an update of external-dns should be triggered when there are events for the pods targeted by the selector, if external-dns is using the --events flag.

For example, we have a service defined like:

apiVersion: v1
kind: Service
metadata:
  name: my-dns-service
  namespace: my-namespace
  annotations:
    external-dns.alpha.kubernetes.io/hostname: my-dns-service.example.com
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    example.com/my-label: label-value
  clusterIP: None

This service targets pods that have labels managed elsewhere, such that the DNS record will always point to the pod(s) with the relevant label. As a concrete example, we are using this for Postgres clusters, and in each cluster, there is a pod with a label indicating it is the primary instance of the cluster.

When something happens to the selector target, e.g. the selected pod is killed, the DNS record should update. However, this doesn't currently trigger a DNS update even with the --events flag specified, since the changes (e.g. a pod being killed, label changes) are not occurring on the resource (my-dns-service) that external-dns is watching (i.e. the resource with the external-dns annotations). In our Postgres example, this happens when a failover occurs: another pod that was previously a replica gets promoted and gets the primary label, and we want the DNS record to be updated to point to the new primary pod.

Why is this needed:

This is needed to accommodate use cases where the events that are relevant for DNS changes are not occurring directly on the service (or other resource) with the external-dns annotations. As mentioned, our specific use case is for managing Postgres clusters, but it could be for any use case where you want to have a stable hostname that can point to a changing target (such as a pod that might be killed or moved). These changes mean that the DNS target should change, but they are not changes in configuration to whatever resource has the external-dns annotation, so they are ignored by external-dns.

It should be feasible to have external-dns also pick up on these sorts of events, since they appear in the Kubernetes event stream, but it would require external-dns to watch for events relevant to the selector of the annotated resource, instead of just watching changes to the annotated resource itself.

[efitzgerald-atlassian]

We'd be willing to work on implementing this as it's quite important for our current project, if it's considered a good addition to external-dns.

[dmarkhas]

We just ran into this behavior ourselves, and I believe it's due to a missing informer here:

https://github.com/kubernetes-sigs/external-dns/blob/master/source/service.go#L719

The handler just isn't being registered to the endpointsInformer.