前幾天我們在解決 CoreDNS 的5秒超時問題的時候，使用了 NodeLocal DNSCache 來解決這個問題，集群 DNS 的解析性能也明顯大幅提升了。但是今天確遇到一個很大的坑，我們在做 DevOps 實驗的時候，相關(guān)的工具都使用的是自定義的域名，這個時候要互相訪問的話就需要添加自定義的域名解析，我們可以通過給 Pod 添加 hostAlias 來解決，但是在使用 Jenkins 的 Kubernetes 插件的時候卻不支持這個參數(shù)，需要使用 YAML 來自定義，比較麻煩，所以想著通過 CoreDNS 來添加 A 記錄解決這個問題。
正常我們只需要在 CoreDNS 的 ConfigMap 中添加 hosts 插件就可以使用了：
hosts { 10.151.30.11 git.k8s.local fallthrough}
但是在配置完成后，始終解析不了這個自定義的域名：
$ 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\\\’
這有點奇怪，難道 hosts 插件不能這樣使用嗎？在經(jīng)過一番查閱過后確信這樣配置是正確的方式。然后將 CoreDNS 的日志開啟，來過濾上面域名的解析日志：
可以看到走了一遍 search 域，但是沒有獲取到正確的解析結(jié)果，這就有點不解了。在折騰了一番過后，想到我們在集群中啟用了 NodeLocalDNSCache，難道是這個組件導(dǎo)致的嗎？這個不是解析沒有命中的時候會轉(zhuǎn)發(fā)到 CoreDNS 查詢嗎？
為了驗證這個問題，我們就直接使用 CoreDNS 的地址來進行解析測試一番：
/ # 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)確實是失敗的：
/ # nslookup git.k8s.local 169.254.20.10Server: 169.254.20.10Address 1: 169.254.20.10nslookup: can\\\’t resolve \\\’git.k8s.local\\\’
這個時候只能去查看 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,
仔細分析上面的 LocalDNS 的配置信息，其中 10.96.0.10 為 CoreDNS 的 Service ClusterIP，169.254.20.10 為 LocalDNS 的 IP 地址，10.96.207.156 是 LocalDNS 新建的一個 Service ClusterIP，該 Service 和 CoreDNS 一樣都是關(guān)聯(lián)以前的 CoreDNS 的 Endpoints 列表。
仔細觀察可以發(fā)現(xiàn) cluster.local、 in-addr.arpa 以及 ip6.arpa 都會通過 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 的時候需要走一遍搜索域，而 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}……
更新完成后，我們可以手動重建 NodeLocalDNS Pod，重建過后發(fā)現(xiàn) NodeLocalDNS 的 Pod 啟動失敗了，會出現(xiàn)如下所示的錯誤信息：
no action found for directive \\\’hosts\\\’ with server type \\\’dns\\\’
原來壓根就不支持 hosts 這個插件。那么我們就只有去 CoreDNS 解析了，所以這個時候我們需要把 forward./etc/resolv.conf 更改成 forward.10.96.207.156，這樣就會去 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 才會生效。
__PILLAR__CLUSTER__DNS__ 和 __PILLAR__UPSTREAM__SERVERS__ 這兩個參數(shù)在鏡像 1.15.6 版本以上中會自動進行配置，對應(yīng)的值來源于 kube-dns 的 ConfigMap 和定制的 Upstream Server 地址。
現(xiàn)在我們再去測試就可以正常解析自定義的域名了：
/ # nslookup git.k8s.localServer: 169.254.20.10Address 1: 169.254.20.10Name: git.k8s.localAddress 1: 10.151.30.11 git.k8s.local
對于使用 NodeLocalDNS 的用戶一定要注意這個問題，如果使用 hosts 或者 rewrite 插件失效，基本上就是這個問題造成的。排查問題通過日志去分析始終是最好的手段。
云原生公開課第二期直播預(yù)告
更多關(guān)于云服務(wù)器，域名注冊，虛擬主機的問題，請訪問三五互聯(lián)官網(wǎng)：www.shinetop.cn