本文是深度解析Kubernetes 1.11新功能系列之一。

介紹

在Kubernetes 1.11中，CoreDNS已經實現了基於DNS的服務發現的GA，可作為kube-dns外掛的替代品。這意味著CoreDNS將作為各種安裝工具未來發布版本中的一個選項來提供。事實上，kubeadm團隊選擇將其作為Kubernetes 1.11的預設選項。

使用kube-dns叢集外掛，基於DNS的服務發現已成為Kubernetes的一部分。這通常很有效，但是對於實施的可靠性、靈活性和安全性存在一些擔憂。

CoreDNS是一個通用的、權威的DNS伺服器，提供與Kubernetes後向相容但可擴充套件的整合。它解決了kube-dns所遇到的問題，並提供了許多獨特的功能，可以解決各種各樣的用例。

在本文中，你將瞭解kube-dns和CoreDNS的實施差異，以及CoreDNS提供的一些有用的擴充套件。

實施差異

在kube-dns中，一個pod內使用了數個容器：kubedns、dnsmasq和sidecar。 kubedns容器監視Kubernetes API並基於Kubernetes DNS規範提供DNS記錄，dnsmasq提供快取和存根域支援，sidecar提供指標和健康檢查。

此設定會導致一些問題隨著時間的推移而出現。首先，dnsmasq中的安全漏洞導致過去需要釋出Kubernetes安全補丁。此外，由於dnsmasq處理存根域，但kubedns處理External Services，因此你無法在外部服務中使用存根域，這非常限制該功能（參閱dns＃131）。

在CoreDNS中，所有這些功能都在一個容器中完成——該容器執行用Go編寫的程序。啟用的不同外掛來複制（並增強）kube-dns中的功能。

配置CoreDNS

在kube-dns中，你可以修改ConfigMap以改變服務發現的行為。這允許新增諸如提供服務存根域、修改上游名稱伺服器以及啟用聯合之類的功能。

在CoreDNS中，你同樣可以修改CoreDNS Corefile的ConfigMap以更改服務發現的工作方式。Corefile配置提供了比kube-dns更多的選項，因為它是CoreDNS用於配置其所有功能（甚至是那些與Kubernetes無關的功能）的主要配置檔案。

使用kubeadm從kube-dns升級到CoreDNS時，現有的ConfigMap將用於為你生成自定義Corefile，包括存根域、聯合和上游名稱伺服器的所有配置。有關更多詳細資訊，請參閱《使用CoreDNS進行服務發現》。

bug修復和增強功能

kube-dns有幾個還沒解決的問題，而這些問題在CoreDNS中得到解決，無論是預設配置還是某些自定義配置。

——dns＃55：kube-dns的自定義DNS條目可以通過使用kubernetes外掛中的“fallthrough”機制、使用重寫外掛或者僅使用不同的外掛（如檔案外掛）提供子區域來處理。

——dns＃116：只有一個A記錄集用於具有單個主機名的pod無頭服務。此問題已修復，無需任何其他配置。

——dns＃131： externalName不使用stubDomains設定。此問題已修復，無需任何其他配置。

——dns＃167：啟用skyDNS迴圈A / AAAA記錄。可以使用負載均衡外掛配置等效功能。

——dns＃190：kube-dns無法以非root使用者身份執行。現在通過使用非預設映象解決了此問題，但在將來的版本中它將成為預設的CoreDNS行為。

——dns＃232：將pod hostname修復為dns srv記錄的podname，這是通過下面描述的“endpoint_pod_names”功能支援的增強功能。

指標

預設CoreDNS配置的功能行為與kube-dns相同。但是，你需要知道的一個區別是釋出的指標不同。在kube-dns中，你可以獲得單獨的dnsmasq和kubedns（skydns）指標。在CoreDNS中，有一組完全不同的指標，因為它只是一個單一的程序。你可以在CoreDNS Prometheus外掛頁面上找到有關這些指標的更多詳細資訊。

一些特殊功能

標準CoreDNS Kubernetes配置旨在向後相容之前的kube-dns行為。但是，通過一些配置更改，CoreDNS可以允許你修改DNS服務發現在叢集中的工作方式。許多這樣的功能旨在仍然符合Kubernetes DNS規範：它們增強了功能，但保持向後相容。由於CoreDNS不僅僅是為Kubernetes而設計的，而是一個通用的DNS伺服器，因此除了該規範之外，你還可以做很多事情。

pod verified模式

在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的往返：

• 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 -> returns a valid record

在CoreDNS中，可以啟用一個名為autopath的可選功能。該功能將導致在伺服器中跟蹤此搜尋路徑。也就是說，CoreDNS將從源IP地址中找出客戶端pod所在的名稱空間，並遍歷此搜尋列表，直到獲得有效答案。由於前三個在CoreDNS內部解析，因此它會切斷客戶端和伺服器之間的所有來回，從而減少延遲。

其他Kubernetes特定功能

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

你還可以按名稱空間或標籤選擇器進行過濾。這可以允許你執行特定的CoreDNS例項——這些例項僅服務於與過濾器匹配的記錄，通過DNS公開一組有限的服務。

可擴充套件性

除了上述功能外，CoreDNS還可以輕鬆擴充套件。可以構建CoreDNS的自定義版本。例如，此功能已用於擴充套件CoreDNS以使用未繫結外掛進行遞迴解析，使用pdsql外掛直接從資料庫服務記錄，並允許多個CoreDNS例項與redisc外掛共享公共2級快取。

還添加了許多其他有趣的擴充套件——你可以在CoreDNS站點的External Plugins頁面上找到它們。Kubernetes和Istio使用者真正感興趣的是kubernetai外掛，它允許單個CoreDNS例項連線到多個Kubernetes叢集並提供跨所有這些叢集的服務發現。

下一步是什麼？

CoreDNS是一個獨立的專案，因此正在開發許多與Kubernetes沒有直接關係的功能。但是，其中一些將在Kubernetes中有應用。例如，即將與策略引擎的整合將允許CoreDNS在請求無頭服務時做出關於返回哪個端點的智慧選擇。這可用於將流量路由到本地pod或更具響應性的pod。許多其他功能正在開發中，當然作為一個開源專案，我們歡迎你提出建議並做出貢獻！

上面描述的功能和差異是一些示例。CoreDNS可以做更多的事情，你可以在CoreDNS部落格上找到更多資訊。

參與CoreDNS

CoreDNS是一個孵化的CNCF專案。我們在Slack（和Github）最活躍——Slack：https：//slack.cncf.io上的#coredns；Github：https：//github.com/coredns/coredns。

可以找到更多資源——網站：https：//coredns.io；部落格：https：//blog.coredns.io；Twitter：@corednsio；郵件列表/組：[email protected]。

譯者：Karen Lee

來源：

https://kubernetes.io/blog/2018/07/10/coredns-ga-for-kubernetes-cluster-dns/