Kube-dns-间歇性名称解析错误

Question

我们正在AWS的CoreOS上运行kubernetes 1.5.7。我们的kube dns映像版本是

gcr.io/google_containers/kubedns-amd64： 1.9gcr.io/google_containers/kube-dnsmasq-amd64： 1.4.1

我们传递给dnsmasq的参数是

  --cache-size=1000
  --no-resolv
  --server=/in-addr.arpa/ip6.arpa/cluster.local/ec2.internal/127.0.0.1#10053
  --server=169.254.169.253
  --server=8.8.8.8
  --log-facility=-
  --log-async
  --address=/com.cluster.local/com.svc.cluster.local/com.kube-system.svc.cluster.local/<ourdomain>.com.cluster.local/<ourdomain>.com.svc.cluster.local/<ourdomain>.com.kube-system.svc.cluster.local/com.ec2.internal/ec2.internal.kube-system.svc.cluster.local/ec2.internal.svc.cluster.local/ec2.internal.cluster.local/

我们在20个节点集群中每个节点运行1个kube dns pod。在过去的几个月里，我们一直在经历DNS故障，从一个5-10分钟的事件，使我们的服务几乎无法使用，因为名称解析是失败的大多数名称查找。在这些活动中，我们运行了3-6个kube dns吊舱。从那时起，我们已经将我们的kube dns吊舱大幅过度配置为每个节点1个，并且没有看到任何5-10分钟的长dns故障事件。然而，现在我们仍然看到较小的DNS故障事件，范围为1-30秒。在调查这些问题的过程中，我们在日志中注意到来自dnsmasq度量容器的以下错误

错误：在标记之前记录。解析：W0517 03:19:50.139060 1服务器。转到：53]从dnsmasq获取度量值时出错：读取udp 127.0.0.1:36181-

当我们有一个较小的DNS事件持续1-30秒时，我们会从kube DNS吊舱中找到这些日志。有一段时间，我们怀疑我们遇到了一个iptables/conntrack问题，无法连接到命中kube dns服务的吊舱。但基于这些与dnsmasq相关的错误，我们认为dnsmasq在一段时间内拒绝连接，导致了我们所经历的DNS故障。对于不熟悉dnsmasq metrics容器的人，它正在同一个pod中对dnsmasq容器执行DNS查找，以获取dnsmasq统计数据。如果无法通过DNS查找检索dnsmasq统计数据，那么认为执行DNS查找的服务可能会遇到相同的问题似乎是合乎逻辑的。

值得注意的是，在这些问题中，我们没有看到来自dnsmasq的以下日志，这使我相信我们没有达到这个阈值。

dnsmasq:已达到最大并发DNS查询数（最大：150）

我非常确信，我们当前的DNS错误与dnsmasq断断续续地拒绝连接有关。我很好奇其他用户是否看到了库贝-dns pod从dnsmasq度量中记录错误，并且在同一时间帧内从集群中的应用程序记录DNS错误的相同问题。

此外，如果任何人对下一步要做什么有任何想法，以了解到底发生了什么，请使用dnsmasq拒绝连接。我正在考虑在调试模式下运行dnsmasq是否有用，但也担心这会带来与在调试模式下运行相关的其他问题。我们正在考虑的其他方案正在缓慢推出CoreDNS(https://github.com/coredns/coredns).

Answer 1

您提供了许多集群域。每个集群域将被插入到本地/etc/resolv.conf中并被使用。对于resolv.conf中的每个域，都会有单独的dns请求。在您的情况下，每个dns查询将有10个dns查询。

--地址=/com.cluster.local/com.svc.cluster.local/com.kube-system.svc.cluster.local/

我的建议是将集群域的数量减少到只cluster.local。

您提供多个群集域的原因是什么？