作者 | 螞蟻金服技術專家 滄漠
關注『阿里巴巴云原生』公眾號，回復關鍵詞“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
協作關系：
- 外部節點運維 Operators 檢測并上報與自己相關的子終態資料至對應的 Condition ConfigMap；
- Machine-Operator 根據標簽獲取節點相關的所有子終態 Condition ConfigMap，并同步至 Machine status 的 conditions中
- 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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/178327.html
標籤：其他