基於 CoreDNS 和 K8s 構建雲原生場景下的企業級 DNS

容器作為近些年最火熱的後端技術，加快了很多企業的數字化轉型程序。目前的企業，不是在使用雲原生技術，就是在轉向雲原生技術的過程中。在容器化程序中，如何保持業務的平穩遷移，如何將現有的一些服務設施一併進行容器化遷移，也是眾多企業較為關注的點。

以 DNS 為例，如何構建一個雲原生的企業 DNS 系統？

CoreDNS 簡介

CoreDNS 是一個 Go 語言編寫的靈活可擴充套件的 DNS 伺服器，在 Kubernetes 中，作為一個服務發現的配置中心，在 Kubernetes 中建立的 Service 和 Pod 都會在其中自動生成相應的 DNS 記錄。Kubernetes 服務發現的特性，使 CoreDNS 很適合作為企業雲原生環境的 DNS 伺服器，保障企業容器化和非容器化業務服務的穩定執行。

構建企業 DNS 伺服器時，一般會有以下需求：

• 使用者外網域名訪問服務；
• 混合雲業務遷移、資料共享、容災；
• 開發程式碼 IP 寫死導致架構可用性、彈性無法實現；
• 統一 DNS 管理需求，含上下級平臺對接；
• DNS 劫持等網路安全風險；
• 存量程式碼固定域名訪問；
• 叢集外域名訪問；

相比於 Bind 開源方案或 Windows Server DNS 商業 DNS 伺服器，CoreDNS 有以下優勢：

• 無商業許可要求，降低投資成本；
• 輕量化，通過外掛實現功能新增；
• 支援 DNS，DNS over TLS，DNS over HTTP/2，DNS over gRPC 協議；
• 提供 kubernetes 服務發現；
• 支援對接 Route53/Google Cloud DNS/AzureDNS；
• 支援整合 Prometheus， OpenTracing，OPA，帶來更全面的運維體驗；
• 支援整合容器管理平臺，提供統一 DNS 系統運維。

構建企業雲原生 DNS 前，對 CoreDNS 做一個更深入的瞭解。

CoreDNS 執行原理與外掛介紹

CoreDNS 基於 Caddy 框架實現模組化設計，每個外掛承載相應的具體功能，對於 DNS 系統而言，CoreDNS 使用 File，ETCD 外掛等載入 DNS 記錄，使用 Kubernetes 外掛實現叢集服務發現，外部 DNS 請求到達 CoreDNS 後，根據外掛呼叫鏈依次處理 DNS 請求。

CoreDNS 社群官方提供了 50 多種外掛，開發者亦可根據需求開發個性化的外部外掛。CoreDNS 常用外掛如下圖，根據使用場景，可分為運維、DNS 處理、後端資料儲存等三個類別。

CoreDNS 定義 Corefile 配置檔案，伺服器在載入 Corefile 後處理 DNS 請求，對於以下外掛，只需在 Corefile 中引用即可，之後 CoreDNS 會使用外掛鏈進行呼叫，外掛鏈可參考以下連結： ​ ​https://github.com/coredns/coredns/blob/master/plugin.cfg​ ​

設計一個基於 CoreDNS 的分層 DNS 架構

在熟悉 CoreDNS 特性後，可設計企業的 DNS 架構：

DNS 架構以外網 DNS、內網 DNS、分割槽 DNS 組成：

外網 DNS：

• 使用 DNSSEC、DOT、DOH 等保障 DNS 安全；
• 快取 DNS 記錄；
• 構建 DNS 例項自動伸縮，應對高 QPS 需求；

內網 DNS：

• Kubernetes 服務發現；
• 構建上游 DNS 區域；

分割槽 DNS：

• 建立開發、測試、UAT、生產等區域 DNS；
• NodeLocalDNS 提高效能；
• 設定轉發器處理遞迴 DNS 請求；

KubeSphere 部署 CoreDNS

由於 CoreDNS 是一個 CNCF 畢業的雲原生專案，是目前支援雲原生最好的一個 DNS 伺服器，使用者可直接在 KubeSphere 應用商店一鍵安裝。KubeSphere 提供了基於 Helm 模板的應用商店，支援雲原生應用的生命週期管理，提供開發人員應用上傳、測試，版本提交，應用管理人員進行稽核、釋出等流程管理。使用者在應用商店選擇 CoreDNS 應用後，可按需部署於不同叢集的不同專案中，並自定義應用模板配置：

服務發現與 DNS 配置

部署 CoreDNS 後，對於運維人員來說，CoreDNS 的配置大體分為兩類：一類為 Kubernetes 配置，一類為 DNS 配置。CoreDNS 提供了 Kubernetes 外掛，支援在 kubernetes 叢集中讀取區域資料，並根據 Pod 和 Service 的域名記載相應的 A 記錄和 PTR 記錄。

這是一個 Kubernetes 叢集中的 CoreDNS corefile 預設配置，CoreDNS 會在 53 埠讀取 cluster.local 字尾的 Kubernetes 叢集 A 記錄和 PTR 記錄。並將 CoreDNS 收集到的監控指標通過 9153 埠輸出到叢集內的 Prometheus。而 Kubernetes 不同型別 Service 的 DNS 記錄格式，CoreDNS 也有相應標準進行記錄。

設定完 Kubernetes 後，可以設定其他業務需求的 DNS 配置，如：

• 設定不同的存根域；
• 設定存根域靜態 DNS 條目；
• 面對存量程式碼，設定域名重寫；
• 面對叢集外服務，設定 DNS 轉發；
• 設定日誌和監控整合；
• 設定快取、健康、就緒檢查及鏈路追蹤；

根據以上配置，就構建了一個基礎的企業雲原生 DNS 系統：

DNS 服務暴露

對於叢集外的服務而言，存量業務可能還是一些虛擬化和裸機的應用，若和叢集網路無法互聯，如何在業務遷移時訪問新的 DNS 服務？

KubeSphere 提供了一個開源專案——OpenELB 來解決雲原生環境下的服務暴露問題，這是一個 CNCF 的沙箱專案。OpenELB 通過物理環境的交換機使用 BGP 協議將 LoadBalancer 型別服務的 ExternalIP 宣告出去，在 IP 可達的環境下叢集外部業務即可通過 EIP 訪問 Kubernetes 服務資源。

對於叢集外需要設定 DNS 伺服器的服務資源，可通過 OpenELB 使用 EIP 暴露 CoreDNS ，即可訪問 DNS 服務 。

在 KubeSphere 3.3 版本，使用者可在開啟叢集閘道器 / 專案閘道器時，在閘道器訪問 LoadBalancer 模式下，選擇“OpenELB”負載均衡提供商，之後建立的 LoadBalancer 服務都會從 OpenELB 建立的 EIP Pool 中分配 EIP，供叢集外部訪問。

DNS 監控運維

為保障 CoreDNS 穩定執行，運維人員還需在基礎設施側完善 DNS 系統的日誌、監控、告警、通知功能，KubeSphere 提供了簡單易用的監控面板、日誌管理與落盤，多維度的告警策略和訊息，以及對接多個企業應用（郵件，釘釘， 企業微信）的通知系統，時刻關注業務執行狀態。

此處以一個系統管理員視角，展示了在 KubeSphere 日誌系統搜尋 NXDOMAIN 型別 DNS 回覆的結果。

通過 KubeSphere 自定義監控面板，設定一個基於 CoreDNS 指標的監控面板，KubeSphere 內建了眾多監控面板，使用者可直接使用模板構建亦可使用 PromQL 建立面板：

通過 KubeSphere 告警和通知元件，使用者可基於預置規則模板（CPU、記憶體、磁碟、網路、異常率）或使用 PromQL 語句自定義告警規則，此處定義當 CoreDNS CPU 用量大於等於 0.1Core 系統觸發告警：

KubeSphere 針對租戶設計了通知模板，包含多種通知系統整合，此處使用郵件將“重要告警”，“危險告警”條件的告警訊息傳送給郵件接收人。

當告警觸發後，即可在告警訊息和通知歷史處檢視到相應的條目，此時使用者也會收到一封告警郵件了：

在高併發 DNS 請求場景中，還需對 CoreDNS 進行自動伸縮設計，通常考慮到服務高可用性和效能考量，可參考以下計算規格和排程策略設計：

• 副本打散，跨可用區 / 節點。
• 避免所在節點 CPU、記憶體過高。
• 通常設計副本數為 2。QPS 與 CPU 消耗正相關，單 CPU——1w+QPS
• Kubernetes 叢集下，CoreDNS 副本數與叢集節點配置 1:8。
• 業務峰值 CPU 佔用 >1Core，水平擴容。

通過 KubeSphere 自動伸縮機制，可設定基於 CPU 用量的自動伸縮策略，保障 CoreDNS 在瞬時高併發場景穩定執行。

總結

以上就是建設一個雲原生的 DNS 系統的全部內容了，可以看出，在雲原生時代，新的技術層出不窮，IT 系統的部門和人員也越發趨於協同作戰，以往構建一個 DNS 系統可能只需要安裝一套穩定能進行 DNS 解析的系統，並實現主備切換即可。在應用驅動基礎架構轉型的雲原生時代，基礎服務應用還更需要考慮異構系統的連線，靈活簡便的安裝升級管理，更強大的可靠性和自愈能力，日誌監控通知系統的完善，還有更適合實際業務需求的彈性設計，來加速應用現代化，推動業務應用持續轉型。