作者 | 左修
OpenClusterManagement（OCM）項目在 11 月 9 日的 CNCF 委員會會議中正式準許為 CNCF 的沙箱項目，并且也吸引了微軟 AKS 研發同學的加盟。同時 OCM 社群也即将在 KubeCon 2021 中國的主題演講裡展開介紹 KubeVela 社群和 OCM 社群正在共建的內建特性。
分布式雲正在成為雲計算行業的趨勢。從使用者的角度認識所謂分布式雲就是可以根據基礎實施拓撲形式和功能需求選擇合适的社群項目方案和叢集管理模式擷取流暢的使用者體驗，同時從雲廠商的角度就需要在技術服務上主動适配開放的技術标準并且在一緻性通過的前提下相容其他廠商的技術方案。是以評價分布式雲混合雲技術方案的開放性的重要名額之一就是項目的廠商中立性和開放性，然而實踐上中立性的目标是比較理想化的因為每個廠商都需要跟随本身的商業利益，是以回到混合雲技術方案上我們需要重點建設的名額是在開放性，反過來綁定終端使用者恰好是與分布式雲的初衷背道而馳的。
下面要展開介紹 OCM 項目是個開源開放的 Kubernetes 多叢集管理平台項目，目前由阿裡雲，紅帽以及微軟等公司跨廠商聯合推動。在宏觀架構設計上 OpenClusterManagement 主要采用了自治管理架構，同時功能元件高度子產品化可剪裁。這樣而來終端使用者可以根據實際的場景靈活安裝拆卸自己所需要的部分子產品，舉個例子如果使用者需要采用某個廠商的功能那麼隻需要在 OCM 上通過訂閱插件快速安裝廠商的服務，同時如果使用者不再需要某子產品了就可以幹淨地拆卸掉。換言之，一個最小的 OCM 安裝模式下，OCM 隻會提供精煉的叢集中繼資料以證書管理等基礎功能。
01 新的子項目 Cluster-Gateway
1、Endpoint-less 的多叢集 API 網關架構 / Cluster-Gateway
Cluster-Gateway 由阿裡雲主要貢獻的 OCM 新晉子項目，也即将引用在阿裡雲在雲栖大會亮相的 ACK 靈活版項目中。
OCM 在自管理模式下不會再要求被托管叢集提供任何形式的 API 通路入口及證書，但是實踐上我們往往仍然迫切需要一個從中樞叢集動态正向通路各個叢集的工作鍊路，同時這個鍊路需要考慮分布式雲 VPC 網絡隔離的問題，甚至被托管叢集有的情況下不具備開放網絡出口的條件。
在 OCM 裡 Cluster-Proxy 這個神奇的特性可以幫助你在中樞叢集和被托管叢集之間沒有任何正向網絡連通性的情況下使得 API 請求能從中樞叢集正确抵達被托管叢集，甚至 Exec，Logs 等複雜請求也可以正常工作。這得益與 Kubernetes 社群在 Apiserver-Netwrok-Proxy（ANP）項目上積累的經驗：
https://github.com/kubernetes-sigs/apiserver-network-proxy通過上述 OCM 的插件開發架構（Addon-Framework），Cluster-Proxy 可以幫你托管維護滾動 ANP 的 Server 端和 Agent 端的 TLS 證書并同步兩者之間的配置。
在網絡連通性穩定工作之後，再借助于下面 Kubernetes 社群的 Aggregated Apiserver 開發架構 Apiserver-Runtime，我們聯合 KubeVela 社群為 OCM 開發了 Cluster-Gateway 項目以提供一個自定義資源及”/proxy”子資源，它就像 Kubernetes 原生的”pods/proxy”, ”services/proxy”一樣工作：
https://github.com/kubernetes-sigs/apiserver-runtime這樣一來 Cluster-Proxy 提供了四層的網絡鍊路，Cluster-Gateway 提供了七層的網絡多叢集路由，于是整體的 API Push 鍊路就可以完整工作了。詳細資訊可以參考下圖：
該特性本身借助于 OCM 的插件架構簡化了 ANP 的部署及證書滾動等繁冗的事情，這些細碎平凡的工作恰恰是建構多叢集平台最先需要解決的通用問題，也是多叢集平台能簡易靈活工作的基礎。一句話來說，我們可以把最枯燥的事情交給 OCM，然後再由你來定義 OCM 的功能上限。
>> 更多關于 OCM 最新插件 cluster-proxy 的文檔可以參考：
https://open-cluster-management.io/getting-started/integration/cluster-proxy/02
2、更多新特性
OpenClusterManagement 社群還有許多正在積極建設的特性子產品等待你去體驗發現，篇幅原因這裡不能詳細展開，可以參考的包括：
- ManifestWork 資源下發的“訂閱式”回流特性
- 多叢集政策配置下發的 Kustomize 內建
- 多叢集 Workload 彈性能力
- 參與社群了解更多
02 OCM 能力回顧
- 首頁倉庫：
- 主題站點：
- 中文主題站點：
OpenClusterManagement 項目由 2020 年末開始走向公衆，至今半年多來經過在螞蟻金服大規模運維實踐的打磨下逐漸走向穩定成熟。後續在吸引了阿裡雲，微軟等廠商的登陸合作之後正式号召社群使用者的使用和合作，并于最近正式被 CNCF 采納為沙箱開源項目。以下為 OpenClusterManagement 項目的主要架構組成：
01
1、叢集生命周期核心控制器 / Registration
https://github.com/open-cluster-management-io/registration這是 OCM 裡的最核心元件，用于控制管理叢集的注冊流程和中繼資料及其生命周期。顯而易見叢集的中繼資料本身是更上層能力的必需基礎，其提供的叢集中繼資料模型也是之上工作的各個子產品的公共“協定”。值得一提的是 OCM 的叢集中繼資料是極其簡練的，甚至不包含任何被托管叢集的證書密鑰，這是得益于 Pull 模式天然排除證書管理的安全性和複雜性。此外 OCM 裡的叢集注冊托管流程是基于“雙向握手”認證的，并且在注冊完成後在中樞 Hub 叢集内會自動生成管理一個與被托管叢集同名的命名空間作為工作空間。
2、持續穩定的資源下發能力 / Work
https://github.com/open-cluster-management-io/work在各個叢集對應的命名空間中我們可以通過 ManifestWork API 将期望的資源打包下發給被托管叢集，值得注意的是在被托管叢集中會持久化一份備份的資源 AppliedManifestWork API 以保證在出現網絡分區或者中樞離線的情況下被托管叢集依然可以持續的維持期望的狀态。通過 Kubernetes 社群多叢集工作小組的決議 Work API 即将會被推為社群标準。
03
3、動态叢集拓撲路由能力 / Placement
https://github.com/open-cluster-management-io/placement完全解耦子產品化的多叢集路由政策子產品。在使用時通過對叢集分組或者進一步篩選指定叢集的标簽之後，Placement 控制器就會動态計算出路由政策的計算結果即一份被比對的叢集清單。這份清單會根據叢集的可用性以及其他衛星屬性動态變化。使用者可以基于 Placement 控制器自由開發屬于自己的多叢集進階特性例如多叢集 Workload 下發等等。此外在 OCM 裡叢集的标簽也分為普通的靜态标簽/Label，以及由被托管叢集采集上報的動态标簽/ClusterClaim，這些都可以作為多叢集路由政策的資訊輸入。
04
4、開放子產品插件管理架構 / Addon-Framework
https://github.com/open-cluster-management-io/addon-frameworkOCM 的插件架構提供了一系列好用的工具來輔助你開發屬于自己的多叢集功能特性，這樣一以來你就不再需要重複處理繁雜的元件部署，中樞與被托管控制器的關聯以及證書滾動等等勞動了，我們可以更專注在建構自己需要的定制功能特性本身。
05
5、更多可選子產品功能
除了以上穩定工作的核心元件，OCM 還提供了多叢集配置政策的下發，基于 Helm 的多叢集的生命周期管理以及和 KubeVela 的內建等等進階子產品等你體驗。
03 如何參與社群
随時歡迎參與我們的社群雙周會，在這裡關注會議及日程：
https://github.com/open-cluster-management-io/community/projects我們的會議時間會動态調整因為橫跨涉及中國歐洲美國東西部的協調，或者可以直接在我們的 slack 頻道尋找夥伴：
https://kubernetes.slack.com/archives/C01GE7YSUUF點選下方連結，快速浏覽我們最新的 OpenClusterManagement 中文站點。