基於 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 會使用插件鏈進行調用，插件鏈可參考以下鏈接： ​ ​http://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 解析的系統，並實現主備切換即可。在應用驅動基礎架構轉型的雲原生時代，基礎服務應用還更需要考慮異構系統的連接，靈活簡便的安裝升級管理，更強大的可靠性和自愈能力，日誌監控通知系統的完善，還有更適合實際業務需求的彈性設計，來加速應用現代化，推動業務應用持續轉型。