调试 DNS 问题

    你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 如果你还没有集群,你可以通过 构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

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

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

    admin/dns/dnsutils.yaml

    说明: 此示例在 default 名字空间创建 Pod。 服务的 DNS 名字解析取决于 Pod 的名字空间。 详细信息请查阅 。

    使用上面的清单来创建一个 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
    3. Name: kubernetes.default
    4. Address 1: 10.0.0.1

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

    先检查本地的 DNS 配置

    查看 resolv.conf 文件的内容 (阅读 和 后文的已知问题 ,获取更多信息)

    1. kubectl exec -ti dnsutils -- cat /etc/resolv.conf

    验证 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

    下列错误表示 CoreDNS (或 kube-dns)插件或者相关服务出现了问题:

    1. kubectl exec -i -t dnsutils -- nslookup kubernetes.default

    输出为:

    或者

    1. kubectl exec -i -t dnsutils -- nslookup kubernetes.default

    输出为:

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

    检查 DNS Pod 是否运行

    1. kubectl get pods --namespace=kube-system -l k8s-app=kube-dns

    输出为:

    1. ...
    2. coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h
    3. coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h
    4. ...

    说明: 对于 CoreDNS 和 kube-dns 部署而言,标签 k8s-app 的值都应该是 kube-dns

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

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

    如查看 CoreDNS 的日志信息:

    1. kubectl logs --namespace=kube-system -l k8s-app=kube-dns

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

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

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

    检查是否启用了 DNS 服务

    使用 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 服务,或者该服务应该是默认自动创建的但是它并没有出现, 请阅读调试服务 来获取更多信息。

    DNS 的端点公开了吗?

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

    1. kubectl get endpoints kube-dns --namespace=kube-system

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

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

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

    1. kubectl -n kube-system edit configmap coredns

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

    1. apiVersion: v1
    2. kind: ConfigMap
    3. metadata:
    4. name: coredns
    5. namespace: kube-system
    6. data:
    7. Corefile: |
    8. .:53 {
    9. log
    10. errors
    11. health
    12. kubernetes cluster.local in-addr.arpa ip6.arpa {
    13. pods insecure
    14. upstream
    15. fallthrough in-addr.arpa ip6.arpa
    16. }
    17. prometheus :9153
    18. forward . /etc/resolv.conf
    19. loop
    20. reload
    21. loadbalance
    22. }

    接下来,发起一些查询并依照前文所述查看日志信息,如果 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. linux/amd64, go1.10.3, 2e322f6
    5. 2018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f
    6. 2018/09/07 15:29:04 [INFO] Reloading complete
    7. 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

    CoreDNS 是否有足够的权限?

    CoreDNS 必须能够列出 和 endpoint 相关的资源来正确解析服务名称。

    示例错误消息:

    1. 2022-03-18T07:12:15.699431183Z [INFO] 10.96.144.227:52299 - 3686 "A IN serverproxy.contoso.net.cluster.local. udp 52 false 512" SERVFAIL qr,aa,rd 145 0.000091221s

    首先,获取当前的 ClusterRole system:coredns

    1. kubectl describe clusterrole system:coredns -n kube-system

    预期输出:

    1. PolicyRule:
    2. Resources Non-Resource URLs Resource Names Verbs
    3. --------- ----------------- -------------- -----
    4. nodes [] [] [get]
    5. endpoints [] [] [list watch]
    6. namespaces [] [] [list watch]
    7. pods [] [] [list watch]
    8. services [] [] [list watch]
    9. endpointslices.discovery.k8s.io [] [] [list watch]

    如果缺少任何权限,请编辑 ClusterRole 来添加它们:

    1. kubectl edit clusterrole system:coredns -n kube-system

    EndpointSlices 权限的插入示例:

    1. ...
    2. - apiGroups:
    3. - discovery.k8s.io
    4. resources:
    5. - endpointslices
    6. verbs:
    7. - list
    8. - watch
    9. ...

    你的服务在正确的名字空间中吗?

    未指定名字空间的 DNS 查询仅作用于 Pod 所在的名字空间。

    如果 Pod 和服务的名字空间不相同,则 DNS 查询必须指定服务所在的名字空间。

    该查询仅限于 Pod 所在的名字空间:

    1. kubectl exec -i -t dnsutils -- nslookup <service-name>

    指定名字空间的查询:

    要进一步了解名字解析,请查看 Pod 与 Service 的 DNS

    有些 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 服务,因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。

    Linux 的 libc(又名 glibc)默认将 DNS nameserver 记录限制为 3, 而 Kubernetes 需要使用 1 条 nameserver 记录。 这意味着如果本地的安装已经使用了 3 个 nameserver,那么其中有些条目将会丢失。 要解决此限制,节点可以运行 dnsmasq,以提供更多 nameserver 条目。 你也可以使用 kubelet 的 标志来解决这个问题。