We have a situation where we would like to use external-dns with a split-horizon DNS in AWS.
The difference with #422 and #322 is that we would like to specify to which hostedzone the DNS entry should be created.
Let's say we have two services (ELBs) with the same domain name; one internal and one internet-facing. Right now, when the first service is created, external-dns will create an entry in both (private and public) zones pointing to the same ELB, which breaks the purpose of the split-horizon.
An idea of solution could be to have another annotation to specify in which zone type (or simply in which zone?) the entries should be added.
Ex:
apiVersion: v1
kind: Service
metadata:
name: my-internal-service
annotations:
external-dns.alpha.kubernetes.io/hostname: app.example.com.
external-dns.alpha.kubernetes.io/audience: private
spec:
...
type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
name: my-external-service
annotations:
external-dns.alpha.kubernetes.io/hostname: app.example.com.
external-dns.alpha.kubernetes.io/audience: public
spec:
...
type: LoadBalancer
I think this is a duplicate of another feature request that I can't find. For the moment, there is a workaround that you can implement: run two instance of external DNS with different filters. Would that work for you in the meantime?
Thanks @Raffo for the answer. As we are using the same domain name for both service, I am not sure if this would be feasible. Any suggestions?
Thanks again!
@vtremblay - Maybe you can use the flag --zone-id-filter ? while the public and private zone have the same domain, the zone id would be unique for each zone. So 2 instances of external-dns, each with a different zone-filter. this is how I am handling split-horizon with external-dns
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
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
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
@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.
@jonathancolby-olx what I'm wondering is how this would work in case that the annotation
# external-dns annotation
external-dns.alpha.kubernetes.io/hostname: example.com
is added to a Service of type LoadBalancer.
So basically I would have two different external-dns deployed with zone-id-filter but the zones they manage are named the same (example.com). How do they differ in which zone tit must be created the entry for the internal ELB if the hostname would be the same?
Just found the annotation filter flag is the answer to my question 馃槉
Just found the annotation filter flag is the answer to my question 馃槉
@mazzy89 you have example?
it is actually in the official documentation https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/public-private-route53.md
Most helpful comment
@vtremblay - Maybe you can use the flag
--zone-id-filter? while the public and private zone have the same domain, the zone id would be unique for each zone. So 2 instances of external-dns, each with a different zone-filter. this is how I am handling split-horizon with external-dns