除錯 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
使用該 Manifest 建立 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
...
注意
標籤k8s-app 的值對於 CoreDNS 和 kube-dns 部署而言皆為 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 endpoints 命令來驗證 DNS 端點是否已公開。
kubectl get endpoints kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 10.180.3.17:53,10.180.3.17:53 1h
如果您沒有看到端點，請參閱偵錯服務文件中的端點章節。
如需其他 Kubernetes DNS 範例，請參閱 Kubernetes GitHub 儲存庫中的 cluster-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>
若要深入了解名稱解析，請參閱服務和 Pod 的 DNS。
已知問題
某些 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（又稱 glibc）預設限制 DNS nameserver 記錄為 3，而 Kubernetes 需要消耗 1 個 nameserver 記錄。這表示如果本機安裝已使用 3 個 nameserver，則其中一些條目將會遺失。若要解決此限制，節點可以執行 dnsmasq，這將提供更多 nameserver 條目。您也可以使用 kubelet 的 --resolv-conf 旗標。
如果您使用 Alpine 版本 3.17 或更早版本作為基礎映像檔，則 DNS 可能無法正常運作，因為 Alpine 的設計問題。直到 musl 版本 1.24 才包含 TCP 回退至 DNS 存根解析器，這表示任何超過 512 位元組的 DNS 呼叫都會失敗。請將您的映像檔升級到 Alpine 版本 3.18 或以上版本。