在 Kubernetes 中配置私有 DNS 區域和上游域名伺服器

編者注：本文是關於 Kubernetes 1.6 新功能的一系列深度文章的一部分

許多使用者都有現有的域名區域，他們希望將其整合到 Kubernetes DNS 名稱空間中。例如，混合雲使用者可能希望在叢集中解析其內部 “.corp” 域地址。其他使用者可能有一個由非 Kubernetes 服務發現系統（如 Consul）填充的區域。我們很高興地宣佈，在Kubernetes 1.6中，kube-dns增加了對可配置的私有 DNS 區域（通常稱為“存根域”）和外部上游 DNS 命名伺服器的支援。在這篇博文中，我們將介紹如何配置和使用此功能。

預設查詢流程

Kubernetes 目前支援兩種 DNS 策略，透過 dnsPolicy 標誌在每個 Pod 基礎上指定：“Default”和“ClusterFirst”。如果未明確指定 dnsPolicy，則使用“ClusterFirst”

• 如果 dnsPolicy 設定為“Default”，則名稱解析配置將從 Pod 執行的節點繼承。注意：此功能不能與 dnsPolicy: “Default” 結合使用。
• 如果 dnsPolicy 設定為“ClusterFirst”，則 DNS 查詢將傳送到 kube-dns 服務。對配置的叢集域字尾（在上述示例中以“.cluster.local”結尾的任何地址）根目錄下的域的查詢將由 kube-dns 服務應答。所有其他查詢（例如，www.kubernetes.io）將轉發到從節點繼承的上游命名伺服器。在此功能之前，通常透過用自定義解析器替換上游 DNS 來引入存根域。然而，這導致自定義解析器本身成為 DNS 解析的關鍵路徑，其中可擴充套件性和可用性問題可能導致叢集失去 DNS 功能。此功能允許使用者引入自定義解析，而無需接管整個解析路徑。

自定義 DNS 流程

從 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。

下面是示例域名及其查詢目的地表

ConfigMap 配置說明

• 存根域 (stubDomains)（可選）

  • 格式：一個 JSON 對映，使用 DNS 字尾作為鍵（例如：“acme.local”），值是一個由 DNS IP 組成的 JSON 陣列。
  • 注意：目標命名伺服器本身可能是一個 Kubernetes 服務。例如，您可以執行自己的 dnsmasq 副本，將自定義 DNS 名稱匯出到 ClusterDNS 名稱空間。

• 上游命名伺服器 (upstreamNameservers)（可選）

  • 格式：一個 DNS IP 的 JSON 陣列。
  • 注意：如果指定，則指定的值將替換預設從節點 /etc/resolv.conf 中獲取的命名伺服器。
  • 限制：最多可指定三個上游命名伺服器。

示例 #1：新增 Consul DNS 存根域

在此示例中，使用者有一個希望與 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：替換上游命名伺服器

在此示例中，叢集管理員希望明確強制所有非叢集 DNS 查詢都透過其位於 172.16.0.1 的自己的命名伺服器。同樣，這很容易實現；他們只需建立一個 ConfigMap，並在 upstreamNameservers 欄位中指定所需的命名伺服器。

apiVersion: v1

kind: ConfigMap

metadata:

  name: kube-dns

  namespace: kube-system

data:

  upstreamNameservers: |

    [“172.16.0.1”]




**Get involved**  

If you’d like to contribute or simply help provide feedback and drive the roadmap, [join our community](https://github.com/kubernetes/community#kubernetes-community). Specifically for network related conversations participate though one of these channels:  

- Chat with us on the Kubernetes [Slack network channel](https://kubernetes.slack.com/messages/sig-network/)
- Join our Special Interest Group, [SIG-Network](https://github.com/kubernetes/community/wiki/SIG-Network), which meets on Tuesdays at 14:00 PT
Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.club.tw/blog/2017/03/five-days-of-kubernetes-1-6).


- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Connect with the community on [Slack](http://slack.k8s.io/)
- [Download](http://get.k8s.io/) Kubernetes

• ←上一篇
• 下一篇→