tdaniely-dn
commented
2 years ago I think there's some confusion. The coredns kubernetes plugin is what actually does the dns updates.
Without the coredns kubernetes plugin we would need to write another controller that updates route53, which is definitely possible. But that's rewriting a free core component to get basically the same functionality payed.
The process to expose the clusters DNS on the subnet is straight-forward:
- Configure coredns as a LoadBalancer type service.
- Configure a parent domain in route53.
- Configure clusters with a subdomain.
- Forward or delegate queries from the parent domain to the cluster's coredns services.
Tell us about your request What do you want us to build? Can we replace coredns with route53 (cloudmap) completely?
Which service(s) is this request for? EKS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Firstly coredns is an additional dependency for kubernetes. Second service discovery requires additional tooling. Usually to make an internal service accessible I have to create a headless service so that external-dsn creates an A record with all the pod-ips. Since kubernetes service discovery is already using round-robin dns internally, I see why can't we use the same for exposing microservices internally (or even externally through public-ip). With coredns replaces by route53, all the above steps I am assuming are out of box. Even a kubernetes svc is completely routable from anywhere within vpc.
Are you currently working around this issue? External-dns
Additional context While talking to community I couldn't understand how dns resolution from route53 is insecure in comparison to dns resolution from coredns. We have coredns plugins to replicate all entries from route53 to coredns. Wondering if its related to this https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html