service source uses externalIPs in ExternalName type if available

[dromie]

Description

If externalIPs are available in ExternalName type services, then external-dns uses those IPs instead of externalName field.
Useful for developing additional operators..
Checklist

• Unit tests updated
• End user documentation updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dromie (d7b0dfd, 04e92c5)

[k8s-ci-robot]

Hi @dromie. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[mloiseleur]

@dromie You need to sign the CLA. Would you please also detail what do you mean by "Useful for developing additional operators..." ?

[dromie]

@mloiseleur My plan is to write an operator that updates ExternalName type services, that would fetch the source of the IP from a pod's annotation. (If you are familiar with multus-cni, you know where this is heading...).
And I can see that an other way to achieve this, would be using the CRD source method, but working with builtin resources seemed like a better option.

[mloiseleur]

Since you can set the IP directly in ExternalName, like this:

---
apiVersion: v1
kind: Service
metadata:
  name: google-dns
spec:
  type: ExternalName
  externalName: 8.8.8.8
  ports:
    - port: 53
      protocol: UDP

Wdyt about supporting numeric IP in externalName instead of using spec.externalIPs ?

EDIT: re-reading k8s doc about ExternalName, it's really focused on CNAME, so my guess is that it will be better to do it either with CRD or headless Service

[dromie]

since the externalIPs field is an array, you can set multiple IP addresses to a single entity. Using a headless service would be misleading my case, because although these IP addresses are connected pods running in the cluster, but they are not allocated from the POD network.

[mloiseleur]

/ok-to-test

[mloiseleur]

I don't have a strong opinion on this, and the PR looks technically fine.
/lgtm
cc @szuecs @Raffo

[szuecs]

From my side it's fine but would also like to have a mix of ipv4 and ipv6 tested that we get also a mix of A and AAAA records.

[mloiseleur]

ah yes, we should have thought about ipv6.
Thanks @szuecs !
/lgtm

[szuecs]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: szuecs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [szuecs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment