還在爲多集羣管理煩惱嗎？OCM來啦！

時間 2021-07-22

標籤 git github 數據庫 segmentfault api 安全網絡架構框架運維欄目負載均衡简体版

原文原文鏈接

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

前言

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

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

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

多集羣管理髮展歷史

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

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

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 的關注與參與，歡迎分享給有一樣需求的更多朋友，讓咱們共同爲多集羣、混合雲的使用體驗更進一步而添磚加瓦！