文｜金敏（螞蟻集團技術專家)\邱見（Red Hat)
校對｜ 馮泳（螞蟻集團資深技術專家)
本文 3311 字 閱讀 6 分鐘
從最初 Kubernetes 技術問世，業界一遍一遍的質疑它能否能經得住生產級的考驗，到今天許多大型企業已經採用 Kubernetes 技術“雲化”之前大規模的基礎設施，在企業內部創建了數十個甚至數百個集羣。
Kubernetes 原生的管理能力目前仍然停留在單集羣級別。每一個集羣可以穩定地自治運行，但是卻缺乏橫貫多個集羣的統籌管理能力。基礎設施的建立者需要協調分散在各處的管理組件，形成一個統一的管理平臺。
通過它，運維管理人員能夠獲知多集羣水位的變化，節點健康狀態的震盪等信息；業務應用負責人能夠決策如何調配應用服務在各個集羣中的部署分佈；應用的運維人員能夠獲知服務狀態，下發騰挪的策略。
與多集羣相關的創新正在不斷湧現。例如 ClusterAPI 和 Submariner 就是處理特定多集羣管理問題比較成功的項目。
而本文要討論的是那些試圖解決企業在面對多集羣管理時遇到的所有問題的技術探索。
在過去五年中，中國的技術公司螞蟻集團在多集羣管理的思考、使用和實施等方面學習到了很多寶貴的經驗。
螞蟻集團管理着遍佈全球的數十個 Kubernetes 集羣，每個集羣平均擁有數千個節點（服務器）。他們將應用程序及其所需組件（包括中間件，數據庫，負載均衡等等）在架構層面組織成邏輯數據中心（LDC）的彈性邏輯單元中，並將它們規劃部署到物理基礎設施上。這種架構設計幫助他們實現基礎設施運維的兩個關鍵目標：高可用性和事務性。
- 首先，部署在某個 LDC 上的業務應用的可用性在所屬 LDC 內能夠得到保障。
- 其次，部署在 LDC 內的應用組件可以被驗證，並在故障發生時，可以被回滾。
螞蟻集團 PaaS 團隊的資深技術專家馮泳表示：
“螞蟻集團擁有數十個 Kubernetes 集羣、數十萬個節點和數千個關鍵應用的基礎設施。在這樣的雲原生基礎設施中，每天都會有數以萬計的 Pod 被創建和刪除。構建一個高度可用、可擴展且安全的平臺來管理這些集羣和應用程序是一項挑戰。”
PART. 1 始於 KubeFed
在 Kubernetes 項目生態中，多集羣功能主要由與之同名的 SIG-Multicluster 團隊處理。這個團隊在 2017 年開發了一個集羣聯邦技術叫做 KubeFed。
聯邦最初被認爲是 Kubernetes 的一個內置特性，但很快就遇到了實現以及用戶訴求分裂的問題，Federation v1 可以將服務分發到多個 Kubernetes 集羣，但不能處理其他類型的對象，也不能真正的以任何方式“管理”集羣。一些有相當專業需求的用戶——尤其是幾個學術實驗室——仍在使用它，但該項目已被 Kubernetes 歸檔，從未成爲核心功能。
然後，Federation v1 很快被一種名爲“ KubeFed v2 ”的重構設計所取代，世界各地的運營人員都在使用該設計。它允許單個 Kubernetes 集羣將多種對象部署到多個其他 Kubernetes 集羣。KubeFed v2 還允許“控制平面”主集羣管理其他集羣，包括它們的大量資源和策略。這是螞蟻集團多集羣管理平臺的第一代方案。
螞蟻集團使用多集羣聯邦的首要任務之一是資源彈性，不止包括節點級別彈性也包括站點級別彈性。通過在需要時添加節點和整個集羣起到提高效率和擴展系統的能力。例如年度性的資源彈性，每年 11 月 11 日是中國一年一度的光棍節，螞蟻集團通常需要快速部署大量額外容量來支持高峯在線購物工作負載。然而，可惜的是正如他們發現的那樣 KubeFed 添加新集羣的速度很慢，而且在管理大量集羣方面效率低下。
在 KubeFed v2 集羣中，一箇中樞 Kubernetes 集羣會充當所有其他集羣的單一“控制平面”。螞蟻集團發現，在管理託管集羣和託管集羣中應用程序的時候，中樞集羣的資源使用率都非常高。
在管理僅佔螞蟻集團總量 3% 的應用程序工作負載的測試中，他們發現由中等規模的雲實例構成的中樞集羣就已經飽和了，並且響應時間很差。因此，他們從未在 KubeFed 上運行全部工作負載。
第二個限制與 Kubernetes 的擴展功能有關，稱爲自定義資源定義或 CRD。類似螞蟻集團這樣的“高級用戶”往往會開發衆多的自定義資源來擴充管理能力。爲了要在多集羣間分發 CRD，KubeFed 要求爲每個 CRD 都創建一個“聯合 CRD”。這不僅使集羣中的對象數量增加了一倍，也爲在集羣間維護 CRD 版本和 API 版本一致性方面帶來了嚴重的問題，並且會造成應用程序因爲不能兼容不同的 DRD 或者 API 版本而無法順利升級。
CRD 的這種數量激增也導致了嚴重的故障排除問題，同時 CRD 的使用定義不規範/字段變更隨意等壞習慣會使 KubeFed 控制面的魯棒性雪上加霜。在本地集羣有自定義資源的地方，聯邦控制平面上也有一個代表該本地集羣資源的圖形聚合視圖。但是如果本地集羣出現問題，很難從聯邦控制平面開始知道問題出在哪裏。本地集羣上的操作日誌和資源事件在聯邦級別也是不可見的。
PART. 2 轉向 Open Cluster Management
Open Cluster Management 項目（OCM）是由 IBM 最初研發，並由紅帽在去年開源。OCM 在螞蟻集團和其他合作伙伴的經驗基礎上，改進了多集羣管理的方法。它將管理開銷從中樞集羣下放到每個被管理集羣上的代理（Agent）上，讓它在整個基礎設施中分佈式自治並維護穩定。這使得 OCM 理論上能管理的集羣數量至少比 KubeFed 多一個數量級。到目前爲止，用戶已經測試了同時管理多達 1000 個集羣。
OCM 還能夠利用 Kubernetes 本身的發展來提高自身的能力。例如，那些以 CRD 封裝的能力擴展可以使用 OCM 的 WorkAPI（一個正在向 SIG-Multicluster 提議的子項目）在集羣之間分發 Kubernetes 對象。WorkAPI 將本地 Kubernetes 資源的子集嵌入其中，作爲要部署的對象的定義，並將其留給代理進行部署。此模型更加靈活，並且最大限度地減少了對任何中央控制平面的部署需求。WorkAPI 可以一起定義一個資源的多個版本，支持應用程序的升級路徑。同時 WorkAPI 兼顧了中樞集羣和被管理集羣網絡鏈接故障時的狀態保持問題，並可以在重連的情況下保障資源狀態的最終一致性。
最重要的是，OCM 在集羣部署中實現了更多的自動化。在 KubeFed 中，集羣的納管是一個“雙向握手”的過程，以中樞集羣和被管理集羣之間“零信任”作爲基礎，在此過程中涉及許多手動步驟來保障安全性。新平臺能夠簡化這一過程。例如，因爲它在 “PULL” 的基礎上運行，不再需要多階段手動證書註冊，也不需要任何明文的 KubeConfig 證書的流通，就可以做到讓被管理集羣獲取中樞集羣的管理命令。
儘管註冊的流程注重雙向的“信任性”，但是在 OCM 中添加新集羣只需要很少的操作；工作人員可以簡單地在目標 Kubernetes 集羣上部署 “Klusterlet” 代理實現自動納管。這不僅對管理員來說更加容易，而且也意味着螞蟻集團爲雙十一準備更多新集羣的部署更加快速。
PART. 3 Kubernetes 多集羣的下一步是什麼？
在短短四年內，Kubernetes 社區的多集羣管理能力迅速發展，從 Federation v1 到 KubeFed v2 再到 Open Cluster Management。
通過在內部興趣組 SIG-Multicluster 和外部項目（OCM、Submariner 等）工作的那些才華橫溢的工程師的技術能力，多集羣支持的管理規模和管理功能都比以前提高了很多。
未來是否還會有一個新的平臺來進一步發展多集羣功能，或者 OCM 就是最終的實現方式？
馮泳是這麼認爲的：
“展望未來，在紅帽、螞蟻集團、阿里雲等參與者的共同努力下，Open Cluster Management 項目將成爲構建基於 Kubernetes 的多集羣解決方案的標準和背板”。
無論如何，有一件事很清楚：
您現在可以在 Kubernetes 上運行整個星球
要了解有關雲原生主題的更多信息，請在KubeCon+CloudNativeCon North America ，2021 – 2021 年 10 月 11-15 日加入雲原生計算基金會和雲原生社區。
🔗「原文鏈接」： https://containerjournal.com/features/the-next-kubernetes-frontier-multicluster-management/
