架構設計
如上圖，元集群是一個高可用的 Kubernetes 集群，用于管理 N 個業(yè)務集群的 Master 節(jié)點。業(yè)務集群是一個服務生產(chǎn)業(yè)務的 Kubernetes 集群。SigmaBoss 是集群管理入口，為用戶提供便捷的交互界面和可控的變更流程。
元集群中部署的 Cluster-Operator 提供了業(yè)務集群集群創(chuàng)建、刪除和升級能力，Cluster-Operator 面向終態(tài)設計，當業(yè)務集群 Master 節(jié)點或組件異常時，會自動隔離并進行修復，以保證業(yè)務集群 Master 節(jié)點達到穩(wěn)定的終態(tài)。這種采用 Kubernetes 管理 Kubernetes 的方案，我們稱作 Kube on Kube 方案，簡稱 KOK 方案。
業(yè)務集群中部署有 Machine-Operator 和節(jié)點故障自愈組件用于管理業(yè)務集群的工作節(jié)點，提供節(jié)點新增、刪除、升級和故障處理能力。在 Machine-Operator 提供的單節(jié)點終態(tài)保持的能力上，SigmaBoss 上構建了集群維度灰度變更和回滾能力。
核心組件
集群終態(tài)保持器
基于 K8S CRD，在元集群中定義了 Cluster CRD 來描述業(yè)務集群終態(tài)，每個業(yè)務集群對應一個 Cluster 資源，創(chuàng)建、刪除、更新 Cluster 資源對應于實現(xiàn)業(yè)務集群創(chuàng)建、刪除和升級。Cluster-Operator watch Cluster 資源，驅動業(yè)務集群 Master 組件達到 Cluster 資源描述的終態(tài)。
業(yè)務集群 Master 組件版本集中維護在 ClusterPackageVersion CRD 中，ClusterPackageVersion 資源記錄了 Master 組件（如：api-server、controller-manager、scheduler、operators 等）的鏡像、默認啟動參數(shù)等信息。Cluster 資源唯一關聯(lián)一個 ClusterPackageVersion，修改 Cluster CRD 中記錄的 ClusterPackageVersion 版本即可完成業(yè)務集群 Master 組件發(fā)布和回滾。
節(jié)點終態(tài)保持器
Kubernetes 集群工作節(jié)點的管理任務主要有：
?節(jié)點系統(tǒng)配置、內(nèi)核補丁管理
?docker / kubelet 等組件安裝、升級、卸載
?節(jié)點終態(tài)和可調(diào)度狀態(tài)管理（如關鍵 DaemonSet 部署完成后才允許開啟調(diào)度）
?節(jié)點故障自愈
為實現(xiàn)上述管理任務，在業(yè)務集群中定義了 Machine CRD 來描述工作節(jié)點終態(tài)，每一個工作節(jié)點對應一個 Machine 資源，通過修改 Machine 資源來管理工作節(jié)點。
Machine CRD 定義如下圖所示，spec 中描述了節(jié)點需要安裝的組件名和版本，status 中記錄有當前這個工作節(jié)點各組件安裝運行狀態(tài)。除此之外，Machine CRD 還提供了插件式終態(tài)管理能力，用于與其它節(jié)點管理 Operators 協(xié)作，這部分會在后文詳細介紹。
工作節(jié)點上的組件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 維護了每個組件的 rpm 版本、配置和安裝方法等信息。一個 Machine 資源會關聯(lián) N 個不同的 MachinePackageVersion，用來實現(xiàn)安裝多個組件。
在 Machine、MachinePackageVersion CRD 基礎上，設計實現(xiàn)了節(jié)點終態(tài)控制器 Machine-Operator。Machine-Operator watch Machine 資源，解析 MachinePackageVersion，在節(jié)點上執(zhí)行運維操作來驅動節(jié)點達到終態(tài)，并持續(xù)守護終態(tài)。
節(jié)點終態(tài)管理
隨著業(yè)務訴求的變化，節(jié)點管理已不再局限于安裝 docker / kubelet 等組件，我們需要實現(xiàn)如等待日志采集 DaemonSet 部署完成才可以開啟調(diào)度的需求，而且這類需求變得越來越多。如果將終態(tài)統(tǒng)一交由 Machine-Operator 管理，勢必會增加 Machine-Operator 與其它組件的耦合性，而且系統(tǒng)的擴展性會受到影響。因此，我們設計了一套節(jié)點終態(tài)管理的機制，來協(xié)調(diào) Machine-Operator 和其它節(jié)點運維 Operators。設計如下圖所示：
全量 ReadinessGates：記錄節(jié)點可調(diào)度需要檢查的 Condition 列表
Condition ConfigMap：各節(jié)點運維 Operators 終態(tài)狀態(tài)上報 ConfigMap
協(xié)作關系：
1.外部節(jié)點運維 Operators 檢測并上報與自己相關的子終態(tài)數(shù)據(jù)至對應的 Condition ConfigMap；
2.Machine-Operator 根據(jù)標簽獲取節(jié)點相關的所有子終態(tài) Condition ConfigMap，并同步至 Machine status 的 conditions中
3.Machine-Operator 根據(jù)全量 ReadinessGates 中記錄的 Condition 列表，檢查節(jié)點是否達到終態(tài)，未達到終態(tài)的節(jié)點不開啟調(diào)度
節(jié)點故障自愈
我們都知道物理機硬件存在一定的故障概率，隨著集群節(jié)點規(guī)模的增加，集群中會常態(tài)出現(xiàn)故障節(jié)點，如果不及時修復上線，這部分物理機的資源將會被閑置。
為解決這一問題，我們設計了一套故障發(fā)現(xiàn)、隔離、修復的閉環(huán)自愈系統(tǒng)。
如下圖所示，故障發(fā)現(xiàn)方面，采取 Agent 上報和監(jiān)控系統(tǒng)主動探測相結合的方式，保證了故障發(fā)現(xiàn)的實時性和可靠性（Agent 上報實時性比較好，監(jiān)控系統(tǒng)主動探測可以覆蓋 Agent 異常未上報場景）。故障信息統(tǒng)一存儲于事件中心，關注集群故障的組件或系統(tǒng)都可以訂閱事件中心事件拿到這些故障信息。
節(jié)點故障自愈系統(tǒng)會根據(jù)故障類型創(chuàng)建不同的維修流程，例如：硬件維系流程、系統(tǒng)重裝流程等。維修流程中優(yōu)先會隔離故障節(jié)點（暫停節(jié)點調(diào)度），然后將節(jié)點上 Pod 打上待遷移標簽來通知 PAAS 或 MigrateController 進行 Pod 遷移，完成這些前置操作后，會嘗試恢復節(jié)點（硬件維修、重裝操作系統(tǒng)等），修復成功的節(jié)點會重新開啟調(diào)度，長期未自動修復的節(jié)點由人工介入排查處理。
風險防范
在 Machine-Operator 提供的原子能力基礎上，系統(tǒng)中設計實現(xiàn)了集群維度的灰度變更和回滾能力。此外，為了進一步降低變更風險，Operators 在發(fā)起真實變更時都會進行風險評估，架構示意圖如下。
高風險變更操作（如：刪除節(jié)點、重裝系統(tǒng)）接入統(tǒng)一限流中心，限流中心維護了不同類型操作的限流策略，若觸發(fā)限流，則熔斷變更。
為了評估變更過程是否正常，我們會在變更前后，對各組件進行健康檢查，組件的健康檢查雖然能夠發(fā)現(xiàn)大部分異常，但不能覆蓋所有異常場景。所以，風險評估過程中，系統(tǒng)會從事件中心、監(jiān)控系統(tǒng)中獲取集群業(yè)務指標（如：Pod創(chuàng)建成功率），如果出現(xiàn)異常指標，則自動熔斷變更。
結束語
本文主要和大家分享了現(xiàn)階段螞蟻金服 Kubernetes 集群管理系統(tǒng)的核心設計，核心組件大量使用 Operator 面向終態(tài)設計模式。
未來我們會嘗試將集群規(guī)模變更切換為 Operator 面向終態(tài)設計模式，探索如何在面向終態(tài)的模式下，做到變更的可監(jiān)控、可灰度和可回滾，實現(xiàn)變更的無人值守。
如果你對螞蟻金服 Kubernetes 集群感興趣，可以閱讀這篇文章：從零到破萬節(jié)點！支撐618大促背后的螞蟻金服Kubernetes集群
