摘要：?jiǎn)栴}描述在搭建集群過(guò)程中，安裝了插件后，運(yùn)行一個(gè)容器，發(fā)現(xiàn)容器內(nèi)無(wú)法解析集群外域名，一開(kāi)始可以解析集群內(nèi)域名，一段時(shí)間后也無(wú)法解析集群內(nèi)域名?？偨Y(jié)通過(guò)對(duì)問(wèn)題的探究，也理解了集群中解析的完整過(guò)程，如圖。

問(wèn)題描述

在搭建Kubernetes集群過(guò)程中，安裝了kube-dns插件后，運(yùn)行一個(gè)ubuntu容器，發(fā)現(xiàn)容器內(nèi)無(wú)法解析集群外域名，一開(kāi)始可以解析集群內(nèi)域名，一段時(shí)間后也無(wú)法解析集群內(nèi)域名。

$ nslookup kubernetes.default
Server:    10.99.0.2
Address 1: 10.99.0.2 kube-dns.kube-system.svc.cluster.local

nslookup: can"t resolve "kubernetes.default"

在排查問(wèn)題前，先思考一下Kubernetes集群中的DNS解析過(guò)程，在安裝好kube-dns的集群中，普通Pod的dnsPolicy屬性是默認(rèn)值ClusterFirst，也就是會(huì)指向集群內(nèi)部的DNS服務(wù)器，kube-dns負(fù)責(zé)解析集群內(nèi)部的域名，kube-dns Pod的dnsPolicy值是Default，意思是從所在Node繼承DNS服務(wù)器，對(duì)于無(wú)法解析的外部域名，kube-dns會(huì)繼續(xù)向集群外部的dns進(jìn)行查詢，過(guò)程如圖。

Ubuntu容器是一個(gè)普通的Pod，在Linux系統(tǒng)中，/etc/resolv.conf是存儲(chǔ)DNS服務(wù)器的文件，普通Pod的/etc/resolv.conf文件應(yīng)該存儲(chǔ)的是kube-dns的Service IP。

nameserver 10.99.0.2  # 這里存儲(chǔ)的是kube-dns的Service IP
search default.svc.cluster.local. svc.cluster.local. cluster.local.
options ndots:5

查看后發(fā)現(xiàn)/etc/resolv.conf文件中存儲(chǔ)的是kube-dns的Service IP，證明這一步?jīng)]有問(wèn)題，接下來(lái)查看一下kube-dns的Pod，先進(jìn)入kube-dns的Pod中檢查一下/etc/resolv.conf文件，這里存儲(chǔ)的應(yīng)該是集群外部的DNS服務(wù)器地址，查看后發(fā)現(xiàn)，這里存儲(chǔ)的地址是127.0.0.53，進(jìn)一步查看kube-dns Pod的log，發(fā)現(xiàn)出現(xiàn)了非常多的i/o timeout錯(cuò)誤。

 2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:38019->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:57567->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:52599->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:42539->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:46885->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:44189->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:56505->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:47320->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:42464->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:49203->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:58103->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:47148->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:36883->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:40968->127.0.0.53:53: i/o timeout
2018/07/11 07:12:47 [ERROR] 2 [www.baidu.com](http://www.baidu.com/). A: unreachable backend: read udp 127.0.0.1:55672->127.0.0.53:53: i/o timeout

現(xiàn)在基本上可以發(fā)現(xiàn)問(wèn)題的原因了，kube-dns只能解析集群內(nèi)部地址，而集群外部地址應(yīng)該發(fā)給外部DNS服務(wù)器進(jìn)行解析，由于kube-dns Pod中的/etc/resolv.conf文件存儲(chǔ)的DNS服務(wù)器地址是127.0.0.53，127...*都是回環(huán)地址，也就是集群外域名的DNS解析請(qǐng)求會(huì)再次發(fā)送回kube-dns，導(dǎo)致形成一個(gè)循環(huán)，這也是一秒鐘會(huì)出現(xiàn)幾十次i/o timeout日志的原因，請(qǐng)求會(huì)不斷的在kube-dns中循環(huán)，kube-dns就像一個(gè)黑洞一樣，吃掉了所有dns解析請(qǐng)求，不斷累積的請(qǐng)求最終會(huì)導(dǎo)致整個(gè)集群的網(wǎng)絡(luò)出現(xiàn)卡頓。

為什么

雖然問(wèn)題的原因找到了，但是為什么kube-dns Pod中/etc/resolv.conf文件存儲(chǔ)的DNS服務(wù)器是127.0.0.53？

kube-dns Pod的dnsPolicy值是Default，查看一下Kubernetes文檔。

"Default": The Pod inherits the name resolution configuration from the node that the pods run on. See?related discussion?for more details.

所以kube-dns的/etc/resolv.conf文件是從Node中繼承來(lái)的，查看Node中的/etc/resolv.conf文件，存儲(chǔ)的DNS服務(wù)器地址確實(shí)是127.0.0.53，那么下一個(gè)問(wèn)題出現(xiàn)了，在Node中發(fā)送DNS解析請(qǐng)求為什么不會(huì)產(chǎn)生回環(huán)的問(wèn)題呢？

Node使用的是Ubuntu 18.04 Server，在這個(gè)版本的系統(tǒng)中，DNS解析請(qǐng)求并不是直接發(fā)給所在網(wǎng)絡(luò)的DNS服務(wù)器的，Ubuntu 18.04中有一個(gè)systemd-resolved服務(wù)，為本地應(yīng)用程序提供了DNS解析服務(wù)，例如nslookup localhost，解析程序從/etc/resolv.conf文件中找到DNS服務(wù)器127.0.0.53，發(fā)送解析請(qǐng)求，systemd-resolved會(huì)監(jiān)聽(tīng)在53端口上，捕獲到解析請(qǐng)求后，如果是自己可以解析的，例如localhost，會(huì)直接返回127.0.0.1，如果不能解析，才會(huì)發(fā)送給外部服務(wù)器，而外部服務(wù)器的地址存儲(chǔ)在/run/systemd/resolve/resolv.conf文件中，這個(gè)文件是systemd-resolved服務(wù)器的配置文件，過(guò)程如圖。

怎么破

理解了問(wèn)題的來(lái)龍去脈，解決問(wèn)題的辦法也就應(yīng)運(yùn)而生。在Kubernetes集群中，kubelet是worker組建，負(fù)責(zé)管理Pod，根據(jù)kubernetes文檔，kubelet默認(rèn)會(huì)從Node的/etc/resolv.conf文件讀取DNS服務(wù)器地址，使得dnsPolicy是Default的Pod得以繼承，kubelet中的--resolv-conf參數(shù)可以指定這個(gè)配置文件的地址。在Ubuntu 18.04中，將這個(gè)參數(shù)設(shè)置為systemd-resolved的DNS服務(wù)器配置文件/run/systemd/resolve/resolv.conf，Pod就會(huì)繼承真正的外部DNS服務(wù)器。

通過(guò)對(duì)問(wèn)題的探究，也理解了Kubernetes集群中DNS解析的完整過(guò)程，如圖。

* 在Ubuntu 16.04中也是類似的邏輯，只不過(guò)systemd-resolved換成了dnsmasq，監(jiān)聽(tīng)地址是127.0.1.1
* 在具體實(shí)踐過(guò)程中，也順便探究了CoreDNS和KubeDNS架構(gòu)和解析邏輯上的區(qū)別，不過(guò)不在此問(wèn)題的討論范圍，有興趣的朋友可以自己看一下。
* 如果Kubernetes集群是安裝在NAT網(wǎng)絡(luò)下的虛擬機(jī)上，虛擬機(jī)（也就是Kubernetes集群中的Node）中/etc/resolv.conf文件可能被修改為NAT的地址，也就不會(huì)出現(xiàn)上面這個(gè)問(wèn)題。

https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/
https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
https://github.com/kubernetes/kubernetes/issues/49411
https://github.com/kubernetes/kubernetes/issues/45828