苹果14pro下载

苹果14pro

引言

華為雲最近成為《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 將持續引領多雲容器平台的發展，助力用戶實現更高效、更智能的雲原生應用部署與管理。

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