（轉）CoreDNS：Kubernetes內部域名解析原理、弊端及優化方式
Kubernetes 中的 DNS
本篇主要儘可能詳盡的說明 Kubernetes 的DNS解析原理，以及 Kubernetes 叢集中 DNS 解析目前存在的弊端和優化方式。
在 Kubernetes 中，服務發現有幾種方式：
①：基於環境變數的方式
②：基於內部域名的方式
基本上，使用環境變數的方式很少，主要還是使用內部域名這種服務發現的方式。
其中，基於內部域名的方式，涉及到 Kubernetes 內部域名的解析，而 kubedns，是 Kubernetes 官方的 DNS 解析元件。從 1.11 版本開始，kubeadm 已經使用第三方的 CoreDNS 替換官方的 kubedns 作為 Kubernetes 叢集的內部域名解析元件，我們的重點，是 CoreDNS，但是在開始 CoreDNS 之前，需要先了解下 kubedns，後續，會對這2個 DNS 元件做對比，分析它們的優劣勢。
Kubernetes 中的域名是如何解析
在 Kubernetes 中，比如服務 a 訪問服務 b，對於同一個 Namespace下，可以直接在 pod 中，通過 curl b 來訪問。對於跨 Namespace 的情況，服務名後邊對應 Namespace即可。比如 curl b.default。那麼，使用者這裡邊會有幾個問題：
①：服務名是什麼？
②：為什麼同一個 Namespace 下，直接訪問服務名即可？不同 Namespace 下，需要帶上 Namespace 才行？
③：為什麼內部的域名可以做解析，原理是什麼？
DNS 如何解析，依賴容器內 resolv 檔案的配置
cat /etc/resolv.conf nameserver 10.233.0.3 search default.svc.cluster.local svc.cluster.local cluster.local
這個檔案中，配置的 DNS Server，一般就是 K8S 中，kubedns 的 Service 的 ClusterIP，這個IP是虛擬IP，無法ping，但可以訪問。
[root@node4 user1]# kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.233.0.3 <none> 53/UDP,53/TCP 270d kubernetes-dashboard ClusterIP 10.233.22.223 <none> 443/TCP 124d
所以，所有域名的解析，其實都要經過 kubedns 的虛擬IP 10.233.0.3 進行解析，不論是 Kubernetes 內部域名還是外部的域名。
Kubernetes 中，域名的全稱，必須是 service-name.namespace.svc.cluster.local 這種模式，服務名，就是Kubernetes中 Service 的名稱，所以，當我們執行下面的命令時：
curl b
必須得有一個 Service 名稱為 b，這是前提。
在容器內，會根據 /etc/resolve.conf 進行解析流程。選擇 nameserver 10.233.0.3 進行解析，然後，用字串 “b”，依次帶入 /etc/resolve.conf 中的 search 域，進行DNS查詢，分別是：
// search 內容類似如下（不同的pod，第一個域會有所不同） search default.svc.cluster.local svc.cluster.local cluster.local
b.default.svc.cluster.local -> b.svc.cluster.local -> b.cluster.local ，直到找到為止。
所以，我們執行 curl b，或者執行 curl b.default，都可以完成DNS請求，這2個不同的操作，會分別進行不同的DNS查詢步驟：
// curl b，可以一次性找到（b +default.svc.cluster.local） b.default.svc.cluster.local // curl b.default，第一次找不到（ b.default + default.svc.cluster.local） b.default.default.svc.cluster.local // 第二次查詢（ b.default + svc.cluster.local），可以找到 b.default.svc.cluster.local
So Questions
curl b，要比 curl b.default 效率高？
答案是肯定的，因為 curl b.default，多經過了一次 DNS 查詢。
當執行 curl b.default，也就使用了帶有名稱空間的內部域名時，容器的第一個 DNS 請求是
// b.default + default.svc.cluster.local b.default.default.svc.cluster.local
當請求不到 DNS 結果時，使用
// b.default + svc.cluster.local b.default.svc.cluster.local
進行請求，此時才可以得到正確的DNS解析。
訪問外部域名走 search 域嗎
這個答案，不能說肯定也不能說否定，看情況，可以說，大部分情況要走 search 域。
我們以請求 youku.com 為例，通過抓包的方式，看一看在某個容器中訪問 youku.com，進行的DNS查詢的過程，都產生了什麼樣的資料包。注意：我們要抓DNS容器的包，就得先進入到DNS容器的網路中（而不是發起DNS請求的那個容器）。
由於DNS容器往往不具備bash，所以無法通過 docker exec 的方式進入容器內抓包，我們採用其他的方式：
// 1、找到容器ID，並列印它的NS ID
docker inspect --format "{{.State.Pid}}" 16938de418ac
// 2、進入此容器的網路Namespace
nsenter -n -t 54438
// 3、抓DNS包
tcpdump -i eth0 udp dst port 53|grep youku.com
在其他的容器中，進行 youku.com 域名查詢
nslookup youku.com 172.22.121.65
注意：nslookup命令的最後指定DNS服務容器的IP，是因為，如果不指定，且DNS服務的容器存在多個的話，那麼DNS請求，可能會均分到所有DNS服務的容器上，我們如果只抓某單個DNS服務容器抓到的包，可能就不全了，指定IP後，DNS的請求，就必然只會打到單個的DNS容器。抓包的資料才完整。
可以看到類似如下結果：
17:01:28.732260 IP 172.20.92.100.36326 > nodexxxx.domain: 4394+ A? youku.com.default.svc.cluster.local. (50) 17:01:28.733158 IP 172.20.92.100.49846 > nodexxxx.domain: 60286+ A? youku.com.svc.cluster.local. (45) 17:01:28.733888 IP 172.20.92.100.51933 > nodexxxx.domain: 63077+ A? youku.com.cluster.local. (41) 17:01:28.734588 IP 172.20.92.100.33401 > nodexxxx.domain: 27896+ A? youku.com. (27) 17:01:28.734758 IP nodexxxx.34138 > 192.168.x.x.domain: 27896+ A? youku.com. (27)
我們可以看到，在真正解析 youku.com 之前，經歷了 youku.com.default.svc.cluster.local. -> youku.com.svc.cluster.local. -> youku.com.cluster.local. -> youku.com.
這也就意味著有3次DNS請求，是浪費的無意義的請求。
為何會出現DNS請求浪費的情況
這是因為，在 Kubernetes 中，其實 /etc/resolv.conf 這個檔案，並不止包含 nameserver 和 search 域，還包含了非常重要的一項：ndots。我們之前沒有提及這個項，也是希望再次能引起讀者重視。
[root@xxxx-67f54c6dff-h4zxq /]# cat /etc/resolv.conf nameserver 10.233.0.3 search cicd.svc.cluster.local svc.cluster.local cluster.local options ndots:5
ndots:5，表示：如果查詢的域名包含的點“.”，不到5個，那麼進行DNS查詢，將使用非完全限定名稱（或者叫絕對域名），如果你查詢的域名包含點數大於等於5，那麼DNS查詢，預設會使用絕對域名進行查詢。舉例來說：
如果我們請求的域名是，a.b.c.d.e，這個域名中有4個點，那麼容器中進行DNS請求時，會使用非絕對域名進行查詢，使用非絕對域名，會按照 /etc/resolv.conf 中的 search 域，走一遍追加匹配：
a.b.c.d.e.cicd.svc.cluster.local. -> a.b.c.d.e.svc.cluster.local. -> a.b.c.d.e.cluster.local.
直到找到為止。如果走完了search域還找不到，則使用 a.b.c.d.e. ，作為絕對域名進行DNS查詢。
我們通過抓包分析一個具體案例：
域名中點數少於5個的情況：
// 對域名 a.b.c.d.ccccc 進行DNS解析請求 [root@xxxxx-67f54c6dff-h4zxq /]# nslookup a.b.c.d.ccccc 172.22.121.65 Server: 172.22.121.65 Address: 172.22.121.65#53 ** server can't find a.b.c.d.ccccc: NXDOMAIN // 抓包資料如下： 18:08:11.013497 IP 172.20.92.100.33387 > node011094.domain: 28844+ A? a.b.c.d.ccccc.cicd.svc.cluster.local. (54) 18:08:11.014337 IP 172.20.92.100.33952 > node011094.domain: 57782+ A? a.b.c.d.ccccc.svc.cluster.local. (49) 18:08:11.015079 IP 172.20.92.100.45984 > node011094.domain: 55144+ A? a.b.c.d.ccccc.cluster.local. (45) 18:08:11.015747 IP 172.20.92.100.54589 > node011094.domain: 22860+ A? a.b.c.d.ccccc. (31) 18:08:11.015970 IP node011094.36383 > 192.168.x.x.domain: 22860+ A? a.b.c.d.ccccc. (31)
// 結論：
// 點數少於5個，先走search域，最後將其視為絕對域名進行查詢
域名中點數>=5個的情況：
// 對域名 a.b.c.d.e.ccccc 進行DNS解析請求 [root@xxxxx-67f54c6dff-h4zxq /]# nslookup a.b.c.d.e.ccccc 172.22.121.65 Server: 172.22.121.65 Address: 172.22.121.65#53 ** server can't find a.b.c.d.e.ccccc: NXDOMAIN // 抓包資料如下： 18:10:14.514595 IP 172.20.92.100.34423 > node011094.domain: 61170+ A? a.b.c.d.e.ccccc. (33) 18:10:14.514856 IP node011094.58522 > 192.168.x.x.domain: 61170+ A? a.b.c.d.e.ccccc. (33) 18:10:14.515880 IP 172.20.92.100.49328 > node011094.domain: 267+ A? a.b.c.d.e.ccccc.cicd.svc.cluster.local. (56) 18:10:14.516678 IP 172.20.92.100.35651 > node011094.domain: 54181+ A? a.b.c.d.e.ccccc.svc.cluster.local. (51) 18:10:14.517356 IP 172.20.92.100.33259 > node011094.domain: 53022+ A? a.b.c.d.e.ccccc.cluster.local. (47) // 結論： // 點數>=5個，直接視為絕對域名進行查詢，只有當查詢不到的時候，才繼續走 search 域。
如何優化 DNS 請求浪費的情況
優化方式1：使用全限定域名
其實最直接，最有效的優化方式，就是使用 “fully qualified name”，簡單來說，使用“完全限定域名”（也叫絕對域名），你訪問的域名，必須要以 “.” 為字尾，這樣就會避免走 search 域進行匹配，我們抓包再試一次：
// 注意：youku.com 後邊有一個點 . nslookup youku.com. 172.22.121.65
在DNS服務容器上抓到的包如下：
16:57:07.628112 IP 172.20.92.100.36772 > nodexxxx.domain: 46851+ [1au] A? youku.com. (38) 16:57:07.628339 IP nodexxxx.47350 > 192.168.x.x.domain: 46851+ [1au] A? youku.com. (38)
並沒有多餘的DNS請求。
優化方式2：具體應用配置特定的 ndots
其實，往往我們還真不太好用這種絕對域名的方式，有誰請求youku.com的時候，還寫成 youku.com. 呢？
在 Kubernetes 中，預設設定了 ndots 值為5，是因為，Kubernetes 認為，內部域名，最長為5，要保證內部域名的請求，優先走叢集內部的DNS，而不是將內部域名的DNS解析請求，有打到外網的機會，Kubernetes 設定 ndots 為5是一個比較合理的行為。
如果你需要定製這個長度，最好是為自己的業務，單獨配置 ndots 即可（Pod為例，其實配置deployment最好）。
apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsConfig: options: - name: ndots value: "1"
Kubernetes DNS 策略
在Kubernetes 中，有4種 DNS 策略，從 Kubernetes 原始碼中看：
const ( // DNSClusterFirstWithHostNet indicates that the pod should use cluster DNS // first, if it is available, then fall back on the default // (as determined by kubelet) DNS settings. DNSClusterFirstWithHostNet DNSPolicy = "ClusterFirstWithHostNet" // DNSClusterFirst indicates that the pod should use cluster DNS // first unless hostNetwork is true, if it is available, then // fall back on the default (as determined by kubelet) DNS settings. DNSClusterFirst DNSPolicy = "ClusterFirst" // DNSDefault indicates that the pod should use the default (as // determined by kubelet) DNS settings. DNSDefault DNSPolicy = "Default" // DNSNone indicates that the pod should use empty DNS settings. DNS // parameters such as nameservers and search paths should be defined via // DNSConfig. DNSNone DNSPolicy = "None" )
這幾種DNS策略，需要在Pod，或者Deployment、RC等資源中，設定 dnsPolicy 即可，以 Pod 為例：
apiVersion: v1
kind: Pod
metadata:
labels:
name: cadvisor-nodexxxx
hostip: 192.168.x.x
name: cadvisor-nodexxxx
namespace: monitoring
spec:
containers:
- args:
- --profiling
- --housekeeping_interval=10s
- --storage_duration=1m0s
image: google/cadvisor:latest
name: cadvisor-nodexxxx
ports:
- containerPort: 8080
name: http
protocol: TCP
resources: {}
securityContext:
privileged: true
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeName: nodexxxx
具體來說：
None
表示空的DNS設定
這種方式一般用於想要自定義 DNS 配置的場景，而且，往往需要和 dnsConfig 配合一起使用達到自定義 DNS 的目的。
Default
有人說 Default 的方式，是使用宿主機的方式，這種說法並不準確。
這種方式，其實是，讓 kubelet 來決定使用何種 DNS 策略。而 kubelet 預設的方式，就是使用宿主機的 /etc/resolv.conf（可能這就是有人說使用宿主機的DNS策略的方式吧），但是，kubelet 是可以靈活來配置使用什麼檔案來進行DNS策略的，我們完全可以使用 kubelet 的引數：–resolv-conf=/etc/resolv.conf 來決定你的DNS解析檔案地址。
ClusterFirst
這種方式，表示 POD 內的 DNS 使用叢集中配置的 DNS 服務，簡單來說，就是使用 Kubernetes 中 kubedns 或 coredns 服務進行域名解析。如果解析不成功，才會使用宿主機的 DNS 配置進行解析。
ClusterFirstWithHostNet
在某些場景下，我們的 POD 是用 HOST 模式啟動的（HOST模式，是共享宿主機網路的），一旦用 HOST 模式，表示這個 POD 中的所有容器，都要使用宿主機的 /etc/resolv.conf 配置進行DNS查詢，但如果你想使用了 HOST 模式，還繼續使用 Kubernetes 的DNS服務，那就將 dnsPolicy 設定為 ClusterFirstWithHostNet。
轉自：https://blog.csdn.net/h952520296/article/details/106816680/