當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【好文收藏】k8s中Pod 无法正常解析域名：部署 DNS 调试工具排查

發布時間：2025/1/21 编程问答 30 豆豆

生活随笔收集整理的這篇文章主要介紹了【好文收藏】k8s中Pod 无法正常解析域名：部署 DNS 调试工具排查小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

k8s 中 Pod 無法正常解析域名：部署 DNS 調試工具排查

問題描述

最近將 Kubernetes 升級到 1.18.1 版本，不過升級完后，查看工作節點的部分 Pod 無法啟動，查看消息全是 connetion timeout 的問題，一看連接超時的地址大部分是以域名方式連接集群內部地址（ClusterIP），少部分是以域名方式連接集群外部地址，通過 IP 進行遠程連接的應用倒是沒有問題（例如，應用通過 IP 連接 MySQL），由此判斷，初步懷疑很可能是 DNS 出現了問題，后來慢慢發現 kube-proxy 中的錯誤，再定位到 IPVS parseIP Error 錯誤，再到解決問題。下面是分析及解問題的過程。

部署 DNS 調試工具

為了探針是否為 DNS 問題，這里需要提前部署用于測試 DNS 問題的 dnsutils 鏡像，該鏡像中包含了用于測試 DNS 問題的工具包，非常利于我們分析與發現問題。接下來，我們將在 Kubernetes 中部署這個工具鏡像。

創建 DNS 工具 Pod 部署文件

創建用于部署的 Deployment 資源文件 ndsutils.yaml：

ndsutils.yaml

apiVersion: v1 kind: Pod metadata: name: dnsutils spec: containers: - name: dnsutils image: mydlqclub/dnsutils:1.3 imagePullPolicy: IfNotPresent command: ["sleep","3600"]

通過 Kubectl 工具部署 NDS 工具鏡像

通過 Kubectl 工具，將對上面 DNS 工具鏡像部署到 Kubernetes 中：

-n：指定應用部署的 Namespace 空間。

$ kubectl create -f ndsutils.yaml -n kube-system

問題分析

進入 DNS 工具 Pod 的命令行

上面 DNS 工具已經部署完成，我們可也通過 Kubectl 工具進入 Pod 命令行，然后，使用里面的一些工具進行問題分析，命令如下：

exec：讓指定 Pod 容器執行某些命令。
-i：將控制臺內容傳入到容器。
-t：進入容器的 tty 使用 bash 命令行。
-n：指定上面部署 DNS Pod 所在的 Namespace。

$ kubectl exec -it dnsutils /bin/sh -n kube-system

通過 Ping 和 Nsloopup 命令測試

進入容器 sh 命令行界面后，先使用 ping 命令來分別探測觀察是否能夠 ping 通集群內部和集群外部的地址，觀察到的信息如下：

## Ping 集群外部，例如這里 ping 一下百度 $ ping www.baidu.com ping: bad address 'www.baidu.com'## Ping 集群內部 kube-apiserver 的 Service 地址 $ ping kubernetes.default ping: bad address 'kubernetes.default'## 使用 nslookup 命令查詢域名信息 $ nslookup kubernetes.default ;; connection timed out; no servers could be reached## 直接 Ping 集群內部 kube-apiserver 的 IP 地址 $ ping 10.96.0.1 PING 10.96.0.1 (10.96.0.1): 56 data bytes 64 bytes from 10.96.0.1: seq=0 ttl=64 time=0.096 ms 64 bytes from 10.96.0.1: seq=1 ttl=64 time=0.050 ms 64 bytes from 10.96.0.1: seq=2 ttl=64 time=0.068 ms## 退出 dnsutils Pod 命令行 $ exit

可以觀察到兩次 ping 域名都不能 ping 通，且使用 nsloopup 分析域名信息時超時。然而，使用 ping kube-apiserver 的 IP 地址 “10.96.0.1” 則可以正常通信，所以，排除網絡插件（Flannel、Calico 等）的問題。初步判斷，很可能是 CoreDNS 組件的錯誤引起的某些問題，所以接下來我們測試 CoreDNS 是否正常。

檢測 CoreDNS 應用是否正常運行

首先，檢查 CoreDNS Pod 是否正在運行，如果 READY 為 0，則顯示 CoreDNS 組件有問題：

-l：指定根據 label 標簽進行查找，篩選有該 label 的 Pod。
-n：指定 CoreDNS 組件部署的 Namespace。

$ kubectl get pods -l k8s-app=kube-dns -n kube-system NAME READY STATUS RESTARTS AGE coredns-669f77d7cc-8pkpw 1/1 Running 2 6h5m coredns-669f77d7cc-jk9wk 1/1 Running 2 6h5m

可也看到 CoreDNS 兩個 Pod 均正常啟動，所以再查看兩個 Pod 中的日志信息，看看有無錯誤日志：

$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \ do kubectl logs --namespace=kube-system $p; done.:53 [INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7 CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b .:53 [INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7 CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b

通過上面信息可以觀察到，日志中信息也是正常啟動沒有問題。再接下來，查看下 CoreDNS 的入口 Service “kube-dns” 是否存在：

kube-dns 的 IP 為 10.96.0.10，集群內的 Pod 都是通過該 IP 與 DNS 組件進行交互，查詢 DNS 信息。

$ kubectl get service -n kube-system | grep kube-dns NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP

上面顯示 Service “kube-dns” 也存在，但是 Service 是通過 endpoints 和 Pod 進行綁定的，所以看看這個 CoreDNS 的 Endpoints 是否存在，及信息是否正確：

$ kubectl get endpoints kube-dns -n kube-system NAME ENDPOINTS kube-dns 10.244.0.21:53,d10.244.2.82:53,10.244.0.21:9153

可以看到 Endpoints 配置也是正常的，正確的與兩個 CporeDNS Pod 進行了關聯。

經過上面一系列檢測 CoreDNS 組件確實是正常運行。接下來，觀察 CoreDNS 域名解析日志，進而確定 Pod 中的域名解析請求是否能夠正常進入 CoreDNS。

觀察 CoreDNS 域名解析日志信息

使用 kubectl edit 命令來修改存儲于 Kubernetes ConfigMap 中的 CoreDNS 配置參數信息，添加 log 參數，讓 CoreDNS 日志中顯示域名解析信息：

CoreDNS 配置參數說明：

errors：輸出錯誤信息到控制臺。
health：CoreDNS 進行監控檢測，檢測地址為 http://localhost:8080/health 如果狀態為不健康則讓 Pod 進行重啟。
ready：全部插件已經加載完成時，將通過 endpoints 在 8081 端口返回 HTTP 狀態 200。
kubernetes：CoreDNS 將根據 Kubernetes 服務和 pod 的 IP 回復 DNS 查詢。
prometheus：是否開啟 CoreDNS Metrics 信息接口，如果配置則開啟，接口地址為 http://localhost:9153/metrics
forward：任何不在Kubernetes 集群內的域名查詢將被轉發到預定義的解析器 (/etc/resolv.conf)。
cache：啟用緩存，30 秒 TTL。
loop：檢測簡單的轉發循環，如果找到循環則停止 CoreDNS 進程。
reload：監聽 CoreDNS 配置，如果配置發生變化則重新加載配置。
loadbalance：DNS 負載均衡器，默認 round_robin。

## 編輯 coredns 配置 $ kubectl edit configmap coredns -n kube-systemapiVersion: v1 data: Corefile: | .:53 {log #添加logerrorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}prometheus :9153forward . /etc/resolv.confcache 30loopreloadloadbalance }

保存更改后 CoreDNS 會自動重新加載配置信息，不過可能需要等上一兩分鐘才能將這些更改傳播到 CoreDNS Pod。等一段時間后，再次查看 CoreDNS 日志：

$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \ do kubectl logs --namespace=kube-system $p; done.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete [INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete

可以看到 CoreDNS 已經重新加載了配置，我們再次進入 dnsuitls Pod 中執行 ping 命令：

## 進入 DNSutils Pod 命令行 $ kubectl exec -it dnsutils /bin/sh -n kube-system## 執行 ping 命令 $ ping www.baidu.com## 退出 dnsutils Pod 命令行 $ exit

然后，再次查看 CoreDNS 的日志信息：

$ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \ do kubectl logs --namespace=kube-system $p; done.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete [INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete

發現和之前沒有執行 ping 命令時候一樣，沒有 DNS 域名解析的日志信息，說明 Pod 執行域名解析時，請求并沒有進入 CoreDNS 中。接下來在查看 Pod 中 DNS 配置信息，進而分析問題。

查看 Pod 中的 DNS 配置信息

一般 Pod 中的 DNS 策略默認為 ClusterFirst，該參數起到的作用是，優先從 Kubernetes DNS 插件地址讀取 DNS 配置。所以，我們正常創建的 Pod 中，DNS 配置 DNS 服務器地址應該指定為 Kubernetes 集群的 DNS 插件 Service 提供的虛擬 IP 地址。

注：其中 DNS 策略（dnsPolicy）支持四種類型：

Default：從 DNS 所在節點繼承 DNS 配置，即該 Pod 的 DNS 配置與宿主機完全一致。
ClusterFirst：預先從 Kubenetes 的 DNS 插件中進行 DNS 解析，如果解析不成功，才會使用宿主機的 DNS 進行解析。
ClusterFirstWithHostNet：Pod 是用 HOST 模式啟動的（hostnetwork），用 HOST 模式表示 Pod 中的所有容器，都使用宿主機的 /etc/resolv.conf 配置進行 DNS 解析，但如果使用了 HOST 模式，還繼續使用 Kubernetes 的 DNS 服務，那就將 dnsPolicy 設置為 ClusterFirstWithHostNet。
None：完全忽略 kubernetes 系統提供的 DNS，以 Pod Spec 中 dnsConfig 配置為主。

為了再分析原因，我們接著進入 dnsutils Pod 中，查看 Pod 中 DNS 配置文件 /etc/resolv.conf 配置參數是否正確：

resolv.conf 配置參數說明：

search：指明域名查詢順序。
nameserver：指定 DNS 服務器的 IP 地址，可以配置多個 nameserver。

## 進入 dnsutils Pod 內部 sh 命令行 $ kubectl exec -it dnsutils /bin/sh -n kube-system## 查看 resolv.conf 配置文件 $ cat /etc/resolv.confnameserver 10.96.0.10 search kube-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5## 退出 DNSutils Pod 命令行 $ exit

可以看到 Pod 內部的 resolv.conf 內容，其中 nameserver 指定 DNS 解析服務器 IP 為 “10.96.0.10” ，這個 IP 地址正是本人 Kubernetes 集群 CoreDNS 的 Service “kube-dns” 的 cluterIP，說明當 Pod 內部進行域名解析時，確實是將查詢請求發送到 Service “kube-dns” 提供的虛擬 IP 進行域名解析。

那么，既然 Pod 中 DNS 配置文件沒問題，且 CoreDNS 也沒問題，會不會是 Pod 本身域名解析不正常呢？或者 Service “kube-dns” 是否能夠正常轉發域名解析請求到 CoreDNS Pod 中？

當然，猜想是沒有用的，進行一下測試來觀察問題到底出在哪里。

進行觀察來定位問題所在

上面懷疑是 Pod 本身解析域名有問題，不能正常解析域名。或者 Pod 沒問題，但是請求域名解析時將請求發送到 Service “kube-dns” 后不能正常轉發請求到 CoreDNS Pod。為了驗證這兩點，我們可以修改 Pod 中的 /etc/resolv.conf 配置來進行測試驗證。

修改 resolv.conf 中 DNS 解析請求地址為阿里云 DNS 服務器地址，然后執行 ping 命令驗證是否為 Pod 解析域名是否有問題：

## 進入 dnsutils Pod 內部 sh 命令行 $ kubectl exec -it dnsutils /bin/sh -n kube-system## 編輯 /etc/resolv.conf 文件，修改 nameserver 參數為阿里云提供的 DNS 服務器地址 $ vi /etc/resolv.confnameserver 223.5.5.5 #nameserver 10.96.0.10 search kube-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5## 修改完后再進行 ping 命令測試，看看是否能夠解析 www.mydlq.club 網址 $ ping www.mydlq.clubPING www.mydlq.club (140.143.8.181) 56(84) bytes of data. 64 bytes from 140.143.8.181 (140.143.8.181): icmp_seq=1 ttl=128 time=9.70 ms 64 bytes from 140.143.8.181 (140.143.8.181): icmp_seq=2 ttl=128 time=9.21 ms## 退出 DNSutils Pod 命令行 $ exit

上面可也觀察到 Pod 中更換 DNS 服務器地址后，域名解析正常，說明 Pod 本身域名解析是沒有問題的。

接下來再修改 resolv.conf 中 DNS 解析請求地址為 CoreDNS Pod 的 IP 地址，這樣讓 Pod 直接連接 CoreDNS Pod 的 IP，而不通過 Service 進行轉發，再進行 ping 命令測試，進而判斷 Service kube-dns 是否能夠正常轉發請求到 CoreDNS Pod 的問題：

## 查看 CoreDNS Pod 的 IP 地址 $ kubectl get pods -n kube-system -o wide | grep corednscoredns-669f77d7cc-rss5f 1/1 Running 0 10.244.2.155 k8s-node-2-13 coredns-669f77d7cc-rt8l6 1/1 Running 0 10.244.1.163 k8s-node-2-12## 進入 dnsutils Pod 內部 sh 命令行 $ kubectl exec -it dnsutils /bin/sh -n kube-system## 編輯 /etc/resolv.conf 文件，修改 nameserver 參數為阿里云提供的 DNS 服務器地址 $ vi /etc/resolv.confnameserver 10.244.2.155 nameserver 10.244.1.163 #nameserver 10.96.0.10 search kube-system.svc.cluster.local svc.cluster.local cluster.local options ndots:5## 修改完后再進行 ping 命令測試，看看是否能夠解析 www.mydlq.club 網址 $ ping www.mydlq.clubPING www.baidu.com (39.156.66.18): 56 data bytes 64 bytes from 39.156.66.18: seq=0 ttl=127 time=6.054 ms 64 bytes from 39.156.66.18: seq=1 ttl=127 time=4.678 ms## 退出 DNSutils Pod 命令行 $ exit## 觀察 CoreDNS 日志信息，查看有無域名解析相關日志 $ for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); \ do kubectl logs --namespace=kube-system $p; done.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] 127.0.0.1:47278 - 55171 "HINFO IN 4940754309314083739.5160468069505858354. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.040844011s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete [INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000398875s [INFO] 10.244.1.162:40261 - 20812 "A IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000505793s [INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000215384s [INFO] 10.244.1.162:55066 - 53239 "A IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000267642s.:53 [INFO] plugin/reload: Running configuration MD5 = 6434d0912b39645ed0707a3569fd69dc CoreDNS-1.6.7 linux/amd64, go1.13.6, da7f65b [INFO] Reloading [INFO] plugin/health: Going into lameduck mode for 5s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete [INFO] 127.0.0.1:32896 - 49064 "HINFO IN 1027842207973621585.7098421666386159336. udp 57 false 512" NXDOMAIN qr,rd,ra 57 0.044098742s [INFO] plugin/reload: Running configuration MD5 = a4809ab99f6713c362194263016e6fac [INFO] Reloading complete [INFO] 10.244.1.162:40261 - 21083 "AAAA IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000217299s [INFO] 10.244.1.162:40261 - 20812 "A IN www.mydlq.club.kube-system.svc.cluster.local. udp 62 false 512" NXDOMAIN qr,aa,rd 155 0.000264552s [INFO] 10.244.1.162:55066 - 53460 "AAAA IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000144795s [INFO] 10.244.1.162:55066 - 53239 "A IN www.mydlq.club.svc.cluster.local. udp 50 false 512" NXDOMAIN qr,aa,rd 143 0.000221163s

經過上面兩個測試，已經可以得知，如果 Pod DNS 配置中直接修改 DNS 服務器地址為 CoreDNS Pod 的 IP 地址，DNS 解析確實沒有問題，能夠正常解析。不過，正常的情況下 Pod 中 DNS 配置的服務器地址一般是 CoreDNS 的 Service 地址，不直接綁定 Pod IP（因為 Pod 每次重啟 IP 都會發生變化）。所以問題找到了，正是在 Pod 向 CoreDNS 的 Service “kube-dns” 進行域名解析請求轉發時，出現了問題，一般 Service 的問題都跟 Kube-proxy 組件有關，接下來觀察該組件是否存在問題。

分析 Kube-Proxy 是否存在問題

觀察 Kube-proxy 的日志，查看是否存在問題：

## 查看 kube-proxy Pod 列表 $ kubectl get pods -n kube-system | grep kube-proxykube-proxy-6kdj2 1/1 Running 3 9h kube-proxy-lw2q6 1/1 Running 3 9h kube-proxy-mftlt 1/1 Running 3 9h## 選擇一個 kube-proxy Pod，查看最后 5 條日志內容 $ kubectl logs kube-proxy-6kdj2 --tail=5 -n kube-systemE0326 15:20:23.159364 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0] E0326 15:20:23.159388 1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/UPD, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0] E0326 15:20:23.159479 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0] E0326 15:20:23.159501 1 proxier.go:1192] Failed to sync endpoint for service: 10.8.0.10:53/TCP, err: parseIP Error ip=[10 96 0 16 0 0 0 0 0 0 0 0 0 0 0 0] E0326 15:20:23.159595 1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[10 96 0 10 0 0 0 0 0 0 0 0 0 0 0 0]

通過 kube-proxy Pod 的日志可以看到，里面有很多 Error 級別的日志信息，根據關鍵字 IPVS、parseIP Error 可知，可能是由于 IPVS 模塊對 IP 進行格式化導致出現問題。

因為這個問題是升級到 Kubernetes 1.18 版本才出現的，所以去 Kubernetes GitHub 查看相關 issues，發現有人在升級 Kubernetes 版本到 1.18 后，也遇見了相同的問題，經過 issue 中 Kubernetes 維護人員討論，分析出原因可能為新版 Kubernetes 使用的 IPVS 模塊是比較新的，需要系統內核版本支持，本人使用的是 CentOS 系統，內核版本為 3.10，里面的 IPVS 模塊比較老舊，缺少新版 Kubernetes IPVS 所需的依賴。

根據該 issue 討論結果，解決該問題的辦法是，更新內核為新的版本。

注：該 issues 地址為：https://github.com/kubernetes/ … 89520

解決問題

升級系統內核版本

升級 Kubernetes 集群各個節點的 CentOS 系統內核版本：

## 載入公鑰 $ rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org## 安裝 ELRepo 最新版本 $ yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm## 列出可以使用的 kernel 包版本 $ yum list available --disablerepo=* --enablerepo=elrepo-kernel## 安裝指定的 kernel 版本： $ yum install -y kernel-lt-4.4.218-1.el7.elrepo --enablerepo=elrepo-kernel## 查看系統可用內核 $ cat /boot/grub2/grub.cfg | grep menuentrymenuentry 'CentOS Linux (3.10.0-1062.el7.x86_64) 7 (Core)' --class centos （略） menuentry 'CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)' --class centos ...（略）## 設置開機從新內核啟動 $ grub2-set-default "CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)"## 查看內核啟動項 $ grub2-editenv list saved_entry=CentOS Linux (4.4.218-1.el7.elrepo.x86_64) 7 (Core)

重啟系統使內核生效：

$ reboot

啟動完成查看內核版本是否更新：

$ uname -r4.4.218-1.el7.elrepo.x86_64

測試 Pod 中 DNS 是否能夠正常解析

進入 Pod 內部使用 ping 命令測試 DNS 是否能正常解析：

## 進入 dnsutils Pod 內部 sh 命令行 $ kubectl exec -it dnsutils /bin/sh -n kube-system## Ping 集群外部，例如這里 ping 一下百度 $ ping www.baidu.com 64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=1 ttl=127 time=7.20 ms 64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=2 ttl=127 time=6.60 ms 64 bytes from 39.156.66.14 (39.156.66.14): icmp_seq=3 ttl=127 time=6.38 ms## Ping 集群內部 kube-api 的 Service 地址 $ ping kubernetes.default 64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=1 ttl=64 time=0.051 ms 64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=2 ttl=64 time=0.051 ms 64 bytes from kubernetes.default.svc.cluster.local (10.96.0.1): icmp_seq=3 ttl=64 time=0.064 ms

可以看到 Pod 中的域名解析已經恢復正常。

原文鏈接：http://www.mydlq.club/article/78/

總結

以上是生活随笔為你收集整理的【好文收藏】k8s中Pod 无法正常解析域名：部署 DNS 调试工具排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Linux安装ipvsadm工具查看ip
下一篇：【好文收藏】K8S集群部署CoreDNS