Skip to content
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.

External DNS Does not Create Route53 Records from Gateways #153

Closed
amybachir opened this issue Jun 29, 2021 · 5 comments
Closed

External DNS Does not Create Route53 Records from Gateways #153

amybachir opened this issue Jun 29, 2021 · 5 comments

Comments

@amybachir
Copy link

amybachir commented Jun 29, 2021

Hi! My external-dns installation would not create records in Route53 unless I added the following annotation to all my Gateways:

external-dns.alpha.kubernetes.io/target: <elb's-dns-record>.elb.<aws-region>.amazonaws.com

I had to grab the DNS name for the nlb manually and add the annotation above. Did I miss something?

@soleares
Copy link
Collaborator

soleares commented Jun 29, 2021

Are you referring to istio-ingressgateway or something else? The only external-dns annotation I can find in the repo is in the istio-ingressgateway config: https://github.com/argoflow/argoflow-aws/blob/master/distribution/istio/istio-spec.yaml#L54.

I did a recent install (3-4 days ago) and it created the entries in route53 based on the annotation.

Did the external-dns logs show any errors?

@amybachir
Copy link
Author

@soleares Thanks for responding my inquiry. It seems there was an error "Unauthorized" in external-dns log. Restarting the pod just fixed. I don't understand what the issue was but it seems to be working as expected.

@soleares
Copy link
Collaborator

@amybachir Good to hear. Kind of sounds like an issue I had when the service account for the load balancer controller wasn't setup correctly - so it didn't assume the right IAM role and showed an unauthorized error. After I fixed it and restarting the pod it resolved it.

@EKami
Copy link

EKami commented Aug 15, 2021

I guess that's the same issue I have here but adding external-dns.alpha.kubernetes.io/target: <elb's-dns-record>.elb.<aws-region>.amazonaws.com did not seem to work on my side :(

@EKami
Copy link

EKami commented Aug 22, 2021

I think I know why it's happening. If you look at the logs of istio-operator pod it actually doesn't install istio correctly sometimes, I have to redeploy the argocd app twice. It's only when the istio-operator is deployed correctly that you have to delete the istio app for argocd to recreate it and deploy the dns to route53 (again you have to look at the logs of the istio-operator pod, sometimes it's stuck but the pod in argocd is marked as "healthy"). Hope it makes sense.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants