引言

華為云最近成為《Forrester Wave?: Multicloud Container Platforms, Q4 2023》報告中唯一入選的中國廠商，市場表現強勁。華為云分布式云原生 UCS 作為本次參評的關鍵服務，其在多云容器應用中的價值獲得了測評的一致認可。同時 12 月初，UCS 通過中國信息通信研究院分布式云原生能力測評，華為云成為首批通過分布式云原生能力評估的企業。

對于 UCS 來說，除了來自權威機構的認定外，越來越多的來自最終用戶的大規模生產實踐才是對 UCS 能力的最大認可。特別是近來頻發的單集群現網事故，使得基于多集群的容災多活引起了越來越多的關注，引發了對服務可用性的更深入思考。

本文將結合華為 MetaERP 的生產應用案例詳細介紹 UCS 多集群的容災多活實踐。MetaERP 業務復雜，服務規模大，可用性要求高。基于 UCS 的多集群方案，在兼容原有單集群流水線、運維工具、監控視圖的前提下，不僅提供了原有單集群的基于節點、AZ 等傳統環境故障的容災能力，同時也提供了多集群特有的集群整體故障、軟件故障容災。在整個生產實踐中，客戶反饋最重要的是多集群方案引入的灰度集群環境解決了單集群本地升級風險的問題，全面提升了服務可用性。

技術背景

隨著以 Kubernetes 為核心的云原生技術的普及和應用，越來越多的大規模生產業務都運行在 Kubernetes 平臺上。其提供了便捷的容器實例擴縮容、極致的負載彈性、無縫的應用遷移，幫助用戶構建大規模、擴展性要求高的云原生應用。此外 Kubernetes 提供的節點、AZ 等反親和部署能力，在單個節點或者整個 AZ 故障時，保證有一定的可用實例提供服務，客觀上也幫助用戶提高了應用的可用性。

但是，近來不斷出現的各種單集群故障導致重大業務故障的案例，給最終客戶帶來了極大的不便，單個 Kubernetes 集群在越來越多可用性要求較高的場景下遇到了嚴重挑戰。Kubernetes 自身作為一個軟件平臺，其控制面和數據面自身組件的潛在故障經過廠商的保證，發生幾率不高，但一旦發生會產生業務停頓、數據丟失等極大的影響。特別是近來業內多個重大的故障案例中單集群 Kubernetes 版本的異常原地升級，導致集群內所有業務癱瘓，引發了全局的業務斷服宕機。

這種現象的根本原因是存在一個無限大的爆炸半徑。就像把所有雞蛋放在一個結實的籃子里，一旦籃子有問題，沒有一個雞蛋能幸存。更糟糕的是隨著業務增長，這個早期還是結實能用的籃子，隨著時間推移越來越破舊，但這個過程中卻有更多的雞蛋一直不斷地塞進來，因此籃破蛋打是早晚要面對的事。解決這類問題的直觀且根本的思路是減小爆炸半徑，把雞蛋分開放到多個籃子里。

理論上這個道理很簡單，不要垂直擴展單個集群，而是水平擴展集群數。但是真正實踐中并沒有這么簡單。MetaERP 客戶早期選擇把大量服務集中部署在大集群的一個主要原因是想降低平臺的運維成本，單個 Kubernetes 集群的運維已經耗費了團隊很多精力，多個 Kubernetes 集群理論上會導致管理和運維成本線性地增加。在 MetaERP 為代表的大規模企業應用實踐中，面臨多個復雜問題: 如何靈活地控制負載和多種資源對象在多個集群間部署、升級、彈性擴展；如何管理多集群的入口流量；如何控制多集群的內部流量。總的來說，即如何將理論上的多集群可用性轉化為客戶的實際價值。最重要的是 MetaERP 希望多集群能力與其原有的單集群使用方式兼容，包括原有單集群命令行工具、CICD 流水線、擴展組件調用的集群 API 等盡量保持不變，同時保持面向應用的多集群統一的資源管理視圖、監控運維視圖等，UCS 的多集群解決方案逐一解決了以上問題。

方案

節點、AZ 等傳統環境故障容災

首先，UCS 內置的 Karmada 多集群資源管理允許用戶根據策略動態地將負載分布式部署到艦隊管理的多個集群中。每個集群管理的節點來自不同的可用區 (AZ), 因此負載的各個實例被智能地分布在不同的可用區，從而具備了跨可用區的高可用性。

當某個節點發生故障時，該節點上的負載實例不可用。此時，訪問該服務的流量不僅會被重新分發到本集群其他節點的對應副本，還會分發到其他集群中對應的副本，確保了服務的整體可用性。

當某個 AZ 故障時，該區域的節點全部失效，導致負載實例不可用。流量自動轉移到其他集群，即其他 AZ 的對應副本上，用戶的業務完全不受影響。

通過以上分析，UCS 多集群方案覆蓋了 MetaERP 原有的單集群提供的 AZ 級別、節點級別的服務可用性，同時還增加了單集群不具備的功能，幫助全面提高業務的可用性。

集群軟件故障容災

除了環境故障外，另外一個可能對業務產生潛在影響的是集群軟件自身的故障，雖然這種故障發生的幾率低，但是一旦發生，對業務影響很大。在客戶應用中曾經出現過 Kube-apiserver 過載導致集群故障、集群數據面異常導致負載不能正常創建等問題。在單集群環境下，基于常規的故障檢測和倒換機制，平臺和業務可采取的有效手段非常有限。

基于 UCS 多集群方案，當檢測到一個集群故障時，Karmada 可以動態地將目標是該故障集群的流量切換到另外一個可用集群的服務后端上。同時根據策略配置，可以動態地將負載實例從故障集群遷移到其他可用集群。也支持用戶根據自身對業務的判斷，在緊急情況下，當發現一個集群狀態不健康時，管理員可以將一個集群的負載整體隔離掉，快速高效地進行故障隔離，最大限度保證業務總體可用性。

集群升級故障容災

在實踐中，UCS 多集群方案為 MetaERP 業務帶來最大收益在于集群升級過程的保障。在業務升級中，引入各種灰度升級策略是常見的做法，然而，在集群平臺升級時，應用這種灰度機制卻相當困難。如果待升級集群版本本身存在問題或與現有業務不兼容，可能導致現有業務受升級影響。例如，集群升級 Master 證書不匹配、容器文件系統變更影響 Jar 包加載順序導致應用啟動異常，或者不當的現網集群版本升級路徑導致集群無法正常啟動等問題，都可能導致整個集群的業務受影響。

通過 UCS 多集群方案，用戶在升級時可選擇一個集群作為獨立的灰度環境進行升級，等待最終業務驗收確認升級成功后再升級另一個集群。這種方式避免了在單集群場景下，集群升級失敗導致全部業務不可用的情況。

以下是詳細的操作步驟:

1.在業務低谷時間窗內進行集群升級。首先，選擇一個待升級的集群作為灰度環境，并配置規則將全部流量切換到另一個集群。

2.對灰度集群的平臺組件執行升級，并觀察各個組件的正常運行情況。

3.觀察灰度集群內負載的運行情況，確保負載與灰度集群環境匹配并正常運行。

4.將少量流量切換至灰度集群，進行部分負載的灰度發布，從最終業務視角觀察服務的運行狀態。當基于業務確認灰度集群運行正常時，逐步將全量流量切換至灰度集群。

5.對另一個集群執行灰度升級過程，確保每個集群都經過類似的測試和確認。

在以上的第二到第四步驟中，如果出現問題，可以立即修復灰度集群，而不會影響最終用戶的訪問。通過這種集群灰度升級的方式，確保升級過程中出現的問題不會對用戶業務造成影響。

入口和內部流量統一多活策略

與傳統的容災多活僅僅基于入口流量控制不同，UCS 與高性能服務網格集成，能夠在應用內部執行一致的流量動作。在容災場景下，通過網格代理和入口 Gateway 基于統一的流量策略進行切換。對于同一目標服務，無論流量源自內部服務訪問還是外部訪問，都可以根據統一的策略隔離異常實例，確保服務的高可用性。

流量遷移伴隨應用遷移多重能力

在許多容災解決方案中，僅僅切換流量可能看似解決了主要問題，但實際上仍然存在不完善之處。在前述場景中，將流量從一個被標記為不健康的集群實例隔離后，實際提供服務的后端數量可能會少于用戶最初預期的數量，從客觀上來說，這會導致服務整體能力受損，這顯然不滿足 MetaERP 可用性要求高的業務。UCS 提供的多集群故障遷移方案不僅僅局限于流量切換，還結合了跨集群負載遷移和根據用戶實際場景進行的數據遷移，構建了立體化的故障應對機制。也就是說，除了保證業務連續性通過流量切換外，還通過多集群中的負載管理，在異常集群中的負載遷移到其他集群中，確保始終有足夠數量的負載實例向用戶提供服務，以確保服務的可用性。這種結合了流量遷移和負載遷移的方式，保障了用戶業務的可用性，確保了總體服務質量符合用戶期望。

單集群一致體驗，簡化運維

UCS 多集群容災方案中以集群粒度進行故障管理，與僅能在實例、節點或 AZ 粒度進行故障檢測和隔離的單集群方案不同，能夠快速隔離整個集群以實現故障快速隔離，從而提升應用的可用性。但這些能力的提供并未增加用戶的管理和運維復雜度。UCS 多集群艦隊提供了與單集群完全兼容的 API 和對象模型，使得原有的單集群運維平臺工具可以無縫對接。MetaERP 原有流水線無需過多修改即可連接艦隊 API, 實現集群 Deployments、Service、Secret、ConfigMap、Role、RoleBinding 等 Kubernetes 資源的創建、升級。

同時，UCS 基于 Karmada 的多集群資源管理能力，根據用戶配置的策略將艦隊級別的資源分發到艦隊管理的多個集群。MetaERP 運維人員可以通過原有的 Kubernetes 命令行工具對艦隊中的資源進行統一運維管理，與單集群體驗基本一致。此外，面向應用的艦隊級別監控視圖也與單集群內的業務監控保持一致。

多集群的采用不僅突破了單集群的容量限制，還大幅提升了平臺的總體容量，滿足了 MetaERP 業務的大規模增長需求。

總結

在 MetaERP 基于 UCS 多集群方案中，不僅涵蓋了傳統容災場景中資源和環境故障的處理，還包括了應對平臺自身、軟件故障以及平臺升級過程的能力，顯著增強了業務的整體可用性。這種方案不受限于云上同 Region 多 AZ 的部署方式，也能靈活適用于跨 Region 環境、多云環境和混合云環境。通過基于分布式環境的部署，它能有效地管理多集群的負載和流量，在分布式云環境中實現容災多活，進一步提高用戶業務的可用性。

這里介紹到的多集群能力只是分布式云原生 UCS 產品功能的一部分。分布式云為用戶提供了將云能力根據其場景分發到各個物理位置的靈活性，同時通過在云上統一管理運維，簡化了用戶的使用。作為業界最早的分布式云產品，華為云的分布式云原生 UCS 采用云原生方式將廠商的硬件、軟件、基礎架構和服務分發到用戶數據中心、邊緣、其他云等多種位置，以滿足用戶對低時延、本地數據處理、數據駐留合規性或容災多活等應用場景的需求。在基于多云多集群高可用的分布式應用管理基礎上，在多集群的艦隊上構建全域統一的動態流量、應用配置、零信任安全、DevOps、應用運維等能力，滿足 MetaERP 等大規模企業用戶不斷增長的應用現代化需求。

同時，UCS 多集群方案的核心組件 Karmada 在服務分布式云原生客戶場景中持續成熟，并于本月正式晉級為 CNCF 孵化項目。未來，Karmada 將繼續探索云原生多集群領域的技術創新，讓基于 Karmada 的多云方案更深度地融入云原生技術生態。

未來，UCS 將持續引領多云容器平臺的發展，助力用戶實現更高效、更智能的云原生應用部署與管理。

廣告聲明：文內含有的對外跳轉鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節省甄選時間，結果僅供參考，所有文章均包含本聲明。

投訴水文 我要糾錯

總結

以上是生活随笔為你收集整理的华为云分布式云原生 UCS 助力 MetaERP 构建企业级高可用分布式业务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。