本文分享自華為云社區(qū)《華為云分布式云原生UCS，助力MetaERP構建企業(yè)級高可用分布式業(yè)務》，作者：云容器大未來。

引言

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

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

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

技術背景

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

但是，近來不斷出現(xiàn)的各種單集群故障導致嚴重的業(yè)務故障的案例，給最終客戶帶來了極大的不便，單個 Kubernetes 集群在越來越多可用性要求較高的場景下遇到了嚴重挑戰(zhàn)。Kubernetes 自身作為一個軟件平臺，其控制面和數(shù)據(jù)面自身組件的潛在故障經(jīng)過廠商的保證，發(fā)生幾率不高，但一旦發(fā)生會產(chǎn)生極大的影響。 特別是近來業(yè)內(nèi)多個重大的故障案例中單集群Kubernetes 版本的原地升級異常，導致集群內(nèi)部署的所有業(yè)務不可用，引發(fā)了全局的業(yè)務斷服宕機。

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

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

方案

節(jié)點、AZ等傳統(tǒng)環(huán)境故障容災

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

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

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

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

集群軟件故障容災

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

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

集群升級故障容災

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

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

以下是詳細的操作步驟：

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

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

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

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

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

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

入口和內(nèi)部流量統(tǒng)一多活策略

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

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

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

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

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

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

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

總結

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

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

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

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

參考：

• 《Forrester Wave?: Multicloud Container Platforms, Q4 2023》測評：華為云成為中國唯一入選多云容器平臺報告的云廠商-華為云
• 中國信通院分布式云原生能力評估：https://mp.weixin.qq.com/s/ba7kIS8C4p-Ue3L3DgwWtA
• Karmada晉級CNCF孵化項目：https://www.cncf.io/blog/2023/12/12/karmada-brings-kubernetes-multi-cloud-capabilities-to-cncf-incubator/

點擊關注，第一時間了解華為云新鮮技術~文章來源地址http://www.zghlxwxcb.cn/news/detail-778806.html

到了這里，關于華為云分布式云原生UCS，助力MetaERP構建企業(yè)級高可用分布式業(yè)務的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！