前言

Kubernetes以其超前的設計理念和優秀的技術架構，在容器編排領域拔得頭籌。越來越多的公司開始在生產環境部署實踐 Kubernetes，在阿里巴巴和螞蟻金服 Kubernetes 已被大規模用於生產環境。

Kubernetes的出現使得廣大開發同學也能運維複雜的分散式系統，它大幅降低了容器化應用部署的門檻，但運維和管理一個生產級的高可用 Kubernetes 叢集仍十分困難。

本文將分享螞蟻金服是如何有效可靠地管理大規模 Kubernetes 叢集的，並會詳細介紹叢集管理系統核心元件的設計。

系統概覽

Kubernetes叢集管理系統需要具備便捷的叢集生命週期管理能力，完成叢集的建立、升級和工作節點的管理。在大規模場景下，叢集變更的可控性直接關係到叢集的穩定性，因此管理系統可監控、可灰度、可回滾的能力是系統設計的重點之一。除此之外，超大規模叢集中，節點數量已經達到 10K 量級，節點硬體故障、元件異常等問題會常態出現。面向大規模叢集的管理系統在設計之初就需要充分考慮這些異常場景，並能夠從這些異常場景中自恢復。

設計模式

基於這些背景，我們設計了一個面向終態的叢集管理系統。系統定時檢測叢集當前狀態，判斷是否與目標狀態一致，出現不一致時，Operators 會發起一系列操作，驅動叢集達到目標狀態。這一設計參考控制理論中常見的負反饋閉環控制系統，系統實現閉環，可以有效抵禦系統外部的干擾，在我們的場景下，干擾對應於節點軟硬體故障。

架構設計

如上圖，元叢集是一個高可用的 Kubernetes 叢集，用於管理 N 個業務叢集的 Master 節點。業務叢集是一個服務生產業務的 Kubernetes 叢集。SigmaBoss 是叢集管理入口，為使用者提供便捷的互動介面和可控的變更流程。

元叢集中部署的 Cluster-Operator 提供了業務叢集叢集建立、刪除和升級能力，Cluster-Operator面向終態設計，當業務叢集 Master 節點或元件異常時，會自動隔離並進行修復，以保證業務叢集 Master 節點達到穩定的終態。這種採用 Kubernetes 管理 Kubernetes 的方案，我們稱作 Kube on Kube 方案，簡稱 KOK 方案。

業務叢集中部署有 Machine-Operator 和節點故障自愈元件用於管理業務叢集的工作節點，提供節點新增、刪除、升級和故障處理能力。在 Machine-Operator 提供的單節點終態保持的能力上，SigmaBoss 上構建了叢集維度灰度變更和回滾能力。

核心元件

叢集終態保持器

基於 K8S CRD，在元叢集中定義了 Cluster CRD 來描述業務叢集終態，每個業務叢集對應一個 Cluster 資源，建立、刪除、更新 Cluster 資源對應於實現業務叢集建立、刪除和升級。Cluster-Operator watch Cluster 資源，驅動業務叢集Master 元件達到 Cluster 資源描述的終態。

業務叢集 Master 元件版本集中維護在 ClusterPackageVersion CRD 中，ClusterPackageVersion 資源記錄了 Master 元件（如：api-server、controller-manager、scheduler、operators 等）的映象、預設啟動引數等資訊。Cluster 資源唯一關聯一個 ClusterPackageVersion，修改 Cluster CRD 中記錄的 ClusterPackageVersion 版本即可完成業務叢集 Master 元件釋出和回滾。

節點終態保持器

Kubernetes叢集工作節點的管理任務主要有：

• 節點系統配置、核心補丁管理
• docker / kubelet 等元件安裝、升級、解除安裝
• 節點終態和可排程狀態管理（如關鍵 DaemonSet 部署完成後才允許開啟排程）
• 節點故障自愈

為實現上述管理任務，在業務叢集中定義了 Machine CRD 來描述工作節點終態，每一個工作節點對應一個 Machine 資源，透過修改 Machine 資源來管理工作節點。

MachineCRD 定義如下圖所示，spec 中描述了節點需要安裝的元件名和版本，status 中記錄有當前這個工作節點各元件安裝執行狀態。除此之外，Machine CRD 還提供了外掛式終態管理能力，用於與其它節點管理Operators 協作，這部分會在後文詳細介紹。

工作節點上的元件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion維護了每個元件的 rpm 版本、配置和安裝方法等資訊。一個Machine 資源會關聯 N 個不同的MachinePackageVersion，用來實現安裝多個元件。

在 Machine、MachinePackageVersion CRD 基礎上，設計實現了節點終態控制器 Machine-Operator。Machine-Operator watchMachine 資源，解析 MachinePackageVersion，在節點上執行運維操作來驅動節點達到終態，並持續守護終態。

節點終態管理

隨著業務訴求的變化，節點管理已不再侷限於安裝 docker / kubelet 等元件，我們需要實現如等待日誌採集DaemonSet 部署完成才可以開啟排程的需求，而且這類需求變得越來越多。如果將終態統一交由Machine-Operator 管理，勢必會增加 Machine-Operator 與其它元件的耦合性，而且系統的擴充套件性會受到影響。因此，我們設計了一套節點終態管理的機制，來協調Machine-Operator 和其它節點運維 Operators。設計如下圖所示：

全量 ReadinessGates：記錄節點可排程需要檢查的 Condition 列表

ConditionConfigMap：各節點運維 Operators 終態狀態上報 ConfigMap

協作關係：

1. 外部節點運維 Operators 檢測並上報與自己相關的子終態資料至對應的 ConditionConfigMap；

2. Machine-Operator 根據標籤獲取節點相關的所有子終態Condition ConfigMap，並同步至 Machine status 的 conditions中

3. Machine-Operator 根據全量 ReadinessGates 中記錄的 Condition 列表，檢查節點是否達到終態，未達到終態的節點不開啟排程

節點故障自愈

我們都知道物理機硬體存在一定的故障機率，隨著叢集節點規模的增加，叢集中會常態出現故障節點，如果不及時修復上線，這部分物理機的資源將會被閒置。

為解決這一問題，我們設計了一套故障發現、隔離、修復的閉環自愈系統。

如下圖所示，故障發現方面，採取 Agent 上報和監控系統主動探測相結合的方式，保證了故障發現的實時性和可靠性（Agent上報實時性比較好，監控系統主動探測可以覆蓋 Agent 異常未上報場景）。故障資訊統一儲存於事件中心，關注叢集故障的元件或系統都可以訂閱事件中心事件拿到這些故障資訊。

節點故障自愈系統會根據故障型別建立不同的維修流程，例如：硬體維繫流程、系統重灌流程等。維修流程中優先會隔離故障節點（暫停節點排程），然後將節點上 Pod 打上待遷移標籤來通知 PAAS 或 MigrateController 進行 Pod 遷移，完成這些前置操作後，會嘗試恢復節點（硬體維修、重灌作業系統等），修復成功的節點會重新開啟排程，長期未自動修復的節點由人工介入排查處理。

風險防範

在 Machine-Operator 提供的原子能力基礎上，系統中設計實現了叢集維度的灰度變更和回滾能力。此外，為了進一步降低變更風險，Operators 在發起真實變更時都會進行風險評估，架構示意圖如下。

高風險變更操作（如：刪除節點、重灌系統）接入統一限流中心，限流中心維護了不同型別操作的限流策略，若觸發限流，則熔斷變更。

為了評估變更過程是否正常，我們會在變更前後，對各元件進行健康檢查，元件的健康檢查雖然能夠發現大部分異常，但不能覆蓋所有異常場景。所以，風險評估過程中，系統會從事件中心、監控系統中獲取叢集業務指標（如：Pod建立成功率），如果出現異常指標，則自動熔斷變更。

結束語

本文主要和大家分享了現階段螞蟻金服 Kubernetes 叢集管理系統的核心設計，核心元件大量使用 Operator 面向終態設計模式。

未來我們會嘗試將叢集規模變更切換為 Operator 面向終態設計模式，探索如何在面向終態的模式下，做到變更的可監控、可灰度和可回滾，實現變更的無人值守。

如果你對螞蟻金服 Kubernetes 叢集感興趣，可以閱讀這篇文章： 從零到破萬節點！支撐618大促背後的螞蟻金服Kubernetes叢集