Kubernetes 調(diào)試DNS問題

調(diào)試 DNS 問題

這篇文章提供了一些關(guān)于 DNS 問題診斷的方法。

在開始之前

你必須擁有一個(gè) Kubernetes 的集群，同時(shí)你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個(gè)節(jié)點(diǎn)的集群上運(yùn)行本教程，且這些節(jié)點(diǎn)不作為控制平面主機(jī)。 如果你還沒有集群，你可以通過 Minikube 構(gòu)建一個(gè)你自己的集群，或者你可以使用下面任意一個(gè) Kubernetes 工具構(gòu)建：

• Katacoda
• 玩轉(zhuǎn) Kubernetes

你的集群必須使用了 CoreDNS 插件 或者其前身，?kube-dns?。

您的 Kubernetes 服務(wù)器必須是 v1.6 或更高版本。 要檢查版本，請(qǐng)輸入 ?kubectl version?。

創(chuàng)建一個(gè)簡(jiǎn)單的 Pod 作為測(cè)試環(huán)境

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

Note: 此示例在 ?default ?命名空間創(chuàng)建 pod。 服務(wù)的 DNS 名字解析取決于 pod 的命名空間。

使用上面的清單來創(chuàng)建一個(gè) Pod：

kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml

pod/dnsutils created

驗(yàn)證其狀態(tài)：

kubectl get pods dnsutils

NAME      READY     STATUS    RESTARTS   AGE
dnsutils   1/1       Running   0          <some-time>

一旦 Pod 處于運(yùn)行狀態(tài)，你就可以在該環(huán)境里執(zhí)行 ?nslookup?。 如果你看到類似下列的內(nèi)容，則表示 DNS 是正常運(yùn)行的。

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 ?命令執(zhí)行失敗，請(qǐng)檢查下列內(nèi)容：

先檢查本地的 DNS 配置

查看 resolv.conf 文件的內(nèi)容

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

驗(yàn)證 search 和 nameserver 的配置是否與下面的內(nèi)容類似 （注意 search 根據(jù)不同的云提供商可能會(huì)有所不同)：

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

下列錯(cuò)誤表示 CoreDNS （或 kube-dns）插件或者相關(guān)服務(wù)出現(xiàn)了問題：

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 是否運(yùn)行 

使用 ?kubectl get pods? 命令來驗(yàn)證 DNS Pod 是否運(yùn)行。

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
...

Note: 對(duì)于 CoreDNS 和 kube-dns 部署而言，標(biāo)簽 ?k8s-app? 的值都應(yīng)該是 ?kube-dns?。

如果你發(fā)現(xiàn)沒有 CoreDNS Pod 在運(yùn)行，或者該 Pod 的狀態(tài)是 failed 或者 completed， 那可能這個(gè) DNS 插件在你當(dāng)前的環(huán)境里并沒有成功部署，你將需要手動(dòng)去部署它。

檢查 DNS Pod 里的錯(cuò)誤 

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

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

下列是一個(gè)正常運(yùn)行的 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 服務(wù) 

使用 ?kubectl get service? 命令來檢查 DNS 服務(wù)是否已經(jīng)啟用。

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
...

Note: 不管是 CoreDNS 還是 kube-dns，這個(gè)服務(wù)的名字都會(huì)是 ?kube-dns? 。

如果你已經(jīng)創(chuàng)建了 DNS 服務(wù)，或者該服務(wù)應(yīng)該是默認(rèn)自動(dòng)創(chuàng)建的但是它并沒有出現(xiàn)， 請(qǐng)閱讀調(diào)試服務(wù) 來獲取更多信息。

DNS 的端點(diǎn)公開了嗎？ 

你可以使用 ?kubectl get endpoints? 命令來驗(yàn)證 DNS 的端點(diǎn)是否公開了。

kubectl get ep kube-dns --namespace=kube-system

NAME       ENDPOINTS                       AGE
kube-dns   10.180.3.17:53,10.180.3.17:53    1h

如果你沒看到對(duì)應(yīng)的端點(diǎn)，請(qǐng)閱讀 調(diào)試服務(wù)的端點(diǎn)部分。

若需要了解更多的 Kubernetes DNS 例子，請(qǐng)?jiān)?nbsp;Kubernetes GitHub 倉(cāng)庫(kù)里查看 cluster-dns 示例。

DNS 查詢有被接收或者執(zhí)行嗎？ 

你可以通過給 CoreDNS 的配置文件（也叫 Corefile）添加 ?log ?插件來檢查查詢是否被正確接收。 CoreDNS 的 Corefile 被保存在一個(gè)叫 ?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
    }

保存這些更改后，你可能會(huì)需要等待一到兩分鐘讓 Kubernetes 把這些更改應(yīng)用到 CoreDNS 的 Pod 里。

接下來，發(fā)起一些查詢并依照前文所述查看日志信息，如果 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 是否有足夠的權(quán)限？

CoreDNS 必須能夠列出 service 和 endpoint 相關(guān)的資源來正確解析服務(wù)名稱。

示例錯(cuò)誤消息：

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

首先，獲取當(dāng)前的 ClusterRole ?system:coredns?：

kubectl describe clusterrole system:coredns -n kube-system

預(yù)期輸出：

PolicyRule:
  Resources                        Non-Resource URLs  Resource Names  Verbs
  ---------                        -----------------  --------------  -----
  nodes                            []                 []              [get]
  endpoints                        []                 []              [list watch]
  namespaces                       []                 []              [list watch]
  pods                             []                 []              [list watch]
  services                         []                 []              [list watch]
  endpointslices.discovery.k8s.io  []                 []              [list watch]

如果缺少任何權(quán)限，請(qǐng)編輯 ClusterRole 來添加它們：

kubectl edit clusterrole system:coredns -n kube-system

EndpointSlices 權(quán)限的插入示例：

...
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - list
  - watch
...

你的服務(wù)在正確的命名空間中嗎？

未指定命名空間的 DNS 查詢僅作用于 pod 所在的命名空間。

如果 pod 和服務(wù)的命名空間不相同，則 DNS 查詢必須指定服務(wù)所在的命名空間。

該查詢僅限于 pod 所在的名稱空間：

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

指定命名空間的查詢：

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

已知問題

有些 Linux 發(fā)行版本（比如 Ubuntu）默認(rèn)使用一個(gè)本地的 DNS 解析器（systemd-resolved）。 ?systemd-resolved? 會(huì)用一個(gè)存根文件（Stub File）來覆蓋 ?/etc/resolv.conf? 內(nèi)容， 從而可能在上游服務(wù)器中解析域名產(chǎn)生轉(zhuǎn)發(fā)環(huán)（forwarding loop）。 這個(gè)問題可以通過手動(dòng)指定 kubelet 的 ?--resolv-conf? 標(biāo)志為正確的 ?resolv.conf?（如果是 ?systemd-resolved?， 則這個(gè)文件路徑為 ?/run/systemd/resolve/resolv.conf?）來解決。 kubeadm 會(huì)自動(dòng)檢測(cè) ?systemd-resolved? 并對(duì)應(yīng)的更改 kubelet 的命令行標(biāo)志。

Kubernetes 的安裝并不會(huì)默認(rèn)配置節(jié)點(diǎn)的 ?resolv.conf? 文件來使用集群的 DNS 服務(wù)，因?yàn)檫@個(gè)配置對(duì)于不同的發(fā)行版本是不一樣的。這個(gè)問題應(yīng)該遲早會(huì)被解決的。

Linux 的 libc 限制 ?nameserver ?只能有三個(gè)記錄。不僅如此，對(duì)于 glibc-2.17-222 之前的版本（參見此 Issue 了解新版本的更新），?search ?的記錄不能超過 6 個(gè) （ 詳情請(qǐng)查閱這個(gè) 2005 年的 bug）。 Kubernetes 需要占用一個(gè) ?nameserver ?記錄和三個(gè)?search?記錄。 這意味著如果一個(gè)本地的安裝已經(jīng)使用了三個(gè) ?nameserver ?或者使用了超過三個(gè) ?search ?記錄，而你的 glibc 版本也在有問題的版本列表中，那么有些配置很可能會(huì)丟失。 為了繞過 DNS ?nameserver ?個(gè)數(shù)限制，節(jié)點(diǎn)可以運(yùn)行 ?dnsmasq?，以提供更多的 ?nameserver ?記錄。你也可以使用kubelet 的 ?--resolv-conf? 標(biāo)志來解決這個(gè)問題。 要想修復(fù) DNS ?search ?記錄個(gè)數(shù)限制問題，可以考慮升級(jí)你的 Linux 發(fā)行版本，或者 升級(jí) glibc 到一個(gè)不再受此困擾的版本。

Note:
使用擴(kuò)展 DNS 設(shè)置， Kubernetes 允許更多的 ?search ?記錄。

如果你使用 Alpine 3.3 或更早版本作為你的基礎(chǔ)鏡像，DNS 可能會(huì)由于 Alpine 中 一個(gè)已知的問題導(dǎo)致無法正常工作。 請(qǐng)查看這里獲取更多信息。