kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
website/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md

19 KiB
Raw Blame History

translator reviewers title content_template
nicksu
bowei
zihongz
Debug DNS 方案 templates/task

{{% capture overview %}} 这篇文章提供了一些关于 DNS 问题诊断的方法。 {{% /capture %}}

{{% capture prerequisites %}}

  • {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
  • Kubernetes 1.6 或者以上版本。
  • 集群必须使用了 coredns (或者 kube-dns)插件。 {{% /capture %}}

{{% capture steps %}}

创建一个简单的 Pod 作为测试环境

新建一个名为 busybox.yaml 的文件并填入下列内容：

{{< codenew file="admin/dns/busybox.yaml" >}}

然后使用这个文件创建一个 Pod 并验证其状态：

kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml
pod/busybox created

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

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

kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      kubernetes.default
Address 1: 10.0.0.1

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

先检查本地的 DNS 配置

查看 resolv.conf 文件的内容 (阅读下面的 从节点继承 DNS 配置 和 已知问题 ，获取更多信息)

kubectl exec busybox cat /etc/resolv.conf

验证 search 和 name server 的配置是否类似下面的配置 (注意 search 根据不同的云提供商可能会有所不同):

search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal
nameserver 10.0.0.10
options ndots:5

下列错误表示 coredns/kube-dns 或者相关服务出现了问题：

kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10

nslookup: can't resolve 'kubernetes.default'

或者

kubectl exec -ti busybox -- nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'

检查 DNS Pod 是否运行

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

对于 CoreDNS 的情况:

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

或者是 kube-dns:

kubectl get pods --namespace=kube-system -l k8s-app=kube-dns
NAME                    READY     STATUS    RESTARTS   AGE
...
kube-dns-v19-ezo1y      3/3       Running   0           1h
...

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

检查 DNS pod 里的错误

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

对于 CoreDNS:

for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done

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

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

对于 kube-dns, 总共有三种类型的日志需要查看：

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar

看日志信息里是否有可疑的错误，对于 kube-dns, 一个 'W', 'E' 或者 'F' 开头的行表示对应的 Warning（警告）， Error（错误）或者 Failure（失败）。请搜索日志等级是否有这样的关键字的日志信息并使用 kubernetes issues 来提交错误报告。

检查是否启用了 DNS 服务

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

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

注意不管是 CoreDNS 还是 kube-dns ， 这个 service 的名字都会是“kube-dns” 。 如果您已经创建了这个 service 或者说在这个例子里它应该是默认自动创建的，但是它并没有出现，请阅读 services 纠错来获取更多信息。

DNS 的 endpoints 公开了吗？

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

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

如果您没看到对应的 endpoints， 请阅读services 纠错的 endpoints 小节。

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

DNS 查询有被接收或者执行吗？

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

kubectl -n kube-system edit configmap coredns

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        log
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

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

接下来，发起一些查询并依照本文上面章节的内容查看日志信息，如果 CoreDNS 的 pods 接收到这些查询，您将可以在日志信息里看到他们。

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

.:53
2018/08/15 14:37:15 [INFO] CoreDNS-1.2.0
2018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6
CoreDNS-1.2.0
linux/amd64, go1.10.3, 2e322f6
2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
2018/09/07 15:29:04 [INFO] Reloading complete
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 文件来覆盖 /etc/resolv.conf从而在解析域名的时候导致了重复向 DNS 上游服务器推送请求。 这个问题可以通过手动指定 kubelet 的 --resolv-conf 标签为正确的 resolv.conf (如果是 systemd-resolved，则这个文件路径为 /run/systemd/resolve/resolv.conf) 来解决。 kubeadm (>= 1.11) 会自动检测systemd-resolved并对应的更改 kubelet 的标签。

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

Linux 的 libc 会在仅有三个 DNS 的 nameserver 和六个 DNS 的search 记录时会不可思议的卡死 (详情请查阅这个2005年的bug)。Kubernetes 需要占用一个 nameserver 记录和三个search记录。这意味着如果一个本地的安装已经使用了三个nameserver或者使用了超过三个的 search记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用dnsmasq来提供更多的nameserver配置，但是无法提供更多的search记录。您也可以使用kubelet 的 --resolv-conf 标签来解决这个问题。

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

Kubernetes Federation (支持多区域部署)

自从 1.3 版本支持了多个 Kubernetes 的联邦集群后，集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的)，从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 联邦集群管理向导 获取更多关于联邦集群和多点支持的信息。

参考

接下来

{{% /capture %}}