下一個 Kubernetes 前沿：多叢集管理

📄

文｜金敏（螞蟻集團技術專家)

邱見（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/