容器作為近些年最火熱的后端技術，加快了很多企業的數字化轉型行程，目前的企業，不是在使用云原生技術，就是在轉向云原生技術的程序中，在容器化行程中，如何保持業務的平穩遷移，如何將現有的一些服務設施一并進行容器化遷移，也是眾多企業較為關注的點，
以 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 決議的系統，并實作主備切換即可，在應用驅動基礎架構轉型的云原生時代，基礎服務應用還更需要考慮異構系統的連接，靈活簡便的安裝升級管理，更強大的可靠性和自愈能力，日志監控通知系統的完善，還有更適合實際業務需求的彈性設計，來加速應用現代化，推動業務應用持續轉型，
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/509177.html
標籤：其他
上一篇：虛擬機環境配置1