调试 DNS 解析
本页面提供了诊断 DNS 问题的提示。
准备工作
你需要有一个 Kubernetes 集群，并且 kubectl 命令行工具已配置为与你的集群通信。建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者使用这些 Kubernetes 演练场之一。
你的集群必须配置为使用 CoreDNS 插件 或其前身 kube-dns。
你的 Kubernetes 服务器版本必须是 v1.6 或更高版本。
要检查版本，请输入 kubectl version。
创建一个简单的 Pod 作为测试环境
apiVersion: v1
kind: Pod
metadata:
name: dnsutils
namespace: default
spec:
containers:
- name: dnsutils
image: registry.k8s.io/e2e-test-images/agnhost:2.39
imagePullPolicy: IfNotPresent
restartPolicy: Always
使用该清单创建一个 Pod
kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
pod/dnsutils created
…并验证其状态
kubectl get pods dnsutils
NAME READY STATUS RESTARTS AGE
dnsutils 1/1 Running 0 <some-time>
一旦 Pod 运行起来，你就可以在该环境中执行 nslookup。如果你看到类似以下内容，则 DNS 正常工作。
kubectl exec -i -t dnsutils -- 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 -ti dnsutils -- cat /etc/resolv.conf
验证搜索路径和名称服务器是否设置如下（请注意，不同云提供商的搜索路径可能有所不同）
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 -i -t dnsutils -- nslookup kubernetes.default
Server: 10.0.0.10
Address 1: 10.0.0.10
nslookup: can't resolve 'kubernetes.default'
或者
kubectl exec -i -t dnsutils -- 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 是否正在运行。
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
...
注意
CoreDNS 和 kube-dns 部署的k8s-app 标签的值均为 kube-dns。如果你看到没有 CoreDNS Pod 正在运行，或者 Pod 已失败/完成，则 DNS 插件可能未在你的当前环境中默认部署，你将不得不手动部署它。
检查 DNS Pod 中的错误
使用 kubectl logs 命令查看 DNS 容器的日志。
对于 CoreDNS
kubectl logs --namespace=kube-system -l k8s-app=kube-dns
以下是一个健康的 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
查看日志中是否有任何可疑或意外消息。
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 部署的服务名称均为kube-dns。如果你已创建服务，或者如果它应该默认创建但没有出现，请参阅 调试服务 以获取更多信息。
DNS 端点是否暴露？
你可以使用 kubectl get endpointslice 命令验证 DNS 端点是否已暴露。
kubectl get endpointslices -l k8s.io/service-name=kube-dns --namespace=kube-system
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
kube-dns-zxoja IPv4 53 10.180.3.17,10.180.3.17 1h
如果看不到端点，请参阅 调试服务 文档中的端点部分。
有关其他 Kubernetes DNS 示例，请参阅 Kubernetes GitHub 仓库中的 集群 DNS 示例。
DNS 查询是否正在接收/处理？
你可以通过将 log 插件添加到 CoreDNS 配置（即 Corefile）来验证 CoreDNS 是否正在接收查询。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
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
保存更改后，Kubernetes 可能需要一到两分钟才能将这些更改传播到 CoreDNS Pod。
接下来，按照本文档中上面的部分进行一些查询并查看日志。如果 CoreDNS Pod 正在接收查询，你应该在日志中看到它们。
以下是日志中查询的示例
.: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
CoreDNS 是否具有足够的权限？
CoreDNS 必须能够列出 服务 和 端点切片 相关资源，以正确解析服务名称。
示例错误消息
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
首先，获取 system:coredns 的当前 ClusterRole
kubectl describe clusterrole system:coredns -n kube-system
预期输出
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
endpoints [] [] [list watch]
namespaces [] [] [list watch]
pods [] [] [list watch]
services [] [] [list watch]
endpointslices.discovery.k8s.io [] [] [list watch]
如果缺少任何权限，请编辑 ClusterRole 以添加它们
kubectl edit clusterrole system:coredns -n kube-system
EndpointSlices 权限的示例插入
...
- apiGroups:
- discovery.k8s.io
resources:
- endpointslices
verbs:
- list
- watch
...
你是否在服务的正确命名空间中？
未指定命名空间的 DNS 查询仅限于 Pod 的命名空间。
如果 Pod 和服务的命名空间不同，则 DNS 查询必须包含服务的命名空间。
此查询仅限于 Pod 的命名空间
kubectl exec -i -t dnsutils -- nslookup <service-name>
此查询指定了命名空间
kubectl exec -i -t dnsutils -- nslookup <service-name>.<namespace>
要了解有关名称解析的更多信息，请参阅 服务的 DNS 和 Pod。
已知问题
某些 Linux 发行版（例如 Ubuntu）默认使用本地 DNS 解析器 (systemd-resolved)。Systemd-resolved 会将 /etc/resolv.conf 移动并替换为一个存根文件，这可能在解析上游服务器中的名称时导致致命的转发循环。这可以通过使用 kubelet 的 --resolv-conf 标志指向正确的 resolv.conf（对于 systemd-resolved，这是 /run/systemd/resolve/resolv.conf）手动修复。kubeadm 会自动检测 systemd-resolved，并相应地调整 kubelet 标志。
Kubernetes 安装默认不配置节点的 resolv.conf 文件以使用集群 DNS，因为该过程本质上是特定于发行版的。这最终应该实现。
Linux 的 libc (a.k.a. glibc) 默认将 DNS nameserver 记录限制为 3 条，而 Kubernetes 需要消耗 1 条 nameserver 记录。这意味着如果本地安装已经使用了 3 条 nameserver，其中一些条目将会丢失。为了解决此限制，节点可以运行 dnsmasq，这将提供更多 nameserver 条目。你也可以使用 kubelet 的 --resolv-conf 标志。
如果使用 Alpine 3.17 或更早版本作为基础镜像，由于 Alpine 的设计问题，DNS 可能无法正常工作。直到 musl 版本 1.24 才包含 DNS 存根解析器的 TCP 回退机制，这意味着任何超过 512 字节的 DNS 调用都会失败。请将你的镜像升级到 Alpine 3.18 或更高版本。
下一步
- 请参阅 集群中 DNS 服务的水平自动扩缩。
- 阅读 服务的 DNS 和 Pod