Endpoint+provider specific annotations on services with multiple domain names

[roehrijn]

What would you like to be added:

Currently it is possible to specify more than one domain on a K8s service object using the annotation external-dns.alpha.kubernetes.io/hostname: name.domain1.tld, name.domain2.tld with comma-separated values. However, it is not possible to configure provider specific annotations in way that they apply to only one of this domains or configure different provider specific values for all the domains. I conducted a PoC and implemented additional parsing on the values of provider specific annotations in the K8s service source implementation. With that approach it is possible to specify something like that:

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        external-dns.alpha.kubernetes.io/hostname: name.domain1.tld, name.domain2.tld
        external-dns.alpha.kubernetes.io/set-identifier: "4711 [name.domain1.tld], 0815 [name.domain2.tld]"
        external-dns.alpha.kubernetes.io/aws-weight: "30 [name.domain1.tld]"
        external-dns.alpha.kubernetes.io/aws-region: "eu-central-1 [name.domain2.tld]"
      name: multi-domain-service
      namespace: default
    spec:
      ...

In general, all the provider specific values can also be comma-separated. In this example I can add (optional) distinguishers in "[..]" after each value. If there is such a distinguisher, the implementation applies the value only to the selected endpoint. If not, it is applied to all the service's endpoints. Thus, it is possible to define different Route53 routing options for the two mentioned domain names in the example above.

At https://github.com/c445/external-dns/commit/69a3ef4fe9ef04467d92c33dfe615ec95a57b5cc you can find the PoC where I implemented the behavior above. Please don't judge the code, it is currently only meant to demonstrate the concept.

My questions:

• is there a possibility that such a modification finds a way into the upstream project?
• are there any ideas to improve UX regarding this multi endpoint specific configurations? I also considered an approach what for example AWS load Balancer Controller is using and it is called stringMap there. But I think with that it is more sophisticated to parse the string and find out the scheme to stay backward-compatible.

Why is this needed:

We at Mercedes-Benz would like to have multiple domains configured on single K8s service objects because we're using AWS NLBs on our services to manage ingress. We need multiple domains on single services to have a direct access domain and one additional domain which undergoes a multi-region load-balancing approach through Route53 and we would like to have single services to avoid the cost of multiple load-balancers being required just to implement different DNS options.

_{Jan Roehrich [email protected], Mercedes-Benz Tech Innovation GmbH, legal info/Impressum}

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.