国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

搭建Kubernetes集群時DNS無法解析問題的處理過程

Berwin / 2163人閱讀

摘要:問題描述在搭建集群過程中,安裝了插件后,運行一個容器,發(fā)現(xiàn)容器內(nèi)無法解析集群外域名,一開始可以解析集群內(nèi)域名,一段時間后也無法解析集群內(nèi)域名。總結(jié)通過對問題的探究,也理解了集群中解析的完整過程,如圖。

問題描述

在搭建Kubernetes集群過程中,安裝了kube-dns插件后,運行一個ubuntu容器,發(fā)現(xiàn)容器內(nèi)無法解析集群外域名,一開始可以解析集群內(nèi)域名,一段時間后也無法解析集群內(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"
排查過程

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

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

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

查看后發(fā)現(xiàn)/etc/resolv.conf文件中存儲的是kube-dns的Service IP,證明這一步?jīng)]有問題,接下來查看一下kube-dns的Pod,先進入kube-dns的Pod中檢查一下/etc/resolv.conf文件,這里存儲的應(yīng)該是集群外部的DNS服務(wù)器地址,查看后發(fā)現(xiàn),這里存儲的地址是127.0.0.53,進一步查看kube-dns Pod的log,發(fā)現(xiàn)出現(xiàn)了非常多的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: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)問題的原因了,kube-dns只能解析集群內(nèi)部地址,而集群外部地址應(yīng)該發(fā)給外部DNS服務(wù)器進行解析,由于kube-dns Pod中的/etc/resolv.conf文件存儲的DNS服務(wù)器地址是127.0.0.53,127...*都是回環(huán)地址,也就是集群外域名的DNS解析請求會再次發(fā)送回kube-dns,導(dǎo)致形成一個循環(huán),這也是一秒鐘會出現(xiàn)幾十次i/o timeout日志的原因,請求會不斷的在kube-dns中循環(huán),kube-dns就像一個黑洞一樣,吃掉了所有dns解析請求,不斷累積的請求最終會導(dǎo)致整個集群的網(wǎng)絡(luò)出現(xiàn)卡頓。

為什么

雖然問題的原因找到了,但是為什么kube-dns Pod中/etc/resolv.conf文件存儲的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中繼承來的,查看Node中的/etc/resolv.conf文件,存儲的DNS服務(wù)器地址確實是127.0.0.53,那么下一個問題出現(xiàn)了,在Node中發(fā)送DNS解析請求為什么不會產(chǎn)生回環(huán)的問題呢?

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

怎么破

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

總結(jié)

通過對問題的探究,也理解了Kubernetes集群中DNS解析的完整過程,如圖。

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

參考內(nèi)容

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

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/8062.html

相關(guān)文章

  • 搭建Kubernetes集群DNS無法解析問題處理過程

    摘要:問題描述在搭建集群過程中,安裝了插件后,運行一個容器,發(fā)現(xiàn)容器內(nèi)無法解析集群外域名,一開始可以解析集群內(nèi)域名,一段時間后也無法解析集群內(nèi)域名。總結(jié)通過對問題的探究,也理解了集群中解析的完整過程,如圖。 showImg(https://segmentfault.com/img/remote/1460000015639330); 問題描述 在搭建Kubernetes集群過程中,安裝了kub...

    snowLu 評論0 收藏0
  • Kubernetes v1.0特性解析

    摘要:問題是不是定義的一個的容器集群是只部署在同一個主機上楊樂到目前是,同一個里的是部署在同一臺主機的。問題這個圖里的是安裝在哪里的所有的客戶端以及會連接這個嘛楊樂可以任意地方,只要能訪問到集群,會作為的出口。 kubernetes1.0剛剛發(fā)布,開源社區(qū)400多位貢獻者一年的努力,多達14000多次的代碼提交,最終達到了之前預(yù)計的milestone, 并意味著這個開源容器編排系統(tǒng)可以正式在...

    HackerShell 評論0 收藏0
  • 個推基于Docker和Kubernetes微服務(wù)實踐

    摘要:個推針對服務(wù)場景,基于和搭建了微服務(wù)框架,提高了開發(fā)效率。三容器化在微服務(wù)落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創(chuàng)新與速度的時代,由容器、微服務(wù)、DevOps構(gòu)成的云原生席卷整個IT界。個推針對Web服務(wù)場景,基于OpenResty和Node.js搭建了微服務(wù)框架,提高了開發(fā)效率。在微服...

    yibinnn 評論0 收藏0
  • 個推基于Docker和Kubernetes微服務(wù)實踐

    摘要:個推針對服務(wù)場景,基于和搭建了微服務(wù)框架,提高了開發(fā)效率。三容器化在微服務(wù)落地實踐時我們選擇了,下面將詳細介紹個推基于的實踐。 2016年伊始Docker無比興盛,如今Kubernetes萬人矚目。在這個無比需要創(chuàng)新與速度的時代,由容器、微服務(wù)、DevOps構(gòu)成的云原生席卷整個IT界。個推針對Web服務(wù)場景,基于OpenResty和Node.js搭建了微服務(wù)框架,提高了開發(fā)效率。在微服...

    genefy 評論0 收藏0
  • 手動搭建kubernetes集群

    摘要:手動搭建集群探索系列的第三篇,主要記錄手動搭建集群的過程,部署部署用作服務(wù)發(fā)現(xiàn)。配置的子網(wǎng)范圍不能和的一致。 手動搭建kubernetes集群 探索kubernetes系列的第三篇,主要記錄手動搭建k8s集群的過程,部署dashboard, 部署DNS用作服務(wù)發(fā)現(xiàn)。順便記錄一下k8s中的一些資源的概念。 配置環(huán)境 這個步驟可以參考《Flannel with Docker》文中的步驟,不...

    warnerwu 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<