許多使用者他們想要內建domain name zones（現有域名區域）到Kubernetes DNS 命名空間。例如，混合雲使用者可能希望在群集内解析其内部“.corp”域位址。其他使用者可能具有由非Kubernetes服務發現系統（如Consul）組成的區域。我們很高興地宣布，在Kubernetes 1.6中，kube-dns增加了對可配置的私有DNS區域（通常稱為“存根域”）和外部上遊DNS名稱伺服器的支援。在這篇博 文中，我們将介紹如何配置和使用此功能。
Default lookup flow
- “Default”
- “ClusterFirst”
如果未明确指定dnsPolicy，則預設使用“ClusterFirst”：
- 果将dnsPolicy設定為“Default”，則名稱解析配置将從運作pod的node節點繼承。注意：此功能不能與dnsPolicy一起使用：“Default”。
- 如果将dnsPolicy設定為“ClusterFirst”，則DNS查詢将發送到kube-dns服務。對于以配置的叢集域字尾為根的域（上面示例中以“.cluster.local”結尾的任何位址）的查詢将由kube-dns服務應答。所有其他查詢（例如，www.kubernetes.io）将被轉發到從節點繼承的上遊名稱伺服器。在此功能之前，通常通過使用自定義解析程式替換上遊DNS來引入存根域。但是，這導緻自定義解析程式本身成為DNS解析的關鍵路徑，其中可伸縮性和可用性問題可能導緻群集丢失DNS功能。此特性允許使用者在不接管整個解析路徑的情況下引入自定義解析。
Customizing the DNS Flow
從Kubernetes 1.6開始，叢集管理者可以通過為kube-dns提供ConfigMap來指定自定義存根域和上遊域名伺服器。例如，下面的配置插入單個存根域和兩個上遊名稱伺服器。根據規定，帶有“.acme.local”字尾的DNS請求将被轉發到偵聽1.2.3.4的DNS。此外，Google Public DNS将為上遊查詢提供服務。有關資料格式的一些注意事項，請參閱本節末尾的ConfigMap配置說明。
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”] 下圖顯示了上述配置中指定的DNS查詢流。将dnsPolicy設定為“ClusterFirst”後，DNS查詢将首先發送到kube-dns中的DNS緩存層。從此處檢查請求的字尾，然後将其轉發到相應的DNS。在這種情況下，具有叢集字尾的名稱（例如“.cluster.local”）将發送到kube-dns。具有存根域字尾的名稱（例如“.acme.local”）将被發送到配置的自定義解析程式。最後，與這些字尾中的任何一個都不比對的請求将被轉發到上遊DNS。
下面是一個示例域名和這些域名的查詢目的地的表格：
| Domain name | Server answering the query |
| kubernetes.default.svc.cluster.local | kube-dns |
| foo.acme.local | custom DNS (1.2.3.4) |
| widget.com | upstream DNS (one of 8.8.8.8, 8.8.4.4) |
ConfigMap Configuration Notes
- stubDomains存根區域(可選)
- 格式：使用DNS字尾密鑰的JSON映射（例如;“acme.local”）和由DNS IP的JSON數組組成的值。
- 注意：目标名稱服務本身可能是Kubernetes服務。例如，您可以運作自己的dnsmasq副本以将自定義DNS名稱導出到Cluster DNS名稱空間中。
- upstreamNameservers上遊命名服務(可選)
- 格式：DNS IP的JSON數組。
- 注意：如果指定，則指定的值将替換預設情況下從節點的/etc/resolv.conf擷取的名稱服務
- 限制：最多可以指定三個上遊名稱伺服器
示例 #1: 增加 Consul DNS Stub Domain
在該示例中，使用者具有他們希望與kube-dns內建的Consul DNS服務發現系統。 consul域伺服器位于10.150.0.1，所有consul名稱的字尾為“.consul.local”。要配置Kubernetes，叢集管理者隻需建立一個ConfigMap對象，如下所示。注意：在此示例中，叢集管理者不希望覆寫節點的上遊名稱伺服器，是以他們不需要指定可選的upstreamNameservers字段。
apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {“consul.local”: [“10.150.0.1”]} 示例 #2: 替換Upstream Nameservers
在此示例中，叢集管理者希望顯式強制所有非叢集DNS查找在172.16.0.1處通過自己的名稱伺服器。再次，這很容易實作;他們隻需要使用upstreamNameservers字段建立一個ConfigMap，指定所需的名稱伺服器。
apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: upstreamNameservers: | [“172.16.0.1”] 總結
上文是kube-dns實作的解決方案。而stubDomains 和 upstreamNameservers 在coredns 中 通過 proxy 插件實作。coredns是接下來重點研究的東西。
本文轉自中文社群-
k8s與DNS--配置私有DNS Zones和Upstream Nameservers