调试 DNS 问题

    你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群，你可以通过 构建一 个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：

    你的集群必须使用了 CoreDNS 插件 或者其前身，。

    您的 Kubernetes 服务器版本必须不低于版本 v1.6. 要获知版本信息，请输入 kubectl version.

    使用上面的清单来创建一个 Pod：

    1. kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
    1. pod/dnsutils created

    验证其状态：

    1. kubectl get pods dnsutils
    1. NAME      READY     STATUS    RESTARTS   AGE
    2. dnsutils   1/1       Running   0          <some-time>

    一旦 Pod 处于运行状态，你就可以在该环境里执行 nslookup。 如果你看到类似下列的内容，则表示 DNS 是正常运行的。

    1. kubectl exec -i -t dnsutils -- nslookup kubernetes.default
    1. Server:    10.0.0.10
    2. Address 1: 10.0.0.10
    4. Address 1: 10.0.0.1

    如果 nslookup 命令执行失败，请检查下列内容：

    先检查本地的 DNS 配置

    查看 resolv.conf 文件的内容 （阅读从节点继承 DNS 配置 和 后文的 ，获取更多信息)

    验证 search 和 nameserver 的配置是否与下面的内容类似 （注意 search 根据不同的云提供商可能会有所不同)：

    1. search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
    2. nameserver 10.0.0.10
    3. options ndots:5
    1. kubectl exec -i -t dnsutils -- nslookup kubernetes.default

    输出为：

    1. Server:    10.0.0.10
    2. Address 1: 10.0.0.10
    4. nslookup: can't resolve 'kubernetes.default'

    或者

    1. Server:    10.0.0.10
    2. Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
    4. nslookup: can't resolve 'kubernetes.default'

    使用 命令来验证 DNS Pod 是否运行。

    1. kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
    1. NAME                       READY     STATUS    RESTARTS   AGE
    2. ...
    3. coredns-7b96bf9f76-5hsxb   1/1       Running   0           1h
    4. coredns-7b96bf9f76-mvmmt   1/1       Running   0           1h
    5. ...

    如果你发现没有 CoreDNS Pod 在运行，或者该 Pod 的状态是 failed 或者 completed， 那可能这个 DNS 插件在您当前的环境里并没有成功部署，你将需要手动去部署它。

    检查 DNS Pod 里的错误

    使用 kubectl logs 命令来查看 DNS 容器的日志信息。

    下列是一个正常运行的 CoreDNS 日志信息：

    1. .:53
    2. 2018/08/15 14:37:17 [INFO] CoreDNS-1.2.2
    3. CoreDNS-1.2.2
    4. linux/amd64, go1.10.3, 2e322f6
    5. 2018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1c

    查看是否日志中有一些可疑的或者意外的消息。

    使用 kubectl get service 命令来检查 DNS 服务是否已经启用。

    1. kubectl get svc --namespace=kube-system
    1. NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
    2. ...
    3. kube-dns     ClusterIP   10.0.0.10      <none>        53/UDP,53/TCP        1h
    4. ...

    说明： 不管是 CoreDNS 还是 kube-dns，这个服务的名字都会是 kube-dns 。

    DNS 的端点公开了吗？

    你可以使用 kubectl get endpoints 命令来验证 DNS 的端点是否公开了。

    1. kubectl get ep kube-dns --namespace=kube-system
    1. NAME       ENDPOINTS                       AGE
    2. kube-dns   10.180.3.17:53,10.180.3.17:53    1h

    如果你没看到对应的端点，请阅读 调试服务的端点部分。

    若需要了解更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看 。

    你可以通过给 CoreDNS 的配置文件（也叫 Corefile）添加 log 插件来检查查询是否被正确接收。 CoreDNS 的 Corefile 被保存在一个叫 的 ConfigMap 里，使用下列命令来编辑它：

    1. kubectl -n kube-system edit configmap coredns

    然后按下面的例子给 Corefile 添加 log。

    保存这些更改后，你可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到 CoreDNS 的 Pod 里。

    接下来，发起一些查询并依照前文所述查看日志信息，如果 CoreDNS 的 Pod 接收到这些查询， 你将可以在日志信息里看到它们。

    下面是日志信息里的查询例子：

    1. .:53
    2. 2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
    3. 2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
    4. CoreDNS-1.2.0
    5. linux/amd64, go1.10.3, 2e322f6
    6. 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
    7. 2018/09/07 15:29:04 [INFO] Reloading complete
    8. 172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s

    有些 Linux 发行版本（比如 Ubuntu）默认使用一个本地的 DNS 解析器（systemd-resolved）。 systemd-resolved 会用一个存根文件（Stub File）来覆盖 /etc/resolv.conf 内容， 从而可能在上游服务器中解析域名产生转发环（forwarding loop）。 这个问题可以通过手动指定 kubelet 的 --resolv-conf 标志为正确的 resolv.conf（如果是 systemd-resolved， 则这个文件路径为 /run/systemd/resolve/resolv.conf）来解决。 kubeadm 会自动检测 systemd-resolved 并对应的更改 kubelet 的命令行标志。

    Kubernetes 的安装并不会默认配置节点的 resolv.conf 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。

    如果你使用 Alpine 3.3 或更早版本作为你的基础镜像，DNS 可能会由于 Alpine 中 一个已知的问题导致无法正常工作。 请查看这里获取更多信息。

    • 参阅.