K8S 運維技巧--DNS 部分;

一.自定義dns ;

1.介紹;
2.怎樣獲取dns 名字;
3.支持的 DNS 模式;
4.自定義dns;

1.介紹

Kubernetes DNS 在羣集上調度 DNS Pod 和服務，並配置 kubelet 以告知各個容器使用 DNS 服務的 IP 來解析 DNS 名稱。

2.怎樣獲取 DNS 名字;

在集羣中定義的每一個 Service（包括 DNS 服務器自身）都會被指派一個 DNS 名稱。 默認，一個客戶端 Pod 的 DNS 搜索列表將包含該 Pod 本身的 Namespace 和集羣默認域。 經過以下示例能夠很好地說明：

假設在 Kubernetes 集羣的 Namespace bar 中，定義了一個Service foo。 運行在Namespace bar 中的一個 Pod，能夠簡單地經過 DNS 查詢 foo 來找到該 Service。 運行在 Namespace quux 中的一個 Pod 能夠經過 DNS 查詢 foo.bar 找到該 Service。

如下各節詳細介紹了受支持的記錄類型和支持的佈局。 其中代碼部分的佈局，名稱或查詢命令均被視爲實現細節，若有更改，恕不另行通知。 有關最新規範請查看 Kubernetes 基於 DNS 的服務發現.

3.支持的 DNS 模式

下面各段詳細說明支持的記錄類型和佈局。 若是任何其它的佈局、名稱或查詢，碰巧也可以使用，這就須要研究下它們的實現細節，以避免後續修改它們又不能使用了。

Service

A 記錄

「正常」 Service（除了 Headless Service）會以 my-svc.my-namespace.svc.cluster-domain.example 這種名字的形式被指派一個 DNS A 記錄。 這會解析成該 Service 的 Cluster IP。

「Headless」 Service（沒有Cluster IP）也會以 my-svc.my-namespace.svc.cluster-domain.example 這種名字的形式被指派一個 DNS A 記錄。 不像正常 Service，它會解析成該 Service 選擇的一組 Pod 的 IP。 但願客戶端可以使用這一組 IP，不然就使用標準的 round-robin 策略從這一組 IP 中進行選擇。

SRV 記錄

命名端口須要建立 SRV 記錄，這些端口是正常 Service或 Headless Services 的一部分。 對每一個命名端口，SRV 記錄具備 _my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example 這種形式。 對普通 Service，這會被解析成端口號和 CNAME：my-svc.my-namespace.svc.cluster-domain.example。 對 Headless Service，這會被解析成多個結果，Service 對應的每一個 backend Pod 各一個， 包含 auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example 這種形式 Pod 的端口號和 CNAME。

Pods

Pod的 hostname 和 subdomain 字段

當前，建立 Pod 後，它的主機名是該 Pod 的 metadata.name 值。

在 v1.2 版本中，用戶能夠配置 Pod annotation， 經過 pod.beta.kubernetes.io/hostname 來設置 Pod 的主機名。 若是爲 Pod 配置了 annotation，會優先使用 Pod 的名稱做爲主機名。 例如，給定一個 Pod，它具備 annotation pod.beta.kubernetes.io/hostname: my-pod-name，該 Pod 的主機名被設置爲 「my-pod-name」。

在 v1.3 版本中，PodSpec 具備 hostname 字段，能夠用來指定 Pod 的主機名。這個字段的值優先於 annotation pod.beta.kubernetes.io/hostname。 在 v1.2 版本中引入了 beta 特性，用戶能夠爲 Pod 指定 annotation，其中 pod.beta.kubernetes.io/subdomain 指定了 Pod 的子域名。 最終的域名將是 「...svc.」。 舉個例子，Pod 的主機名 annotation 設置爲 「foo」，子域名 annotation 設置爲 「bar」，在 Namespace 「my-namespace」 中對應的 FQDN 爲 「foo.bar.my-namespace.svc.cluster.local」。

在 v1.3 版本中，PodSpec 具備 subdomain 字段，能夠用來指定 Pod 的子域名。 這個字段的值優先於 annotation pod.beta.kubernetes.io/subdomain 的值。

4.Pod 的 DNS 設定

Pod 的 DNS 配置可以讓用戶對 Pod 的 DNS 設置進行更多控制。

dnsConfig 字段是可選的，它能夠與任何 dnsPolicy 設置一塊兒使用。 可是，當 Pod 的 dnsPolicy 設置爲 「None」 時，必須指定 dnsConfig 字段。

用戶能夠在 dnsConfig 字段中指定如下屬性：

• nameservers: 將用做於 Pod 的 DNS 服務器的 IP 地址列表。最多能夠指定3個 IP 地址。 當 Pod 的 dnsPolicy 設置爲 「None」 時，列表必須至少包含一個IP地址，不然此屬性是可選的。列出的服務器將合併到從指定的 DNS 策略生成的基本名稱服務器，並刪除重複的地址。

• searches: 用於在 Pod 中查找主機名的 DNS 搜索域的列表。此屬性是可選的。指定後，提供的列表將合併到根據所選 DNS 策略生成的基本搜索域名中。 重複的域名將被刪除。    Kubernetes最多容許6個搜索域。

• options: 對象的可選列表，其中每一個對象可能具備 name 屬性（必需）和 value 屬性（可選）。 此屬性中的內容將合併到從指定的 DNS 策略生成的選項。 重複的條目將被刪除。

• 
  

如下是具備自定義DNS設置的Pod示例

(1).dns yaml 配置詳細;

(2).運行dns ymal

(3).測試解析dns;

(4).建立上面的Pod後，容器 test 會在其 /etc/resolv.conf 文件中獲取如下內容:

二.經過 kube-dns 配置私有dns;

1.準備開始
2.配置存根域和上游 DNS 服務器
3.理解 Kubernetes 中名字解析
4.ConfigMap 選項

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

準備開始

• 你必須擁有一個 Kubernetes 的集羣，同時你的 Kubernetes 集羣必須帶有 kubectl 命令行工具。 若是你尚未集羣，你能夠經過 Minikube 構建一 個你本身的集羣，或者你可使用下面任意一個 Kubernetes 工具構建：

• Katacoda

• Play with Kubernetes

要獲知版本信息，請輸入 kubectl version.

• Kubernetes 1.6 及其以上版本。

• 集羣必須配置使用 kube-dns 插件。

配置存根域和上游 DNS 服務器

部署kube-dns 步驟以下;

(1).獲取:kube-dns yaml

wget https://raw.githubusercontent.com/feiskyer/kubernetes-handbook/master/manifests/kubedns/kube-dns.yaml 

(2).設置 kube-dns.yaml  clusterIP 集羣ip地址 （參考:kubernetes 網斷中未使用ip地址）

kubectl get service --all-namespaces 

(3).注意kube-dns 鏡像須要進行進行獲取;

經過爲 kube-dns （kube-system:kube-dns）提供 ConfigMap，集羣管理員可以指定自定義存根域和上游域名服務器。

例如，下面的 ConfigMap 創建了一個 DNS 配置，它具備一個單獨的存根域和兩個上游域名服務器：

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"]

按如上說明，具備 「.acme.local」 後綴的 DNS 請求被轉發到 DNS 1.2.3.4。Google 公共 DNS服務器 爲上游查詢提供服務。 下表描述了具備特定域名的查詢如何映射到它們的目標 DNS 服務器：

域名	響應查詢的服務器
kubernetes.default.svc.cluster.local	kube-dns
foo.acme.local	自定義 DNS (1.2.3.4)
widget.com	上游 DNS (8.8.8.8, 8.8.4.4，其中之一)

查看 ConfigMap 選項 獲取更多關於配置選項格式的詳細信息。

理解 Kubernetes 中名字解析

能夠爲每一個 Pod 設置 DNS 策略。 當前 Kubernetes 支持兩種 Pod 特定的 DNS 策略：「Default」 和 「ClusterFirst」。 能夠經過 dnsPolicy 標誌來指定這些策略。 注意：「Default」 不是默認的 DNS 策略。若是沒有顯式地指定 dnsPolicy，將會使用 「ClusterFirst」。

「Default」 DNS 策略

若是 dnsPolicy 被設置爲 「Default」，則名字解析配置會繼承自 Pod 運行所在的節點。 自定義上游域名服務器和存根域不可以與這個策略一塊兒使用。

「ClusterFirst」 DNS 策略

若是 dnsPolicy 被設置爲 「ClusterFirst」，處理名字解析有所不一樣，*依賴因而否配置了存根域和上游 DNS 服務器*。

未進行自定義配置：沒有匹配上配置的集羣域名後綴的任何請求，例如 「www.kubernetes.io」，將會被轉發到繼承自節點的上游域名服務器。

進行自定義配置：若是配置了存根域和上游 DNS 服務器（相似於 前面示例 配置的內容），DNS 查詢將基於下面的流程對請求進行路由：

1. 查詢首先被髮送到 kube-dns 中的 DNS 緩存層。

2. 從緩存層，檢查請求的後綴，並根據下面的狀況轉發到對應的 DNS 上：

• *具備集羣后綴的名字*（例如 「.cluster.local」）：請求被髮送到 kube-dns。

• *具備存根域後綴的名字*（例如 「.acme.local」）：請求被髮送到配置的自定義 DNS 解析器（例如：監聽在 1.2.3.4）。

• *未能匹配上後綴的名字*（例如 「widget.com」）：請求被轉發到上游 DNS（例如：Google 公共 DNS 服務器，8.8.8.8 和 8.8.4.4）。

ConfigMap 選項

kube-dns kube-system:kube-dns 對應的 ConfigMap 選項以下所示：

字段	格式	描述
stubDomains（可選）	使用 DNS 後綴做爲鍵（例如 「acme.local」）的 JSON map，以及由 DNS IP 的 JSON 數組組成的值。	目標域名服務器多是一個 Kubernetes Service。例如，能夠運行本身的 dnsmasq 副本，將 DNS 名字暴露到 ClusterDNS namespace 中。
upstreamNameservers（可選）	DNS IP 的 JSON 數組。	注意：若是指定，則指定的值會替換掉被默認從節點的 /etc/resolv.conf 中獲取到的域名服務器。限制：最多能夠指定三個上游域名服務器。

附加示例

示例：存根域

在這個例子中，用戶有一個 Consul DNS 服務發現系統，他們但願可以與 kube-dns 集成起來。 Consul 域名服務器地址爲 10.150.0.1，全部的 Consul 名字具備後綴 「.consul.local」。 要配置 Kubernetes，集羣管理員只須要簡單地建立一個 ConfigMap 對象，以下所示：

apiVersion: v1
kind: ConfigMap 
metadata:  
     name: kube-dns   
     namespace: kube-system 
     data:  stubDomains: |    
              {"consul.local": ["10.150.0.1"]}

注意，集羣管理員不但願覆蓋節點的上游域名服務器，因此他們不會指定可選的 upstreamNameservers 字段。

示例：上游域名服務器

在這個示例中，集羣管理員不但願顯式地強制全部非集羣 DNS 查詢進入到他們本身的域名服務器 172.16.0.1。 並且這很容易實現：他們只須要建立一個 ConfigMap，upstreamNameservers 字段指按期望的域名服務器便可：

apiVersion: v1 
kind: ConfigMap 
metadata:  
    name: kube-dns  
    namespace: kube-system 
data:  upstreamNameservers: |   
          ["172.16.0.1"]