文｜金敏（螞蟻集團技術專家)\邱見（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/
