Closed StianOvrevage closed 3 years ago
I've been trying to figure out how to do this as well. I use the cert-manager controller to create letsencypt certificates and would like to use a single wildcard dns record and certificate to avoid rate limits when creating and deleting ingress resources.
As a hack, you can set the hostname to empty string on the ingress
external-dns.alpha.kubernetes.io/hostname: ""
Does this annotation "external-dns.alpha.kubernetes.io/hostname" apply for ingresses as well? or is it just for services of type=LB
@prachidamle According to personal testing and a quick look at the code, yes, it should support ingress
with aws-alb-ingress-controller, setting external-dns.alpha.kubernetes.io/hostname: "" doesn't work. Even removing the annotation doesn't work.
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
/remove-lifecycle stale
@StianOvrevage I can give you a couple of ideas but I didn't understand your setup fully.
For CNAME to work with the TXT registry you have to use a non-empty --txt-prefix
on all your ExternalDNS instances (it should be the same on all in your case)
When you have multiple ExternalDNS instances messing around with the same hostnames and zones you should give each instance a different non-empty value for their --txt-owner-id
. This allows each instance to "own" a record so that once it's "claimed" it won't be change by other ExternalDNS instances even if they also know about that DNS name.
If you then want to change the "ownership" of a DNS record from one cluster to another you could manually update the owner value in the TXT record and the other ExternalDNS instance will adopt that record (and probably change the corresponding CNAME to its cluster's Ingress entrypoint).
If you merely want to instruct ExternalDNS to ignore certain Ingresses you could start them with the --annotation-filter
flag which expects an annotation selector and matches all Ingresses of a cluster against it.
For example, you could start ExternalDNS with --annotation-filter=ingress.class=nginx
to have it only process Ingresses that are backed by the nginx ingress controller. It supports the full label selector syntax, so you can also use !=
etc.
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.
For example, you could start ExternalDNS with
--annotation-filter=ingress.class=nginx
to have it only process Ingresses that are backed by the nginx ingress controller. It supports the full label selector syntax, so you can also use!=
etc.
@linki How does the !=
syntax need to look? I've tried it a few ways and not been able to get it to work. I get the following error:
"\"!=\" is not a valid label selector operator"
using:
--annotation-filter=kubernetes.io/ingress.class!=internal-ingress
/reopen
@runningman84: You can't reopen an issue/PR unless you authored it or you are a collaborator.
For example, you could start ExternalDNS with
--annotation-filter=ingress.class=nginx
to have it only process Ingresses that are backed by the nginx ingress controller. It supports the full label selector syntax, so you can also use!=
etc.@linki How does the
!=
syntax need to look? I've tried it a few ways and not been able to get it to work. I get the following error:"\"!=\" is not a valid label selector operator"
using:--annotation-filter=kubernetes.io/ingress.class!=internal-ingress
@linki the !=
syntax does not work
@2tim the syntax is described in this comment by @Evesy
"--annotation-filter=kubernetes.io/ingress.class notin (internal-ingress)"
@Evesy thanks, I think I found that shortly after posting this buried somewhere. I’m using that today.
I request a feature or a bug fix.
Setting external-dns.alpha.kubernetes.io/hostname: ""
for AWS load balancer controller doesn't work.
I think ignoring one or two ingress objects is a valid requirement.
For example, you are creating an ALB which sends traffic to the website services, but you want to put your apex domain on a CloudFront which uses the ALB as an origin instead of putting the apex domain on the ALB itself.
Of course, there can be some manual hacks, for example, setting the policy to create-only
instead of upcert-only
or sync
, then after the record is created you can change it to the CloudFront distribution. But you probably want to upcert or sync for all the other ingresses, so this won't work.
So, please, implement this. Some annotation like external-dns.alpha.kubernetes.io/create-dns-record: false
which defaults to true would be nice.
/reopen
@IronCore864: You can't reopen an issue/PR unless you authored it or you are a collaborator.
@IronCore864 this issue is now reopened.
/reopen
@seanmalloy: Reopened this issue.
/remove-lifecycle rotten
We will use #1910 instead. Sorry for the confusion.
/close
@seanmalloy: Closing this issue.
You can set external-dns.alpha.kubernetes.io/ingress-hostname-source: annotation-only
to force it to generate DNS records only based on the annotations. If you then leave out the external-dns.alpha.kubernetes.io/hostname
annotation it won't generate any records at all.
This does not work with istio virtual services :(
We could add a check here -> https://github.com/kubernetes-sigs/external-dns/blob/master/source/istio_virtualservice.go#L330
Similar to how it's done in the ingress
file
Do you know if there any WIP for this?
You can set
external-dns.alpha.kubernetes.io/ingress-hostname-source: annotation-only
to force it to generate DNS records only based on the annotations. If you then leave out theexternal-dns.alpha.kubernetes.io/hostname
annotation it won't generate any records at all.
Note: I added external-dns.alpha.kubernetes.io/controller: hacktonotmanagethesehostswithexternaldns
as a hack to make it works.
We have external-dns set up with
--source=ingress
.We have multiple clusters running variations of the same service. We then point a permanent DNS alias (CNAME) to the cluster that is operational.
For this to work we need to have ingresses across clusters that have the same hostname.
We want to have control over these CNAME records. However, external-dns keeps overwriting and creating race-conditions messing everything up.
Ideally there should be an ingress annotation allow us to disable external-dns for that ingress but I have not been able to find any such functionality.
Next I have tried adding
--txt-prefix=lock.
to allow TXT and CNAME to co-exist. I look at thelock.alias
TXT record, change the owner-ref to something else and delete the A record to free it up so we can create the needed CNAME. A second later the TXT record is changed back and the A record is back preventing us from creating a CNAME to the chosen cluster.