安裝配置Kube-dns · kubernetes完整攻略

# 安裝配置kube-dns 在我們安裝Kubernetes集群的時候就已經安裝了kube-dns插件，這個插件也是官方推薦安裝的。通過將 Service 注冊到 DNS 中，Kuberentes 可以為我們提供一種簡單的服務注冊發現與負載均衡方式。 [CoreDNS](https://coredns.io)作為CNCF中的托管的一個項目，在Kuberentes1.9版本中，使用kubeadm方式安裝的集群可以通過以下命令直接安裝CoreDNS。 ```bash kubeadm init --feature-gates=CoreDNS=true ``` 您也可以使用CoreDNS替換Kubernetes插件kube-dns，可以使用 Pod 部署也可以獨立部署，請參考[Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/)，下文將介紹如何配置kube-dns。 ## kube-dns kube-dns是Kubernetes中的一個內置插件，目前作為一個獨立的開源項目維護，見<https://github.com/kubernetes/dns>。下文中給出了配置 DNS Pod 的提示和定義 DNS 解析過程以及診斷 DNS 問題的指南。 ## 前提要求 - Kubernetes 1.6 及以上版本。 - 集群必須使用 `kube-dns` 插件進行配置。 ## kube-dns 介紹從 Kubernetes v1.3 版本開始，使用 cluster add-on 插件管理器回自動啟動內置的 DNS。 Kubernetes DNS pod 中包括 3 個容器： - `kubedns`：`kubedns` 進程監視 Kubernetes master 中的 Service 和 Endpoint 的變化，并維護內存查找結構來服務DNS請求。 - `dnsmasq`：`dnsmasq` 容器添加 DNS 緩存以提高性能。 - `sidecar`：`sidecar` 容器在執行雙重健康檢查（針對 `dnsmasq` 和 `kubedns`）時提供單個健康檢查端點（監聽在10054端口）。 DNS pod 具有靜態 IP 并作為 Kubernetes 服務暴露出來。該靜態 IP 分配后，kubelet 會將使用 `--cluster-dns = <dns-service-ip>` 標志配置的 DNS 傳遞給每個容器。 DNS 名稱也需要域名。本地域可以使用標志 `--cluster-domain = <default-local-domain>` 在 kubelet 中配置。 Kubernetes集群DNS服務器基于 [SkyDNS](https://github.com/skynetservices/skydns) 庫。它支持正向查找（A 記錄），服務查找（SRV 記錄）和反向 IP 地址查找（PTR 記錄） ## kube-dns 支持的 DNS 格式 kube-dns 將分別為 service 和 pod 生成不同格式的 DNS 記錄。 **Service** - A記錄：生成`my-svc.my-namespace.svc.cluster.local`域名，解析成 IP 地址，分為兩種情況： - 普通 Service：解析成 ClusterIP - Headless Service：解析為指定 Pod 的 IP 列表 - SRV記錄：為命名的端口（普通 Service 或 Headless Service）生成 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster.local` 的域名 **Pod** - A記錄：生成域名 `pod-ip.my-namespace.pod.cluster.local` ## kube-dns 存根域名可以在 Pod 中指定 hostname 和 subdomain：`hostname.custom-subdomain.default.svc.cluster.local`，例如： ```yaml apiVersion: v1 kind: Pod metadata: name: busybox labels: name: busybox spec: hostname: busybox-1 subdomain: busybox-subdomain containers: name: busybox - image: busybox command: - sleep - "3600" ``` 該 Pod 的域名是 `busybox-1.busybox-subdomain.default.svc.cluster.local`。 ## 繼承節點的 DNS 運行 Pod 時，kubelet 將預先配置集群 DNS 服務器到 Pod 中，并搜索節點自己的 DNS 設置路徑。如果節點能夠解析特定于較大環境的 DNS 名稱，那么 Pod 應該也能夠解析。請參閱下面的已知問題以了解警告。如果您不想要這個，或者您想要為 Pod 設置不同的 DNS 配置，您可以給 kubelet 指定 `--resolv-conf` 標志。將該值設置為 "" 意味著 Pod 不繼承 DNS。將其設置為有效的文件路徑意味著 kubelet 將使用此文件而不是 `/etc/resolv.conf` 用于 DNS 繼承。 ## 配置存根域和上游 DNS 服務器通過為 kube-dns （`kube-system:kube-dns`）提供一個 ConfigMap，集群管理員能夠指定自定義存根域和上游 nameserver。例如，下面的 ConfigMap 建立了一個 DNS 配置，它具有一個單獨的存根域和兩個上游 nameserver： ```yaml 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 請求被轉發到 1.2.3.4 處監聽的 DNS。Google Public 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 選項獲取更多關于配置選項格式的詳細信息。 ### 對 Pod 的影響自定義的上游名稱服務器和存根域不會影響那些將自己的 `dnsPolicy` 設置為 `Default` 或者 `None` 的 Pod。如果 Pod 的 `dnsPolicy` 設置為 “`ClusterFirst`”，則其名稱解析將按其他方式處理，具體取決于存根域和上游 DNS 服務器的配置。 **未進行自定義配置**：沒有匹配上配置的集群域名后綴的任何請求，例如 “www.kubernetes.io”，將會被轉發到繼承自節點的上游 nameserver。 **進行自定義配置**：如果配置了存根域和上游 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）。 ![DNS lookup flow](https://d33wubrfki0l68.cloudfront.net/340889cb80e81dcd19a16bc34697a7907e2b229a/24ad0/docs/tasks/administer-cluster/dns-custom-nameservers/dns.png) ## ConfigMap 選項 kube-dns `kube-system:kube-dns` ConfigMap 的選項如下所示： | 字段 | 格式 | 描述 | | ------------------------- | ---------------------------------------- | ---------------------------------------- | | `stubDomains`（可選） | 使用 DNS 后綴 key 的 JSON map（例如 “acme.local”），以及 DNS IP 的 JSON 數組作為 value。 | 目標 nameserver 可能是一個 Kubernetes Service。例如，可以運行自己的 dnsmasq 副本，將 DNS 名字暴露到 ClusterDNS namespace 中。 | | `upstreamNameservers`（可選） | DNS IP 的 JSON 數組。 | 注意：如果指定，則指定的值會替換掉被默認從節點的 `/etc/resolv.conf` 中獲取到的 nameserver。限制：最多可以指定三個上游 nameserver。 | ### 示例 #### 示例：存根域在這個例子中，用戶有一個 Consul DNS 服務發現系統，他們希望能夠與 kube-dns 集成起來。 Consul 域名服務器地址為 10.150.0.1，所有的 Consul 名字具有后綴 `.consul.local`。要配置 Kubernetes，集群管理員只需要簡單地創建一個 ConfigMap 對象，如下所示： ```yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {“consul.local”: [“10.150.0.1”]} ``` 注意，集群管理員不希望覆蓋節點的上游 nameserver，所以他們不會指定可選的 `upstreamNameservers` 字段。 #### 示例：上游 nameserver 在這個示例中，集群管理員不希望顯式地強制所有非集群 DNS 查詢進入到他們自己的 nameserver 172.16.0.1。而且這很容易實現：他們只需要創建一個 ConfigMap，`upstreamNameservers` 字段指定期望的 nameserver 即可。 ```yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: upstreamNameservers: | [“172.16.0.1”] ``` ## 調試 DNS 解析 ### 創建一個簡單的 Pod 用作測試環境創建一個名為 busybox.yaml 的文件，其中包括以下內容： ```yaml apiVersion: v1 kind: Pod metadata: name: busybox namespace: default spec: containers: - name: busybox image: busybox command: - sleep - "3600" imagePullPolicy: IfNotPresent restartPolicy: Always ``` 使用該文件創建 Pod 并驗證其狀態： $ kubectl create -f busybox.yaml pod "busybox" created $ kubectl get pods busybox NAME READY STATUS RESTARTS AGE busybox 1/1 Running 0 <some-time> ``` 該 Pod 運行后，您可以在它的環境中執行 `nslookup`。如果您看到類似如下的輸出，表示 DNS 正在正確工作。 ?```bash $ kubectl exec -ti busybox -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 Name: kubernetes.default Address 1: 10.0.0.1 ``` 如果 `nslookup` 命令失敗，檢查如下內容： ### 首先檢查本地 DNS 配置查看下 resolv.conf 文件。 ```bash $ kubectl exec busybox cat /etc/resolv.conf ``` 驗證搜索路徑和名稱服務器設置如下（請注意，搜索路徑可能因不同的云提供商而異）： ``` search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal nameserver 10.0.0.10 options ndots:5 ``` 如果看到如下錯誤表明錯誤來自 kube-dns 或相關服務： ``` $ kubectl exec -ti busybox -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 nslookup: can't resolve 'kubernetes.default' ``` 或者 ``` $ kubectl exec -ti busybox -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local nslookup: can't resolve 'kubernetes.default' ``` ### 檢查 DNS pod 是否在運行使用 `kubectl get pods` 命令驗證 DNS pod 是否正在運行。 ```bash $ kubectl get pods --namespace=kube-system -l k8s-app=kube-dns NAME READY STATUS RESTARTS AGE ... kube-dns-v19-ezo1y 3/3 Running 0 1h ... ``` 如果您看到沒有 Pod 運行或者 Pod 處于失敗/完成狀態，DNS 插件可能沒有部署到您的當前環境中，您需要手動部署。 ### 檢查 DNS pod 中的錯誤使用 `kubectl logs` 命令查看 DNS 守護進程的日志。 ```bash $ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns $ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq $ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar ``` 看看有沒有可疑的日志。以字母“`W`”，“`E`”，“`F`”開頭的代表警告、錯誤和失敗。請搜索具有這些日志級別的條目，并使用 [kubernetes issues](https://github.com/kubernetes/kubernetes/issues)來報告意外錯誤。 ### DNS 服務啟動了嗎？使用 `kubectl get service` 命令驗證 DNS 服務是否啟動。 ```bash $ kubectl get svc --namespace=kube-system NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE ... kube-dns 10.0.0.10 <none> 53/UDP,53/TCP 1h ... ``` 如果您已經創建了該服務或它本應該默認創建但沒有出現，參考[調試服務](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/)獲取更多信息。 ### DNS 端點暴露出來了嗎？您可以使用`kubectl get endpoints`命令驗證 DNS 端點是否被暴露。 ```bash $ kubectl get ep kube-dns --namespace=kube-system NAME ENDPOINTS AGE kube-dns 10.180.3.17:53,10.180.3.17:53 1h ``` 如果您沒有看到端點，查看[調試服務](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/)文檔中的端點部分。獲取更多的 Kubernetes DNS 示例，請參考 Kubernetes GitHub 倉庫中的[cluster-dns示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 ## 已知問題 Kubernetes安裝時不會將節點的 resolv.conf 文件配置為默認使用集群 DNS，因為該過程本身是特定于發行版的。這一步應該放到最后實現。 Linux 的 libc 不可思議的卡住（[查看該2005年起暴出來的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253)）限制只能有 3 個 DNS `nameserver` 記錄和 6 個 DNS `search` 記錄。Kubernetes 需要消耗 1 個 `nameserver` 記錄和 3 個 `search` 記錄。這意味著如果本地安裝已經使用 3 個 `nameserver` 或使用 3 個以上的 `search` 記錄，那么其中一些設置將會丟失。有個部分解決該問題的方法，就是節點可以運行 `dnsmasq`，它將提供更多的 `nameserver` 條目，但不會有更多的 `search` 條目。您也可以使用 kubelet 的 `--resolv-conf` 標志。如果您使用的是 Alpine 3.3 或更低版本作為基礎映像，由于已知的 Alpine 問題，DNS 可能無法正常工作。點擊[這里](https://github.com/kubernetes/kubernetes/issues/30215)查看更多信息。 ## Kubernetes 集群聯邦（多可用區支持） Kubernetes 1.3 版本起引入了支持多站點 Kubernetes 安裝的集群聯邦支持。這需要對 Kubernetes 集群 DNS 服務器處理 DNS 查詢的方式進行一些小的（向后兼容的）更改，以便于查找聯邦服務（跨多個 Kubernetes 集群）。有關集群聯邦和多站點支持的更多詳細信息，請參閱[集群聯邦管理員指南](https://kubernetes.io/docs/concepts/cluster-administration/federation/)。 ## 參考 - [Configure DNS Service](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/) - [Service 和 Pod 的 DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) - [自動擴容集群中的 DNS 服務](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) - [Using CoreDNS for Service Discovery](https://kubernetes.io/docs/tasks/administer-cluster/coredns/)