來自專輯 K8S訓(xùn)練營(yíng)摘錄

前幾天我們?cè)诮鉀Q CoreDNS 的5秒超時(shí)問題的時(shí)候，使用了 NodeLocal DNSCache 來解決這個(gè)問題，集群 DNS 的解析性能也明顯大幅提升了。但是今天確遇到一個(gè)很大的坑，我們?cè)谧?DevOps 實(shí)驗(yàn)的時(shí)候，相關(guān)的工具都使用的是自定義的域名，這個(gè)時(shí)候要互相訪問的話就需要添加自定義的域名解析，我們可以通過給 Pod 添加 hostAlias 來解決，但是在使用 Jenkins 的 Kubernetes 插件的時(shí)候卻不支持這個(gè)參數(shù)，需要使用 YAML 來自定義，比較麻煩，所以想著通過 CoreDNS 來添加 A 記錄解決這個(gè)問題。

成都創(chuàng)新互聯(lián)公司專注于懷仁網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供懷仁營(yíng)銷型網(wǎng)站建設(shè)，懷仁網(wǎng)站制作、懷仁網(wǎng)頁(yè)設(shè)計(jì)、懷仁網(wǎng)站官網(wǎng)定制、微信小程序開發(fā)服務(wù)，打造懷仁網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供懷仁網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

正常我們只需要在 CoreDNS 的 ConfigMap 中添加 hosts 插件就可以使用了：

hosts { 10.151.30.11 git.k8s.local fallthrough}

但是在配置完成后，始終解析不了這個(gè)自定義的域名：

$ kubectl run -it --image busybox:1.28.4 test --restart=Never --rm /bin/shIf you don\'t see a command prompt, try pressing enter./ # nslookup git.k8s.localServer: 169.254.20.10Address 1: 169.254.20.10nslookup: can\'t resolve \'git.k8s.local\'

這有點(diǎn)奇怪，難道 hosts 插件不能這樣使用嗎？在經(jīng)過一番查閱過后確信這樣配置是正確的方式。然后將 CoreDNS 的日志開啟，來過濾上面域名的解析日志：

可以看到走了一遍 search 域，但是沒有獲取到正確的解析結(jié)果，這就有點(diǎn)不解了。在折騰了一番過后，想到我們?cè)诩褐袉⒂昧?NodeLocalDNSCache，難道是這個(gè)組件導(dǎo)致的嗎？這個(gè)不是解析沒有命中的時(shí)候會(huì)轉(zhuǎn)發(fā)到 CoreDNS 查詢嗎？

為了驗(yàn)證這個(gè)問題，我們就直接使用 CoreDNS 的地址來進(jìn)行解析測(cè)試一番：

/ # nslookup git.k8s.local 10.96.0.10Server: 10.96.0.10Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName: git.k8s.localAddress 1: 10.151.30.11 git.k8s.local

發(fā)現(xiàn)居然是正確的，那也就說明 CoreDNS 的配置是沒有任何問題的，問題肯定就是 NodeLocalDNSCache 導(dǎo)致的，直接用 LocalDNS 的地址（169.254.20.10）解析發(fā)現(xiàn)確實(shí)是失敗的：

/ # nslookup git.k8s.local 169.254.20.10Server: 169.254.20.10Address 1: 169.254.20.10nslookup: can\'t resolve \'git.k8s.local\'

這個(gè)時(shí)候只能去查看 LocalDNS 的 Pod 日志了：

$ kubectl logs -f node-local-dns-bb84m -n kube-system......2020/05/14 05:30:21 [INFO] Updated Corefile with 0 custom stubdomains and upstream servers /etc/resolv.conf2020/05/14 05:30:21 [INFO] Using config file:cluster.local:53 { errors cache { success 9984 30 denial 9984 5 } reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 health 169.254.20.10:8080 }in-addr.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }ip6.arpa:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . 10.96.207.156 { force_tcp } prometheus :9253 }.:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . /etc/resolv.conf { force_tcp } prometheus :9253 }......[INFO] plugin/reload: Running configuration MD5 = 3e3833f9361872f1d34bc97155f952caCoreDNS-1.6.7linux/amd64, go1.11.13,

仔細(xì)分析上面的 LocalDNS 的配置信息，其中 10.96.0.10 為 CoreDNS 的 Service ClusterIP，169.254.20.10 為 LocalDNS 的 IP 地址，10.96.207.156 是 LocalDNS 新建的一個(gè) Service ClusterIP，該 Service 和 CoreDNS 一樣都是關(guān)聯(lián)以前的 CoreDNS 的 Endpoints 列表。

仔細(xì)觀察可以發(fā)現(xiàn) cluster.local、 in-addr.arpa 以及 ip6.arpa 都會(huì)通過 forward 轉(zhuǎn)發(fā)到 10.96.207.156，也就是去 CoreDNS 解析，其他的則是 forward./etc/resolv.conf 通過 resolv.conf 文件去解析，該文件的內(nèi)容如下所示：

nameserver 169.254.20.10search default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:5

所以當(dāng)我們解析域名 git.k8s.local 的時(shí)候需要走一遍搜索域，而 cluster.local 的域名是直接 forward 到 CoreDNS 解析的，CoreDNS 自然解析不出來這幾天記錄了。那么我們是不是自然可以想到把 hosts 插件配置在 LocalDNS 這邊不就可以了嗎？這種思路應(yīng)該是完全正確的：

$ kubectl edit cm node-local-dns -n kube-system.......:53 { errors hosts { # 添加 A 記錄 10.151.30.11 git.k8s.local fallthrough } cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . __PILLAR__UPSTREAM__SERVERS__ { force_tcp } prometheus :9253}......

更新完成后，我們可以手動(dòng)重建 NodeLocalDNS Pod，重建過后發(fā)現(xiàn) NodeLocalDNS 的 Pod 啟動(dòng)失敗了，會(huì)出現(xiàn)如下所示的錯(cuò)誤信息：

no action found for directive \'hosts\' with server type \'dns\'

原來壓根就不支持 hosts 這個(gè)插件。那么我們就只有去 CoreDNS 解析了，所以這個(gè)時(shí)候我們需要把 forward./etc/resolv.conf 更改成 forward.10.96.207.156，這樣就會(huì)去 CoreDNS 解析了，在 NodeLocalDNS 的 ConfigMap 中做如下的修改即可：

$ kubectl edit cm node-local-dns -n kube-system.......:53 { errors cache 30 reload loop bind 169.254.20.10 10.96.0.10 forward . __PILLAR__CLUSTER__DNS__ { force_tcp } prometheus :9253}......

同樣修改完成后，需要重建 NodeLocalDNS 的 Pod 才會(huì)生效。

__PILLAR__CLUSTER__DNS__ 和 __PILLAR__UPSTREAM__SERVERS__ 這兩個(gè)參數(shù)在鏡像 1.15.6 版本以上中會(huì)自動(dòng)進(jìn)行配置，對(duì)應(yīng)的值來源于 kube-dns 的 ConfigMap 和定制的 Upstream Server 地址。

現(xiàn)在我們?cè)偃y(cè)試就可以正常解析自定義的域名了：

/ # nslookup git.k8s.localServer: 169.254.20.10Address 1: 169.254.20.10Name: git.k8s.localAddress 1: 10.151.30.11 git.k8s.local

對(duì)于使用 NodeLocalDNS 的用戶一定要注意這個(gè)問題，如果使用 hosts 或者 rewrite 插件失效，基本上就是這個(gè)問題造成的。排查問題通過日志去分析始終是最好的手段。

---

云原生公開課第二期直播預(yù)告

文章名稱：CoreDNS自定義域名失效問題\"
文章來源：http://www.rwnh.cn/article2/cposoc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)公司、小程序開發(fā)、電子商務(wù)、手機(jī)網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)