備戰雙 11！螞蟻金服萬級規模 K8s 集羣管理系統如何設計？

做者 | 螞蟻金服技術專家 滄漠

關注『阿里巴巴雲原生』公衆號，回覆關鍵詞「1024」，可獲取本文 PPT。

前言

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 資源來管理工做節點。

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

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

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

節點終態管理

隨着業務訴求的變化，節點管理已再也不侷限於安裝 docker / kubelet 等組件，咱們須要實現如等待日誌採集 DaemonSet 部署完成才能夠開啓調度的需求，並且這類需求變得愈來愈多。若是將終態統一交由 Machine-Operator 管理，勢必會增長 Machine-Operator 與其它組件的耦合性，並且系統的擴展性會受到影響。所以，咱們設計了一套節點終態管理的機制，來協調 Machine-Operator 和其它節點運維 Operators。設計以下圖所示：

• 全量 ReadinessGates：記錄節點可調度須要檢查的 Condition 列表
• Condition ConfigMap：各節點運維 Operators 終態狀態上報 ConfigMap

協做關係：

1. 外部節點運維 Operators 檢測並上報與本身相關的子終態數據至對應的 Condition ConfigMap；
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 面向終態設計模式。這套面向終態的集羣管理系統在今年備戰雙11過程當中，經受了性能和穩定性考驗。

一個完備的集羣管理系統除了保證集羣穩定性和運維效率外，還應該提高集羣總體資源利用率。接下來，咱們會從提高節點在線率、下降節點閒置率等方面出發，來提高螞蟻金服生產集羣的資源利用率（P.S.螞蟻金服-系統部-資源調度組正在招聘，加入咱們，一塊兒來解決世界級難題吧！）。

Q & A

Q1：目前公司絕大多數應用已部署在 Docker 中 ，如何向 K8s 轉型？是否有案例能夠借鑑？
A1：我在螞蟻工做了將近 5 年，螞蟻的業務由最先跑在 xen 虛擬機中，到如今跑在 Docker 裏由 K8s 調度，基本上每一年都在迭代。K8s 是一個很是開放的 「PaaS」 框架，若是已經部署在 Docker 中，符合「雲原生」應用特性，遷移 K8s 理論上會比較平滑。螞蟻因爲歷史包袱比較重，在實踐過程當中，爲了兼容業務需求，對 K8s 作了一些加強，保證業務能平滑遷移過來。

Q2：應用部署在 K8s 及 Docker 中會影響性能嗎？例如大數據處理相關的任務是否建議部署到 K8s 中？
A2：我理解 Docker 是容器，不是虛擬機，對性能的影響是有限的。螞蟻大數據、AI 等業務都已經在遷移 K8s 與在線應用混部。大數據類對時間不敏感業務，能夠很好地利用集羣空閒資源，混部後可大幅下降數據中心成本。

Q3：K8s 集羣和傳統的運維環境怎麼更好的結合？如今公司確定不會所有上 K8s。
A3：基礎設施不統一會致使資源沒有辦法統一進行調度，另外維護兩套相對獨立的運維繫統，代價是很是大的。螞蟻在遷移過程當中實現了一個「Adapter」，將傳統建立容器或發佈的指令轉換成 K8s 資源修改來作「橋接」。

Q4：Node 監控是怎麼作的，Node 掛掉會遷移 Pod 嗎？業務不容許自動遷移呢？
A4：Node 監控分爲硬件、系統級、組件級，硬件監控數據來自 IDC，系統級監控使用內部自研監控平臺，組件（kubelet/pouch 等）監控咱們擴展 NPD，提供 exporter 暴露接口給監控系統採集。Node 出現異常，會自動遷移 Pod。有些帶狀態的業務，業務方本身定製 operator 來實現 Pod 自動遷移。不具有自動遷移能力的 Pod, 超期後會自動銷燬。

Q5：整個 K8s 集羣將來是否會對開發透明，使用代碼面向集羣編程或編寫部署文件，再也不須要按容器去寫應用及部署，是否有這種規劃？
A5：K8s 提供了很是多構建 PaaS 平臺的擴展能力，但如今直接面向 K8s 去部署應用的確很是困難。我以爲採用某種 DSL 去部署應用是將來的趨勢，K8s 會成爲這些基礎設施的核心。

Q6：咱們目前採用 kube-to-kube 的方式管理集羣，kube-on-kube 相比 kube-to-kube 的優點在哪？在大規模場景下，K8s 集羣的節點伸縮過程當中，性能瓶頸在哪？是如何解決的？
A6：目前已經有很是多的 CI/CD 流程跑在 K8s 之上。採用 kube-on-kube 方案，咱們能夠像管理普通業務 App 那樣管理業務集羣的管控。節點上除運行 kubelet pouch 外，還會額外運行不少 daemonset pod，大規模新增節點時，節點組件會對 apiserver 發起大量 list/watch 操做，咱們的優化主要集中在 apiserver 性能提高，和配合 apiserver 下降節點全量 list/watch。

Q7：滄漠你好，由於咱們公司尚未上 K8s，全部我想請教如下幾個問題：K8s 對咱們有什麼好處？可以解決當前的什麼問題？優先在哪些業務場景、流程環節使用？現有基礎設施可否平滑切換到 Kubernetes？
A7：我以爲 K8s 最大的不一樣在於面向終態的設計理念，再也不是一個一個運維動做。這對於複雜的運維場景來講，很是有益。從螞蟻的升級實踐看，平滑是能夠作到的。

Q8：cluster operator 是 Pod 運行，用 Pod 啓動業務集羣 master，而後 machine operator 是物理機運行？
A8：operator 都運行在 Pod 裏面的，cluster operator 將業務集羣的 machine operator 拉起來。

Q9：你好！請問一下，爲應對像雙十一這樣的高併發場景，多少許級的元集羣的規模對應管理多少許級的業務集羣合適？就個人理解，cluster operator 應該是對資源的 list watch，面對大規模的併發場景，大家作了哪些方面的優化？
A9：一個集羣能夠管理萬級節點，因此元集羣理論上能夠管理 3K+ 業務集羣。

Q10：節點若是遇到系統內核、Docker、K8s 異常，如何從軟件層面最大化保證系統正常？
A10：具有健康檢查能力，主動退出，由 K8s 發現，並從新在其它節點拉起。

「 阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」