還在為多集群管理煩惱嗎？OCM來啦！

作者簡介：馮泳（花名鹿驚），資深技術專家，擁有西北工業大學計算機科學博士學位，在高性能計算，大數據和雲計算領域擁有十多年的設計開發經驗，專注於調度，資源和應用管理領域。也深度參與相關開源項目的開發和商業化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 領導過相關的開發團隊。

前言

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

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

項目官網：https://open-cluster-management.io/

多集群管理髮展歷史

讓我們把時間拉回到幾年前，當業界關注/爭論的焦點還在 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 的 APIPriorityAndFairness 特性，可以根據場景主動定製流量軟隔離策略，而不是被動的通過類似 ACL 進行流量的懲罰限流。如果在最開始進行集群規劃的時候劃分為多個集群，那麼隔離性的問題自然就解決了，比如我們可以根據業務給大數據分配獨佔集群，或者特定業務應用分配獨佔請集群等等。

OCM 的主要功能和架構

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

1.理解集群的定義；

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

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

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

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

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

●通過 ManagedCluster API 定義被管理的集群，同時 OCM 會安裝名為 Klusterlet 的 agent 在每個集群裡來完成集群註冊，生命週期管理等功能。

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

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

●通過 ManagedClusterSet API 對集群進行分組，並提供用戶訪問集群的界限。

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

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

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

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

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

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

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

同時為了和 kubernetes 生態系統緊密結合，OCM 實現了 kubernetes sig-multicluster 的多個設計方案，包括 KEP-2149 Cluster ID：
https://github.com/Kubernetes/enhancements/tree/master/keps/sig-multicluster/2149-clusterid

和 KEP-1645 Multi-Cluster Services API 中關於 clusterset 的概念：https://github.com/Kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api

也在和其他開發者在社區共同推動 Work APIhttps://github.com/Kubernetes-sigs/work-api 的開發。

OCM 的主要優勢

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

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

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

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

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

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

●通過 ManagedClusterAction 我們可以向被納管的集群逐個下發原子指令，這也是作為一箇中樞管控系統自動化編排各個集群最直觀的做法。一個 ManagedClusterAction 可以有自己的指令類型，指令內容以及指令執行的具體狀態。

●通過 ManagedClusterView 我們可以主動將被納管集群中的資源“投射”到多集群聯邦中樞系統中，通過讀取這些資源在中樞中的“投影”，我們可以在聯邦系統中進行更動態準確的決策。

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
https://github.com/oam-dev/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 的關注與參與，歡迎分享給有同樣需求的更多朋友，讓我們共同為多集群、混合雲的使用體驗更進一步而添磚加瓦！

本週推薦閱讀

更多文章請掃碼關注“金融級分佈式架構”公眾號

前言