-
Notifications
You must be signed in to change notification settings - Fork 320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CoreDNS support for ExternalName services is broken in EKS 1.11 #129
Comments
Thanks for reporting this @bhang. We will get this fixed. |
I am facing the same problem, any workaround? Maybe remove CoreDNS and come back to kube-dns again? |
@mogaal we just run newer version of coredns. Version 1.3.1. |
@spronin-aurea so is it fine to use upstream releases there aren't any "compatibility" problems with eks? |
@bhang You should now be able to edit your coredns deployment to new image |
Yes, it is fine. We run it in heavy prod for some time now. |
Ok, I believe we can mark this one fixed then. Re-open as apt. |
Yes I used also latest. Seems fine. |
@shyamjvs Apologies for the delay. Can confirm that switching to the version you indicated solves the problem |
|
The 1.1.3 manifest lives at https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-02-11/dns.yaml Which we updated to use Do we have a repository or tracking issue where we can find the approved manifest as it is updated? |
@whereisaaron ref #266 |
I tried to patch my EKS 1.13 coredns deployment as follows:
But none of the versions 1.3.1 and 1.4.0 worked (1.6.1 fails to start). I cannot resolve service names of type ExternalName. The above comments read like upstream releases should work. Which steps did you take to fix this? |
@AndiDog, I had a similar issue but doing this resolved it for me: coredns/coredns#2038 (comment) |
I'd rather not use workarounds to fix stuff in production, especially on strongly audited systems. Would be very surprising if an application then doesn't work anymore after a cluster version upgrade. Today, I have upgraded my EKS cluster to 1.14 including setting all the recommended image versions (core-dns etc.), but it still fails to resolve ExternalName services.
Attempt to access from some pod fails:
|
Per https://kubernetes.io/docs/concepts/services-networking/service/#externalname, it has to be a canonical DNS name:
|
Indeed, using an FQDN instead of an IP works! On EKS with Kubernetes 1.14 (platform version eks.1) at least, cannot test other versions right now. Maybe other people can verify if this works for them.
|
Environment
Kubernetes version: 1.11
Platform version: eks.1
Cluster DNS provider: CoreDNS
CoreDNS image: 602401143452.dkr.ecr.us-east-2.amazonaws.com/eks/coredns:v1.1.3
Problem
The version of coreDNS being deployed to 1.11 EKS clusters suffers from this issue - coredns/coredns#2038 (repro steps available here)
This issue has been fixed in coredns 1.2.1 but EKS is still running the older version (i.e. 1.1.3) and so ExternalName services that serve as an alias for in-cluster kubernetes services in another namespace cannot currently be resolved.
This problem does not exist in 1.10 i.e. w/ kubedns
The text was updated successfully, but these errors were encountered: