簡介： 為了讓開發者、用戶在多集群和混合環境下也能像在單個 Kubernetes 集群平臺上一樣，使用自己熟悉的開源項目和產品輕松開發功能，RedHat 和螞蟻、阿里云共同發起并開源了 OCM（Open Cluster Management，項目官網 （_https://open-cluster-management.io/_），旨在解決多集群、混合環境下資源、應用、配置、策略等對象的生命周期管理問題。目前，OCM 已向 CNCF TOC 提交 Sandbox 級別項目的孵化申請。 ?

作者：馮泳（鹿驚）

在云計算領域如果還有人沒聽過 Kubernetes，就好像有人不知道重慶火鍋必需有辣椒。Kubernetes 已經像手機上的 Android ，筆記本上的 Windows 一樣成為管理數據中心事實上的標準平臺了。圍繞著 Kubernetes ，開源社區構建了豐富的技術生態，無論是 CI/CD、監控運維，還是應用框架、安全反入侵，用戶都能找到適合自己的項目和產品。可是，一旦將場景擴展到多集群、混合云環境時，用戶能夠依賴的開源技術就屈指可數，而且往往都不夠成熟、全面。
?

為了讓開發者、用戶在多集群和混合環境下也能像在單個 Kubernetes 集群平臺上一樣，使用自己熟悉的開源項目和產品輕松開發功能，RedHat 和螞蟻、阿里云共同發起并開源了 OCM（Open Cluster Management，項目官網 （_https://open-cluster-management.io/_），旨在解決多集群、混合環境下資源、應用、配置、策略等對象的生命周期管理問題。目前，OCM 已向 CNCF TOC 提交 Sandbox 級別項目的孵化申請。

Open Cluster Management

多集群管理發展歷史

讓我們把時間拉回到幾年前，當業界關注/爭論的焦點還在 Kubernetes 是否生產級可用的時候，就出現了最早一批登陸“多集群聯邦”技術的玩家。它們大都是體量上遠超平均水準的 Kubernetes 實踐先驅，從最早 Redhat 、谷歌入場做了 KubeFed v1 的嘗試，再到后來攜手 IBM 吸取經驗又推出 KubeFed v2 。除了這些大型企業在生產實踐 Kuberentes 的場景中探索多集群聯邦技術，在商業市場上，各個廠商基于 Kubernetes 包裝的服務產品也大多經歷了從單集群產品服務到多集群形態、混合云場景進化的過程。其實，無論是企業自身還是商業用戶都有共性的需求，聚焦在以下幾個方面：
?

多地域問題：當集群需要在異構基礎設施上或者橫跨更廣地域進行部署。

**

Kubernetes 集群依賴 etcd 作為數據持久層，而 etcd 作為分布式系統對系統中各個成員之間的網絡延遲上有要求，對成員的數量也有一些限制，雖然在延遲能夠容忍的情況下可以通過調整心跳等參數適配，但是不能滿足跨國跨洲的全球性部署需求，也不能保證規模化場景下可用區的數量，于是為了讓 etcd 至少可以穩定運行，一般會按地域將 etcd 規劃為多個集群。此外，以業務可用和安全性為前提，混合云架構越來越多地被用戶接受。跨越云服務提供商很難部署單一 etcd 集群，隨之對應的，Kubernetes 集群也被分裂為多個。當集群的數量逐漸增多，管理員疲于應對時，自然就需要一個聚合的管控系統同時管理協調多個集群。

規模性問題：當單集群規模性遇到瓶頸。

**

誠然，Kubernetes 開源版本有著明顯的規模性瓶頸，然而更糟糕是，我們很難真正量化 Kubernetes 的規模。社區一開始提供了 kubemark 套件去驗證集群的性能，可是現實很骨感，kubemark 所做的事情基于局限于在不同節點數量下反復對 Workload 進行擴縮容調度。可是實踐中造成 Kubernetes 性能瓶頸的原因復雜、場景眾多，kubemark 很難全面客觀描述多集群的規模性，只能作為非常粗粒度下的參考方案。后來社區支持以規模性信封來多維度衡量集群容量，再之后有了更高級的集群壓測套件 perf-tests。當用戶更清晰地認識到規模性的問題之后，就可以根據實際場景（比如 IDC 規模、網絡拓撲等）提前規劃好多個 Kubernetes 集群的分布，多集群聯邦的需求也隨之浮出水面。
**

容災/隔離性問題：當出現更多粒度的隔離和容災需求。

**

業務應用的容災通過集群內的調度策略，將應用部署到不同粒度的基礎設施可用區來實現。結合網絡路由、存儲、訪問控制等技術，可以解決可用區失效后業務的連續性問題。但是如何解決集群級別，甚至是集群管理控制平臺自身的故障呢？
?

etcd 作為分布式系統可以天然解決大部分節點失敗的問題，可是不幸的是實踐中 etcd 服務也還是可能出現宕機的狀況，可能是管理的操作失誤，也可能是出現了網路分區。為了防止 etcd 出現問題時“毀滅世界”，往往通過縮小“爆炸半徑”來提供更粒度的容災策略。比如實踐上更傾向于在單個數據中心內部搭建多集群以規避腦裂問題，同時讓每集群成為獨立的自治系統，即使在出現網絡分區或者更上層管控離線的情況下可以完整運行，至少穩定保持現場。這樣自然就形成了同時管控多個 Kubernetes 集群的需求。
?

另一方面，隔離性需求也來自于集群在多租戶能力上的不足，所以直接采取集群級別的隔離策略。順帶一提的好消息是 Kubernetes 的控制面公平性/多租戶隔離性正在一磚一瓦建設起來，通過在 1.20 版本進入 Beta 的 API Priority And Fairness 特性，可以根據場景主動定制流量軟隔離策略，而不是被動的通過類似 ACL 進行流量的懲罰限流。如果在最開始進行集群規劃的時候劃分為多個集群，那么隔離性的問題自然就解決了，比如我們可以根據業務給大數據分配獨占集群，或者特定業務應用分配獨占請集群等等。
?

OCM 的主要功能和架構

OCM 旨在簡化部署在混合環境下的多 Kubernetes 集群的管理工作。可以用來為 Kubernetes 生態圈不同管理工具拓展多集群管理能力。OCM 總結了多集群管理所需的基礎概念，認為在多集群管理中，任何管理工具都需要具備以下幾點能力：
?

理解集群的定義

通過某種調度方式選擇一個或多個集群

分發配置或者工作負載到一個或多個集群

治理用戶對集群的訪問控制

部署管理探針到多個集群中

?

OCM 采用了 hub-agent 的架構，包含了幾項多集群管理的原語和基礎組件來達到以上的要求：
?

• 通過 Managed Cluster API 定義被管理的集群，同時 OCM 會安裝名為 Klusterlet 的 agent 在每個集群里來完成集群注冊，生命周期管理等功能。

?

• 通過 Placement API 定義如何將配置或工作負載調度到哪些集群中。調度結果會存放在 Placement Decision API 中。其他的配置管理和應用部署工具可以通過 Placement Decisiono 決定哪些集群需要進行配置和應用部署。

?

• 通過 Manifest Work API 定義分發到某個集群的配置和資源信息。

?

• 通過 Managed Cluster Set AP 對集群進行分組，并提供用戶訪問集群的界限。

?

• 通過 Managed Cluster Addon API 定義管理探針如何部署到多個集群中以及其如何與 hub 端的控制面進行安全可靠的通信。

架構如下圖所示，其中 registration 負責集群注冊、集群生命周期管理、管理插件的注冊和生命周期管理；work 負責資源的分發；placement 負責集群負載的調度。在這之上，開發者或者 SRE 團隊能夠基于 OCM 提供的 API 原語在不同的場景下方便的開發和部署管理工具。

?

通過利用 OCM 的 API 原語，可以簡化許多其他開源多集群管理項目的部署和運維，也可以拓展許多 Kubernetes 的單集群管理工具的多集群管理能力。例如：
?

簡化 submariner 等多集群網絡解決方案的管理。利用 OCM 的插件管理功能將 submariner 的部署和配置集中到統一的管理平臺上。

為應用部署工具（KubeVela, ArgoCD等）提供豐富的多集群負責調度策略和可靠的資源分發引擎。

拓展現有的 kuberenetes 單集群安全策略治理工具（Open Policy Agent，Falco 等）使其具有多集群安全策略治理的能力。

?

OCM 還內置了兩個管理插件分別用來進行應用部署和安全策略管理。其中應用部署插件采用了訂閱者模式，可以通過定義訂閱通道（Channel）從不同的源獲取應用部署的資源信息，其架構如下圖所示：
?

?

同時為了和 kubernetes 生態系統緊密結合，OCM 實現了 kubernetes sig-multicluster 的多個設計方案，包括 KEP-2149 Cluster ID 和 KEP-1645 Multi-Cluster Services API 中關于clusterset 的概念。也在和其他開發者在社區共同推動 Work API ?的開發。
?

OCM 的主要優勢

?

高度模塊化 --- 可自由選擇/剪裁的模塊

?

整個 OCM 架構很像是“微內核”操作系統，OCM 的底盤提供核心能力集群元數據抽象等等服務，而其他擴展能力都是作為獨立組件可拆分的進行部署。如上圖所示 OCM 的整個方案里除了最核心的能力部分之外，其他上層的能力都是可以根據實際需求進行裁剪的，比如如果我們不需要復雜集群拓撲關系，那么就可以剪裁掉集群分組相關的模塊，如果我們不需要通過 OCM 下發任何資源僅作為元數據使用，那么甚至可以剪裁掉整個資源下發的 Agent 組件。這也有利于引導用戶逐步登陸 OCM ，在初期用戶可能只需要用到很小的一部分功能，再隨著場景拓展慢慢引入更多的特性組件，甚至同時支持在正在運行中的控制面上熱插拔。
?

更具有包容性 --- 復雜使用場景的瑞士軍刀

?

整個 OCM 方案在設計之初就考慮到通過集成一些第三方主流的技術方案進行一些復雜場景高級能力的建設。比如為了支持更復雜的應用資源渲染下發，OCM 支持以 Helm Chart 的形式安裝應用且支持載入遠程 Chart 倉庫。同時也提供了 Addon 框架以支持使用方通過提供的擴展性接口定制開發自己的需求，比如 Submarine 就是基于 Addon 框架開發的多集群網絡信任方案。
?

易用性 --- 降低使用復雜性

為了降低用戶的使用復雜度以及遷移到 OCM 方案的簡易度，OCM 提供了傳統指令式的多集群聯邦控制流程。值得注意的是以下提及功能尚在研發過程中，將在后續版本和大家正式見面：
?

• 通過 Managed Cluster Action 我們可以向被納管的集群逐個下發原子指令，這也是作為一個中樞管控系統自動化編排各個集群最直觀的做法。一個 Managed Cluster Action 可以有自己的指令類型，指令內容以及指令執行的具體狀態。
• 通過 Managed Cluster View 我們可以主動將被納管集群中的資源“投射”到多集群聯邦中樞系統中，通過讀取這些資源在中樞中的“投影”，我們可以在聯邦系統中進行更動態準確的決策。

?

OCM 在螞蟻集團的實踐

?

OCM 技術已經應用到螞蟻集團的基礎設施中，作為第一步，通過運用一些類似與社區 Cluster API 的運維手段將 OCM Klusterlet 逐個部署到被管理的集群中去，從而把螞蟻域內幾十個線上線下集群的元信息統一接入到了OCM中。這些 OCM Klusterlet 為上層的產品平臺提供了多集群管理運維的基礎能力方便以后的功能擴展。具體來講 OCM 第一步的落地內容包括以下方面：

• 無證書化：在傳統的多集群聯邦系統中，我們往往需要給各個集群的元數據配置上對應的集群訪問證書，這也是 KubeFed v2 的集群元數據模型里的必需字段。由于 OCM 整體采用了 Pull 的架構，由部署在各個集群中的 Agent 從中樞拉取任務并不存在中樞主動訪問實際集群的過程，所以每份集群的元數據都只是徹底“脫敏”的占位符。同時因為證書信息不需要進行存儲所以在 OCM 方案中不存在證書被拷貝挪用的風險。

?

• 自動化集群注冊：先前集群注冊的流程中存在較多人工干預操作的環節拉長了協作溝通時間的同時又損失了變更靈活性，比如站點級別或者機房級別的彈性。在很多場景下人工的核驗必不可少，可以充分利用 OCM 集群注冊提供的審核和驗證能力，并將他們集成進域內的批準流程工具，從而實現整個集群自動化的注冊流程，達成以下目標 ：

(1) 簡化集群初始化/接管流程 。(2) 更清晰地控制管控中樞所具備的權限。

?

• 自動化集群資源安裝/卸載：所謂接管主要包括兩件事情 (a) 在集群中安裝好管理平臺所需的應用資源 (b) 將集群元數據錄入管理平臺。對于 (a) 可以進一步分為 Cluster 級別和 Namespace 級別的資源，而 (b) 一般對于上層管控系統是個臨界操作，從元數據錄入的那一刻之后產品就被認為接管了集群。在引入OCM 前，所有的準備的工作都是需要人工推動一步一步準備。通過 OCM 整個流程可以自動化，簡化人工協作溝通的成本。這件事情的本質是將集群納管梳理成一個流程化的操作，在集群元數據之上定義出狀態的概念讓產品中樞可以流程化地自動化接管所要做的”瑣事“。在 OCM 中注冊好集群之后資源的安裝與卸載流程都被清晰的定義了下來。

?

通過上述工作，螞蟻域內的數十個集群都在 OCM 的管理范圍內。在雙十一等大促活動中，自動創建和刪除的集群也實現了自動化的接入和刪除。后面也計劃了與 KubeVela 等應用管理技術集成，協同完成應用，安全策略等在螞蟻域內的云原生化管理能力。
?

OCM 在阿里云的實踐

?

在阿里云，OCM 項目則是 KubeVela ?面向混合環境進行無差別應用交付的核心依賴之一。KubeVela 是一個基于開放應用模型（OAM）的“一站式”應用管理與交付平臺，同時也是目前 CNCF 基金會托管的唯一一個云原生應用平臺項目。在功能上，KubeVela 能夠為開發者提供端到端的應用交付模型，以及灰度發布、彈性伸縮、可觀測性等多項面向多集群的運維能力，能夠以統一的工作流面向混合環境進行應用交付與管理。在整個過程中，OCM 是 KubeVela 實現 Kubernetes 集群注冊、納管、應用分發策略的主要技術。
?

在公共云上，KubeVela 的上述特性結合阿里云 ACK 多集群納管能力，則可以為用戶提供了一個強大的應用交付控制平面，能夠輕松實現：
?

• 混合環境一鍵建站。例如，一個典型的混合環境可以是一個公共云的 ACK 集群（生產集群）加上一個被 ACK 多集群納管的本地 Kubernetes 集群（測試集群）。在這兩個環境中，應用組件的提供方往往各不相同，比如數據庫組件在測試集群中可能是 MySQL，而在公共云上則是阿里云 RDS 產品。這樣的混合環境下，傳統的應用部署和運維都極其復雜的。而 KubeVela 則可以讓用戶非常容易的在一份部署計劃中詳細定義待部署制品、交付工作流、聲明不同環境的差異化配置。這不僅免去了繁瑣的人工配置流程，還能借助 Kubernetes 強大的自動化能力和確定性大幅降低發布和運維風險。

?

• 多集群微服務應用交付：云原生架構下的微服務應用，往往由多樣化的組件構成，常見的比如容器組件、Helm 組件、中間件組件、云服務組件等。KubeVela 為用戶提供面向微服務架構的多組件應用交付模型，借助 OCM 提供的分發策略在多集群、混合環境中進行統一的應用交付，大大降低運維和管理微服務應用的難度。

?

在未來，阿里云團隊會同 RedHat/OCM 社區、Oracle、Microsoft 等合作伙伴一起，進一步完善 KubeVela 面向混合環境的應用編排、交付與運維能力，讓云原生時代的微服務應用交付與管理真正做到“既快、又好”。
?

加入社區

?

目前 OCM 社區還處在快速開發的早期，非常歡迎有興趣的企業、組織、學校和個人參與。在這里，你可以和螞蟻集團、RedHat、和阿里云的技術專家們以及 Kubernetes 核心 Contributor 成為伙伴，一起學習、搭建和推動 OCM 的普及。

• GitHub 地址（https://github.com/open-cluster-management-io）

• 通過視頻了解 OCM（https://www.youtube.com/channel/UC7xxOh2jBM5Jfwt3fsBzOZw）

• 來社區周會認識大家（https://docs.google.com/document/d/1CPXPOEybBwFbJx9F03QytSzsFQImQxeEtm8UjhqYPNg）

• 在 Kubernetes Slack 頻道 # open-cluster-mgmt 自由交流（https://slack.k8s.io/）

• 加入郵件組瀏覽關鍵討論 （https://groups.google.com/g/open-cluster-management）

• 訪問社區官網獲取更多信息（https://open-cluster-management.io/）

今年 9 月 10 日 INCLUSION·外灘大會將如期舉行，作為全球金融科技盛會，它將繼續保持科技·讓技術更普惠的初心。11 日下午的多集群、混合云架構開源專場，OCM 社區的主要開發人員會為大家帶來圍繞 OCM 構建的多集群、混合云最佳實踐，歡迎你屆時線下參加，面對面交流。

感謝你對 OCM 的關注與參與，歡迎分享給有同樣需求的更多朋友，讓我們共同為多集群、混合云的使用體驗更進一步而添磚加瓦！

原文鏈接：https://developer.aliyun.com/article/785567?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的还在为多集群管理烦恼吗？RedHat 和蚂蚁、阿里云给开源社区带来了OCM的全部內容，希望文章能夠幫你解決所遇到的問題。

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