知識星球
https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
作者 | Zwischenzugs
譯者 | Andy Song (pinewall) ????共計翻譯：38.0 篇 貢獻時間：170 天
在 Linux DNS 查詢剖析（第一部分）[1]，Linux DNS 查詢剖析（第二部分）[2] 和 Linux DNS 查詢剖析（第三部分）[3] 中，我們已經介紹了以下內容：
nsswitch/etc/hosts/etc/resolv.confping 與 host 查詢方式的對比systemd 和對應的 networking 服務ifup 和 ifdowndhclientresolvconfNetworkManagerdnsmasq在第四部分中，我將介紹容器如何完成 DNS 查詢。你想的沒錯，也不是那麼簡單。
1) Docker 和 DNS
在 Linux DNS 查詢剖析（第三部分）[3] 中，我們介紹了 dnsmasq，其工作方式如下：將 DNS 查詢指向到 localhost 地址 127.0.0.1，同時啟動一個行程監聽 53 埠並處理查詢請求。
在按上述方式配置 DNS 的主機上，如果運行了一個 Docker 容器，容器內的 /etc/resolv.conf 檔案會是怎樣的呢？
我們來動手試驗一下吧。
按照預設 Docker 建立流程，可以看到如下的預設輸出：
$ docker run ubuntu cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
search home
nameserver 8.8.8.8
nameserver 8.8.4.4
奇怪！
地址 8.8.8.8 和 8.8.4.4 從何而來呢？
當我思考容器內的 /etc/resolv.conf 配置時，我的第一反應是繼承主機的 /etc/resolv.conf。但只要稍微進一步分析，就會發現這樣並不總是有效的。
如果在主機上配置了 dnsmasq，那麼 /etc/resolv.conf 檔案總會指向 127.0.0.1這個迴環地址。如果這個地址被容器繼承，容器會在其本身的網路背景關係中使用；由於容器內並沒有執行（在 127.0.0.1 地址的）DNS 伺服器，因此 DNS 查詢都會失敗。
“有了！”你可能有了新主意：將 主機的 的 IP 地址用作 DNS 伺服器地址，其中這個 IP 地址可以從容器的預設路由中獲取：
root@79a95170e679:/# ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
使用主機 IP 地址真的可行嗎？
從預設路由中，我們可以找到主機的 IP 地址 172.17.0.1，進而可以透過手動指定 DNS 伺服器的方式進行測試（你也可以更新 /etc/resolv.conf 檔案並使用 ping 進行測試；但我覺得這裡很適合介紹新的 dig 工具及其 @ 引數，後者用於指定需要查詢的 DNS 伺服器地址）：
root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION
;; ANSWER SECTION:
google.com. 112 IN A 172.217.23.14
但是還有一個問題，這種方式僅適用於主機配置了 dnsmasq 的情況；如果主機沒有配置 dnsmasq，主機上並不存在用於查詢的 DNS 伺服器。
在這個問題上，Docker 的解決方案是忽略所有可能的複雜情況，即無論主機中使用什麼 DNS 伺服器，容器內都使用 Google 的 DNS 伺服器 8.8.8.8 和 8.8.4.4 完成 DNS 查詢。
我的經歷：在 2013 年，我遇到了使用 Docker 以來的第一個問題，與 Docker 的這種 DNS 解決方案密切相關。我們公司的網路遮蔽了 8.8.8.8 和 8.8.4.4，導致容器無法解析域名。
這就是 Docker 容器的情況，但對於包括 Kubernetes 在內的容器 編排引擎，情況又有些不同。
2) Kubernetes 和 DNS
在 Kubernetes 中，最小部署單元是 pod；它是一組相互協作的容器，共享 IP 地址（和其它資源）。
Kubernetes 面臨的一個額外的挑戰是，將 Kubernetes 服務請求（例如，myservice.kubernetes.io）透過對應的解析器，轉發到具體服務地址對應的內網地址。這裡提到的服務地址被稱為歸屬於“叢集域”。叢集域可由管理員配置，根據配置可以是 cluster.local 或 myorg.badger 等。
在 Kubernetes 中，你可以為 pod 指定如下四種 pod 內 DNS 查詢的方式。
Default
在這種（名稱容易讓人誤解）的方式中，pod 與其所在的主機採用相同的 DNS 查詢路徑，與前面介紹的主機 DNS 查詢一致。我們說這種方式的名稱容易讓人誤解，因為該方式並不是預設選項！ClusterFirst 才是預設選項。
如果你希望改寫 /etc/resolv.conf 中的條目，你可以新增到 kubelet 的配置中。
ClusterFirst
在 ClusterFirst 方式中，遇到 DNS 查詢請求會做有選擇的轉發。根據配置的不同，有以下兩種方式：
第一種方式配置相對古老但更簡明，即採用一個規則：如果請求的域名不是叢集域的子域，那麼將其轉發到 pod 所在的主機。
第二種方式相對新一些，你可以在內部 DNS 中配置選擇性轉發。
下麵給出示例配置並從 Kubernetes 檔案[4]中選取一張圖說明流程：
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"acme.local": ["1.2.3.4"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
在 stubDomains 條目中，可以為特定域名指定特定的 DNS 伺服器；而 upstreamNameservers 條目則給出，待查詢域名不是叢集域子域情況下用到的 DNS 伺服器。
這是透過在一個 pod 中執行我們熟知的 dnsmasq 實現的。
kubedns
剩下兩種選項都比較小眾：
ClusterFirstWithHostNet
適用於 pod 使用主機網路的情況，例如繞開 Docker 網路配置，直接使用與 pod 對應主機相同的網路。
None
None 意味著不改變 DNS，但強制要求你在 pod 規範檔案的 dnsConfig 條目中指定 DNS 配置。
CoreDNS 即將到來
除了上面提到的那些，一旦 CoreDNS 取代 Kubernetes 中的 kube-dns，情況還會發生變化。CoreDNS 相比 kube-dns 具有可配置性更高、效率更高等優勢。
如果想瞭解更多，參考這裡[5]。
如果你對 OpenShift 的網路感興趣，我曾寫過一篇文章[6]可供你參考。但文章中 OpenShift 的版本是 3.6，可能有些過時。
第四部分總結
第四部分到此結束，其中我們介紹了：
via: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
作者：zwischenzugs[8] 譯者：pinewall 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出