參考：https://kubernetes.io/zh/docs/tasks/administer-cluster/dns-debugging-resolution/

建立一個簡單的 Pod 作為測試環境

apiVersion: v1
kind: Pod
metadata:
  name: dnsutils
  namespace: default
spec:
  containers:
  - name: dnsutils
    image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
 

說明： 此示例在 default 名稱空間建立 pod。 服務的 DNS 名字解析取決於 pod 的名稱空間。 詳細資訊請查閱 服務和 Pod 的 DNS。

一旦 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 和 nameserver 的配置是否與下面的內容類似 （注意 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 -i -t dnsutils -- nslookup kubernetes.default

輸出為：

Server:    10.0.0.10
Address 1: 10.0.0.10

nslookup: can't resolve '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 的狀態是 failed 或者 completed， 那可能這個 DNS 外掛在您當前的環境裡並沒有成功部署，你將需要手動去部署它。

檢查 DNS Pod 裡的錯誤

使用 kubectl logs 命令來檢視 DNS 容器的日誌資訊。

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 服務，或者該服務應該是預設自動建立的但是它並沒有出現， 請閱讀除錯服務 來獲取更多資訊。

DNS 的端點公開了嗎？

你可以使用 kubectl get endpoints 命令來驗證 DNS 的端點是否公開了。

kubectl get ep 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 查詢有被接收或者執行嗎？

你可以通過給 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
        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

你的服務在正確的名稱空間中嗎？

未指定名稱空間的 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 會用一個存根檔案（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 限制 nameserver 只能有三個記錄。不僅如此，對於 glibc-2.17-222 之前的版本（參見此 Issue 瞭解新版本的更新），search 的記錄不能超過 6 個 （ 詳情請查閱這個 2005 年的 bug）。 Kubernetes 需要佔用一個 nameserver 記錄和三個search記錄。 這意味著如果一個本地的安裝已經使用了三個 nameserver 或者使用了超過三個 search 記錄，而你的 glibc 版本也在有問題的版本列表中，那麼有些配置很可能會丟失。 為了繞過 DNS nameserver 個數限制，節點可以執行 dnsmasq，以提供更多的 nameserver 記錄。你也可以使用kubelet 的 --resolv-conf 標誌來解決這個問題。 要想修復 DNS search 記錄個數限制問題，可以考慮升級你的 Linux 發行版本，或者 升級 glibc 到一個不再受此困擾的版本。

如果你使用 Alpine 3.3 或更早版本作為你的基礎映象，DNS 可能會由於 Alpine 中 一個已知的問題導致無法正常工作。 請檢視這裡（https://github.com/kubernetes/kubernetes/issues/30215）獲取更多資訊。