如何在 K8S 中配置私有 DNS 區域和上游 NS

許多用戶想將現有的域名 zones 集成到其 Kubernetes DNS 命名空間中。例如，混合雲用戶可能但願解決集羣內部的「.corp」域地址問題。其餘用戶多是有由非 Kubernetes 服務發現系統的 zone（如 Consul）問題。在 Kubernetes 1.6中，kube-dns 增長了對可配置的專用 DNS zones（一般稱爲「stub domains」）和外部上游 DNS 名稱服務器的支持。在這篇博文中，咱們將介紹如何配置和使用此功能。
1.默認查找流程

Kubernetes 目前支持兩種 DNS 策略：
」Default」和」ClusteFirst」。
若是 dnsPolicy 的 Flag 沒有特別指明，則默認使用」ClusterFirst」。
若是dnsPolicy設置爲「Default」，則名稱解析配置將從pod運行的節點繼承。
若是 dnsPolicy 設置爲「ClusterFirst」，則 DNS 查詢將被髮送到 kube-dns 服務。 基於 cluster domaim 後綴（上述示例中以.cluster.local結尾的地址）的域查詢將由 kube-dns 服務應答。 全部其餘查詢（例如www.kubernetes.io）將被轉發到從節點繼承的上游 NS。
在此以前，一般使用自定義解析器替換上游 DNS 來引入存根域。 然而，這會致使自定義解析器自己成爲 DNS 解析的關鍵路徑，其中可擴展性和可用性的問題可能致使集羣丟失 DNS 功能。 如今，容許用戶引入自定義解析而不佔用整個解析路徑。
2.自定義 DNS Flow
從 Kubernetes 1.6開始，集羣管理員能夠經過爲kube-dns提供的 ConfigMap 來指定自定義存根域和上游 NS。 例如，下面的配置插入一個單獨的存根域和兩個上游 NS。 以下所示，以「.acme.local」爲後綴的DNS請求將被轉發到監聽在 1.2.3.4 上的 DNS 服務來處理。此外， Google 公共 DNS 將提供上游查詢。 有關數據格式的一些說明，請參閱本節末尾的 ConfigMap 配置說明。

下圖顯示了上述配置中指定的 DNS 查詢流程。
將 dnsPolicy 設置爲「ClusterFirst」後，首先將 DNS 查詢發送到 kube-dn s中的 DNS 緩存層。 從這裏，請求的後綴被檢查，而後轉發到相應的 DNS 。 在這種狀況下，具備集羣后綴（例如「.cluster.local」）的名稱將發送到 kube-dns 。 使用存根域後綴（例如「.acme.local」）的名稱將被髮送到配置的自定義解析器。 最後，與這些後綴不匹配的請求將轉發到上游 DNS 。

如下是一些域名示例以及查詢這些域名的目標服務器：

3.ConfigMap配置注意事項
stubDomains（可選）
格式：以 DNS 後綴（如「acme.local」）爲鍵，DNS IP 數組爲值的 JSON 映射。
注意：目標名稱服務器自己多是 Kubernetes 服務。 例如，您能夠運行本身的 dnsmasq 副本將自定義 DNS 名稱導出到 ClusterDNS 命名空間中。
upstreamNameservers（可選）
格式： DNS I P的 JSON 數組。
注意：若是指定，那麼指定的值將替代默認從節點的/etc/resolv.conf中獲取的名稱服務器
限制：最多能夠指定三個上游名稱服務器
示例1：添加一個Consul DNS 存根域
在此示例中，用戶具備但願與 kube-dns 集成的 Consul DNS 服務發現系統。
Consul Domain 服務器位於10.150.0.1，全部 consul 均之後綴「.consul.local」命名。
要配置 Kubernetes ，集羣管理員只需建立一個 ConfigMap 對象，以下所示。 注意：在此示例中，集羣管理員不但願覆蓋節點的上游 NS ，所以他們不須要指定可選的 upstreamNameservers 字段。

示例2：替換上游 NS
在此示例中，集羣管理員但願明確強制全部非集羣的 DNS 查詢經過運行 在 172.16.0.1 上的他們本身的 NS 來完成。這很容易完成,他們只須要使用指定所需名稱 服務器的 upstreamNameservers 字段建立一個 ConfigMap。

時速雲翻譯，轉載請註明出處！