我有一个运行“v1.12.6-eks-d69f1”的双节点 Kubernetes EKS 集群
Amazon VPC CNI Plugin for Kubernetes version: amazon-k8s-cni:v1.4.1
CoreDNS version: v1.1.3
KubeProxy: v1.12.6
集群上运行着两个 CoreDNS pod。
我遇到的问题是我的 pod 间歇性地解析内部 DNS 名称。 (外部 DNS 名称的解析工作正常)
root@examplecontainer:/# curl http://elasticsearch-dev.internaldomain.local:9200/
curl: (6) Could not resolve host: elasticsearch-dev.internaldomain.local
elasticsearch-dev.internaldomain.local 在 AWS Route53 内部托管区域上注册。上面的工作间歇性地进行，如果我发出五个请求，其中两个会正确解析，其余的会失败。
这些是上面 examplecontainer 上的/etc/resolv.conf 文件的内容:
root@examplecontainer:/# cat /etc/resolv.conf
nameserver 172.20.0.10
search default.svc.cluster.local svc.cluster.local cluster.local eu-central-1.compute.internal
options ndots:5
知道为什么会发生这种情况吗？
最佳答案
我通过从自定义“DHCP 选项集”切换到 AWS 提供的默认“DHCP 选项集”解决了这个问题。我在几个月前创建了自定义“DHCP 选项集”并将其分配给运行 EKS 集群的 VPC...
我是怎么弄清楚的？
运行“kubectl get events -n kube-system”后，我意识到以下几点:
Warning DNSConfigForming 17s (x15 over 14m) kubelet, ip-10-4-9-155.us-west-1.compute.internal Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: 10.4.8.2 8.8.8.8 8.8.4.4
8.8.8.8 和 8.8.4.4 是由我创建的麻烦的“DHCP 选项集”注入(inject)的。而且我认为我的服务间歇性解析内部 DNS 名称的原因是因为 CoreDNS 服务在内部以循环方式将 DNS 请求转发到 10.4.8.2、8.8.4.4、8.8.8.8。由于最后 2 个 DNS 服务器不知道我的 Route53 内部托管区域 DNS 记录，因此解析间歇性失败。
注意 10.4.8.2 是默认的 AWS 名称服务器。
只要切换到 AWS 提供的默认“DHCP 选项集”，EKS 服务就可以一致地解析我的内部 DNS 名称。
我希望这对将来的人有所帮助。
关于amazon-web-services - Kubernetes CoreDNS 间歇性解析名称，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56107267/