除錯 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