本文已超過一年。 較舊的文章可能包含過時的內容。 請檢查頁面中的資訊自發布以來是否已變得不正確。

CoreDNS GA 用於 Kubernetes 叢集 DNS

作者：John Belamaric (Infoblox) |

編者註：這篇文章是關於 Kubernetes 1.11 新功能的系列深入文章的一部分

簡介

在 Kubernetes 1.11 中，CoreDNS 已針對基於 DNS 的服務發現達到正式發布 (GA)，作為 kube-dns 外掛程式的替代方案。 這表示在即將推出的各種安裝工具版本中，CoreDNS 將作為一個選項提供。 事實上，kubeadm 團隊選擇使其成為 Kubernetes 1.11 開始的預設選項。

基於 DNS 的服務發現作為 kube-dns 叢集外掛程式已成為 Kubernetes 的一部分很長時間了。 這通常運作良好，但對於實作的可靠性、彈性和安全性存在一些疑慮。

CoreDNS 是一個通用、權威的 DNS 伺服器，它提供與 Kubernetes 的向後相容但可擴展的整合。 它解決了 kube-dns 中出現的問題，並提供了許多獨特的功能，可以解決更廣泛的用例。

在本文中，您將了解 kube-dns 和 CoreDNS 實作的差異，以及 CoreDNS 提供的一些有用的擴展。

實作差異

在 kube-dns 中，單個 Pod 內使用了多個容器：kubedns、dnsmasq 和 sidecar。 kubedns 容器監視 Kubernetes API 並根據 Kubernetes DNS 規範提供 DNS 記錄，dnsmasq 提供快取和 Stub 網域支援，而 sidecar 提供指標和健康檢查。

這種設定導致了一些隨著時間的推移而出現的問題。 首先，dnsmasq 中的安全漏洞導致過去需要發布 Kubernetes 的安全修補程式版本。 此外，由於 dnsmasq 處理 Stub 網域，而 kubedns 處理外部服務，因此您無法在外部服務中使用 Stub 網域，這對該功能非常有限制（請參閱 dns#131）。

所有這些功能都在 CoreDNS 中的單個容器中完成，該容器正在運行以 Go 編寫的進程。 啟用的不同外掛程式複製（並增強）了 kube-dns 中的功能。

配置 CoreDNS

在 kube-dns 中，您可以修改 ConfigMap 以更改服務發現的行為。 這允許新增諸如提供 Stub 網域、修改上游名稱伺服器和啟用 Federation 等功能。

在 CoreDNS 中，您可以類似地修改 CoreDNS Corefile 的 ConfigMap，以更改服務發現的工作方式。 此 Corefile 配置提供了比您在 kube-dns 中找到的更多的選項，因為它是 CoreDNS 用於配置其所有功能（即使是那些與 Kubernetes 無關的功能）的主要配置文件。

當使用 kubeadm 從 kube-dns 升級到 CoreDNS 時，您現有的 ConfigMap 將用於為您生成自訂的 Corefile，包括 Stub 網域、Federation 和上游名稱伺服器的所有配置。 有關更多詳細資訊，請參閱使用 CoreDNS 進行服務發現。

錯誤修復和增強功能

kube-dns 存在多個未解決的問題，這些問題已在 CoreDNS 中解決，無論是在預設配置中還是在某些自訂配置中。

指標

預設 CoreDNS 配置的功能行為與 kube-dns 相同。 但是，您需要注意的一個區別是發布的指標不同。 在 kube-dns 中，您可以獲得 dnsmasq 和 kubedns (skydns) 的單獨指標。 在 CoreDNS 中，指標集完全不同，因為它只是一個進程。 您可以在 CoreDNS Prometheus 外掛程式頁面上找到有關這些指標的更多詳細資訊。

一些特殊功能

標準的 CoreDNS Kubernetes 組態旨在與先前的 kube-dns 行為向後相容。但是透過一些組態變更，CoreDNS 可以讓您修改 DNS 服務探索在您的叢集中運作的方式。這些功能中的許多旨在仍然符合 Kubernetes DNS 規範；它們增強了功能，但仍然保持向後相容性。由於 CoreDNS 並非僅為 Kubernetes 而設計，而是一個通用的 DNS 伺服器，因此您可以執行許多超出該規範範圍的操作。

Pod 已驗證模式

在 kube-dns 中，Pod 名稱記錄是「假的」。也就是說，任何 "a-b-c-d.namespace.pod.cluster.local" 查詢都會傳回 IP 位址 "a.b.c.d"。在某些情況下，這可能會削弱 TLS 提供的身分保證。因此，CoreDNS 提供了「pods verified」模式，只有當指定的命名空間中存在具有該 IP 位址的 pod 時，才會傳回 IP 位址。

基於 Pod 名稱的端點名稱

在 kube-dns 中，當使用無頭服務時，您可以使用 SRV 請求來取得服務的所有端點列表

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 10 33 0 6234396237313665.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 10 33 0 6662363165353239.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 10 33 0 6338633437303230.headless.default.svc.cluster.local.
dnstools#

然而，端點 DNS 名稱（實際上）是隨機的。在 CoreDNS 中，預設情況下，您會獲得基於端點 IP 位址的端點 DNS 名稱

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-14.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-18.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-4.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-9.headless.default.svc.cluster.local.

對於某些應用程式來說，需要使用 Pod 名稱而不是 Pod IP 位址（例如，請參閱 kubernetes#47992 和 coredns#1190）。若要在 CoreDNS 中啟用此功能，您需要在您的 Corefile 中指定 "endpoint_pod_names" 選項，這會產生以下結果

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-qv84p.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-zc8lx.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-q7lf2.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-566rt.headless.default.svc.cluster.local.

自動路徑 (Autopath)

CoreDNS 還具有一項特殊功能，可以改善外部名稱 DNS 請求的延遲。在 Kubernetes 中，Pod 的 DNS 搜尋路徑指定了一個長串的後綴。這使得在請求叢集中的服務時可以使用簡短的名稱 - 例如，上面的 "headless"，而不是 "headless.default.svc.cluster.local"。但是，當請求外部名稱 - 例如 "infoblox.com" 時 - 客戶端會發出多個無效的 DNS 查詢，每次都需要從客戶端到 kube-dns 的往返行程（實際上是到 dnsmasq 然後到 kubedns，因為 停用了負向快取）

  • infoblox.com.default.svc.cluster.local -> NXDOMAIN
  • infoblox.com.svc.cluster.local -> NXDOMAIN
  • infoblox.com.cluster.local -> NXDOMAIN
  • infoblox.com.your-internal-domain.com -> NXDOMAIN
  • infoblox.com -> 傳回有效的記錄

在 CoreDNS 中，可以啟用一個名為 autopath 的可選功能，這將導致在伺服器中遵循此搜尋路徑。也就是說，CoreDNS 將從來源 IP 位址判斷客戶端 Pod 所在的命名空間，並將遍歷此搜尋列表，直到獲得有效的答案。由於前 3 個查詢是在 CoreDNS 內部自行解析的，因此它消除了客戶端和伺服器之間的所有來回通信，從而降低了延遲。

其他一些 Kubernetes 特有功能

在 CoreDNS 中，您可以使用標準 DNS 區域傳輸來匯出整個 DNS 記錄集。這對於偵錯您的服務以及將叢集區域匯入到其他 DNS 伺服器非常有用。

您還可以按命名空間或標籤選擇器進行篩選。這可讓您執行特定的 CoreDNS 實例，這些實例只會服務符合篩選條件的記錄，僅透過 DNS 公開有限的一組服務。

可擴展性

除了上述功能外，CoreDNS 還易於擴展。可以建構包含您自己功能的 CoreDNS 自訂版本。例如，此功能已用於擴展 CoreDNS，以使用 unbound 外掛程式 進行遞迴解析，使用 pdsql 外掛程式 直接從資料庫提供記錄，以及允許使用 redisc 外掛程式 讓多個 CoreDNS 實例共享一個通用二級快取。

已新增許多其他有趣的擴展功能，您可以在 CoreDNS 網站的外部外掛程式頁面中找到。對於 Kubernetes 和 Istio 使用者來說，一個真正有趣的功能是 kubernetai 外掛程式，它允許單個 CoreDNS 實例連接到多個 Kubernetes 叢集，並在所有叢集之間提供服務探索。

下一步？

CoreDNS 是一個獨立專案，因此正在開發許多與 Kubernetes 沒有直接關聯的功能。但是，其中許多功能將在 Kubernetes 中有應用。例如，即將到來的與策略引擎的整合將允許 CoreDNS 在請求無頭服務時，對要傳回哪個端點做出明智的選擇。這可以用於將流量路由到本機 Pod，或路由到反應更靈敏的 Pod。許多其他功能正在開發中，當然，作為一個開源專案，我們歡迎您提出並貢獻您自己的功能！

上面描述的功能和差異只是一些範例。您可以使用 CoreDNS 做更多的事情。您可以在 CoreDNS 部落格上找到更多資訊。

參與 CoreDNS

CoreDNS 是一個孵化中的 CNCF 專案。

我們在 Slack (和 GitHub) 上最活躍

可以找到更多資源