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

Question

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

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

我们传递给dnsmasq的args是

  --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。在过去的几个月中，我们经历了5到10分钟不等的DNS故障，这使我们的服务几乎无法使用，因为大多数名称查找都无法使用名称解析。在这些事件中，我们运行了3-6个kube-dns pod。从那时起，我们就将kube-dns Pod的配置大大地提高到每个节点1个，并且没有看到任何长时间的5-10分钟的DNS故障事件。但是，现在我们仍然看到较小的DNS故障事件，范围为1-30秒。在调查这些问题期间，我们在日志中注意到dnsmasq-metrics容器中的以下错误

ERROR: logging before flag.Parse: W0517 03:19:50.139060 1 server.go:53] Error getting metrics from dnsmasq: read udp 127.0.0.1:36181->127.0.0.1:53: i/o timeout

每当我们有一个持续1-30秒的较小DNS事件之一时，我们就会从kube-dns Pane 中找到这些日志。有一阵子，我们怀疑我们遇到了iptables / conntrack问题，导致Pod到达了kube-dns服务。但是基于这些与dnsmasq相关的错误，我们认为dnsmasq在一段时间内拒绝连接会导致我们一直遇到的DNS故障。对于不熟悉dnsmasq-metrics容器的用户，它将对同一容器中的dnsmasq容器执行DNS查找，以获取dnsmasq统计信息。如果无法通过DNS查找来检索dnsmasq统计信息，则认为执行DNS查找的服务可能会遇到相同的问题似乎是合乎逻辑的。

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

dnsmasq: Maximum number of concurrent DNS queries reached (max: 150)

我非常有信心，我们当前的DNS错误与dnsmasq间歇性拒绝连接有关。我很好奇，如果其他用户在kube-dns pod从dnsmasq-metrics记录错误的情况下看到相同的问题，并且在同一时间范围内从群集中的应用程序记录了DNS错误。

此外，如果有人对下一步该如何做有任何想法，以确切了解dnsmasq拒绝连接的情况。我在考虑在 Debug模式下运行dnsmasq是否有用，但我担心还会引入其他与在 Debug模式下运行有关的问题。我们正在考虑的其他选项正在缓慢推出CoreDNS( https://github.com/coredns/coredns)。

Answer 1

您提供了很多群集域。每个群集域都将插入到本地/etc/resolv.conf中并使用。对于resolv.conf中的每个域，将有单独的dns请求。在您的情况下，每个dns查询将有10个以上的dns查询。
--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/

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

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