運維 K8s 集羣的管控面

做者 | 淮右、臨石

**導讀：**單 K8s 集羣爲用戶提供了 Namespace 級別的隔離能力，理論上支持不超過 5K Node、15W Pod。多 K8s 集羣則解決了單集羣的資源隔離、故障隔離難題，打破可支持節點數、Pod 數的限制，但與此同時也帶來了集羣管理複雜度的上升；尤爲在專有云場景中，K8s 工程師不可能像在公有云中同樣快速觸達客戶環境，運維成本被進一步放大。所以如何低成本、高效率、自動化低管理多套 K8s 集羣，成爲業內廣泛難題。

背景

多集羣主要應用在以下場景：

1.產品自己須要多集羣能力。產品的管控須要部署在 K8s 集羣內，同時，該產品還須要提供 K8s 集羣給用戶使用，從故障隔離、穩定性、安全多重角度考慮，容器服務的管控和業務應該分別部署在不一樣的集羣內； 2.用戶在使用 K8s 的時候，也但願具有生產多套集羣供不一樣業務使用，從而進行資源隔離、故障隔離； 3.同一用戶可能須要多種類型集羣的能力，以邊緣計算 IOT 爲例，它須要一個定製的邊緣 K8s 集羣，若是按照普通的獨立 K8s 集羣來建立，一方面會存在資源浪費，另外一方面獨立的集羣爲用戶增長了運維的成本。

咱們總結了運維 K8s 集羣的難點，能夠分爲兩部分：

難點 1：運維 K8s 集羣的管控面

• 如何支持用戶一鍵彈出新的 Kubernetes 集羣？
• 如何升級多個 K8s 集羣的版本，當社區重大 CVE 發現時，是否要一個個升級集羣？
• 如何自動修復多個 K8s 集羣運行時發生的故障？
• 如何對集羣的 etcd 進行維護，包括升級、備份、恢復、節點遷移？

難點 2：運維 Worker 節點

• 如何快速擴縮容 Worker 節點？同時須要確保每一個節點的 on-host 軟件（例如 docker、kubelet 等沒法被 K8s 託管的組件）版本、配置和其餘節點拉齊。
• 如何升級若干 Worker 節點上的 on-host 軟件？如何灰度發佈 Worker 節點上的軟件包？
• 如何自動修復若干 Worker 節點可能出現的 on-host 軟件故障？好比要是 docker/kubelet 發生 panic，咱們是否能自動化的處理？

K8s 做爲一個複雜的自動化運維繫統，支撐了上層業務的發佈、升級、生命週期管理，但 K8s 自己的運維在業內卻每每仍是由一個工做流（ansible、argo 等）來執行。這個過程的自動化程度不高，須要運維人員具有比較專業的 K8s 知識。而當須要運維多套 K8s 集羣后，運維成本在理想狀況下也會線性上升，在專有云場景下成本還會被再次放大。

阿里內部很早就遇到了運維大量 K8s 集羣的難題，咱們摒棄了傳統工做流的模式，探索另一條路徑：使用 K8s 管理 K8s，CNCF 的文章《Demystifying Kubernetes as a Service – How Alibaba Cloud Manages 10,000s of Kubernetes Clusters》介紹了阿里巴巴在大規模 K8s 集羣管理上的探索與經驗。

固然，專有云場景和阿里巴巴內部場景仍是有較大不一樣，阿里集團內使用 Kube-On-Kube 技術主要看重它的規模效應，可使用一個元 K8s 集羣來管理成百上千的業務 K8s 集羣，而專有云場景的規模效應小，專有云主要看重的是Kube-On-Kube 技術自動化運維 K8s 集羣和兼容多種 K8s 集羣的能力，在提升穩定性的同時豐富了用戶的使用場景。

K8s 聲明式運維哲學：用 K8s 管理 K8s

K8s 的聲明式 API 顛覆了傳統的過程式運維模式，聲明式 API 對應的是面向終態的運維模式：使用者將在 Spec 裏定義本身所指望的狀態，K8s 的 Controller 會進行一系列操做幫助使用者達到指望狀態，只要不知足要求，Controller 會一直嘗試。

對於 Deployment 等 K8s 原生資源，由 K8s 的 Controller 負責終態維護，而對於用戶自定義的資源，例如一個 Cluster，K8s 提供了強大易用的 CRD+Operator 機制，只須要簡單幾步就能夠實現自定義的面向終態運維：

1.定義本身的資源類型（CRD），實現本身的 Operator，Operator 中包含了自定義 Controller； 2.用戶只須要提交本身的 CR，表現形式爲一個 yaml 或者 json； 3.Operator 監聽到 CR 的變化，Controller 開始執行對應的運維邏輯； 4.在運行過程當中，當終態不知足要求時，Operator 也可以監聽到變化，並作出相應的恢復操做。

Operator 是用代碼運維應用最好的實踐之一。固然，這只是一個框架，它節省了使用者的一些重複性勞動，如事件監聽機制、RESTful API 監聽，但核心的運維邏輯，仍是須要 case by case 由使用者編寫。

雲原生的 KOK 架構

Kube-On-Kube 不是新概念，業內已有不少優秀的解決方案：

• 螞蟻
• 社區項目

可是以上方案對公有云基礎設施有較強依賴，專有云的特殊性讓咱們要考慮：

• 足夠輕量化用戶纔會買單，客戶一般很排斥獨佔的管理節點開銷；
• 不依賴公有云和阿里集團內部的差別性基礎設施；
• 採用雲原生架構。

在考慮到這 3 個因素後，咱們設計出更爲通用的 KOK 方案：

名詞解釋：

• Meta Cluster：元集羣，即 Kube-On-Kube 的下層 Kube；
• Production Cluster：業務集羣，即 Kube-On-Kube 的上層 Kube；
• etcd cluster：由運行在元集羣中的 etcd operator 建立和維護的 etcd 集羣，能夠每一個業務集羣獨佔一個 etcd，或者多個業務集羣共享；
• PC-master-pod：業務集羣管控 pod，其實是 apiserver/scheduler/controller-manager 這 3 種 pod，由運行在元集羣的 Cluster Operator 維護；
• PC-nodes：業務集羣的 Node 節點，由 Machine Operator 負責初始化並加入到業務集羣，由 Machine Operator 維護；

etcd Operator

etcd Operator 負責 etcd 集羣的建立、銷燬、升級、故障恢復等，還提供了 etcd 集羣的狀態監控，包括集羣健康狀態、member 健康狀態、存儲數據量等。

阿里雲-雲原生應用平臺-SRE 團隊對開源版 etcd Operator 進行了改進，加強了運維功能和穩定性，該 Operator 負責阿里內部大量 etcd 集羣的運維管理，運行穩定，久經考驗。

Cluster Operator

Cluster Operator 負責業務集羣 K8s 管控組件（Apiserver、Controller Manager、Scheduler）的建立、維護，以及相應的證書生成、kubeconfig 生成。

咱們和螞蟻集團-PaaS 引擎與專有云產品團隊共建了 Cluster Operator，具有自定義渲染、版本溯源、動態增長可支持版本等能力。

業務集羣的 K8s 管控組件部署在元集羣，從元集羣的視角看就是一堆普通的 Resource，包括 Deployment、Secret、Pod、PVC 等，所以，業務集羣不具有 Master 節點的概念：

• kube-apiserver：由 1 個 Deployment +1 個 Service 組成。kube-apiserver 自己無狀態，Deployment 能夠知足要求，同時，Apiserver 須要對接 etcd Operator 拉起的 etcd cluster；Service 用於對業務集羣其餘組件以及對外暴露 Apiserver 的服務，此處咱們考慮了，若是用戶環境具有 LoadBalancer Service 的能力，建議優先使用 LoadBalancer 暴露 Apiserver，若是沒有此能力，咱們也提供了 NodePort 的暴露形態；
• kube-controller-manager：1 個 Deployment，無狀態應用；
• kube-scheduler：1 個 Deployment 便可，無狀態應用；

可是，只部署以上 3 個組件還不能提供一個可用 K8s，咱們還須要知足如下場景：

1.一個可用的業務 K8s 除了 etcd、3 大件以外，還須要部署 coredns、kube-proxy 或者其餘任意組件； 2.部分組件須要和 etcd、3 大件同樣的部署在元集羣，例如 Machine Operator 是拉起節點的組件，它必須在業務集羣有節點以前就能運做，因此它不能部署在業務集羣； 3.組件版本的升級。

所以，爲了應對擴展性要求，咱們設計了 addons 熱插拔能力，只需一條命令便可導入全部 Addon 組件；同時 addons 支持動態渲染能力，可自定義 addons 的配置項，細節再也不贅述。

Machine Operator

Machine Operator 負責對節點作必要的初始化操做，而後建立節點的 docker、k8s、NVIDIA 等組件並維護其終態；最後，將節點加入業務集羣。

咱們採用了阿里雲-雲原生應用平臺-Serverless 節點管理團隊維護的 KubeNode 組件，該 Operator 負責集團內節點的上下線，實現了一個面向終態的運維框架，能夠針對不一樣 Arch 或者不一樣 OS 定製運維 CRD，比較適合在環境多變的專有云環境使用。

KubeNode 簡而言之實現了一個面向終態的運維框架，它主要包含 Component+Machine 兩個概念。

1.使用者按模板提供運維腳本，生成 Component CR； 2.若是要上線節點，就生成一個 Machine CR，Machine CR 裏會指定須要部署哪些 Component； 3.KubeNode 監聽到 Machine CR，會到對應節點進行運維操做。

這種設計理論上能夠針對不一樣 Arch 或者不一樣 OS 能夠在不改動 Operator 源碼的前提下進行擴展，靈活度很高。同時，咱們也在探索如何結合 IaaS provider，最終實現 RunAnyWhere 的目標。

多集羣方案成本對比

在使用自動化工具（也是一個雲原生的 Operator，後續會有文章介紹）串接上述流程後，咱們能夠將一個集羣的生產時間壓縮到分鐘級。

下圖列舉了平鋪式多集羣解決方案（直接部署多套）和 KOK 多集羣解決方案的成本分析：

	平鋪式多集羣解決方案	KOK多集羣解決方案
交付成本	TKG	TG+tG*(K-1)
升級成本	UGP*K	UGP+uGP*(K-1)
用戶使用成本	T*K	t*K

其中，T 爲單個 K8s 集羣部署時間，t 爲單個業務集羣的部署時間，K 爲集羣數，G 爲局點數，U 爲升級元集羣時間，u 爲升級業務集羣時間，P 爲升級次數。

從咱們的實踐經驗獲得，正常狀況下，T、U 爲約爲 1 小時，t、u 約爲 10 分鐘，咱們預計：

• 交付多集羣（集羣數爲 3）時間將由 > 3小時降爲 <1 小時；
• 升級 1 套集羣的時間將由 >1 小時降爲 10 分鐘；
• 用戶自建 1 套新集羣的時間開銷將由 >2 小時降爲 10 分鐘。

總結

平鋪式多集羣勢必帶來運維複雜度的線性上升，難以維護；而 KOK 多集羣將 K8s 集羣自己視爲一個 K8s 資源，利用 K8s 強大的 CRD+Operator 能力，將 K8s 的運維自己也從傳統的過程式升級爲聲明式，對 K8s 集羣的運維複雜度實行了降維打擊。

與此同時，本文介紹的多集羣設計方案，在借鑑阿里巴巴集團內多年運維經驗的基礎上，採用雲原生的架構，擺脫了對差別性基礎設施的依賴，實現了 RunAnyWhere。使用者只須要提供普通的 IaaS 設施，就能夠享受到易用、穩定、輕量的 K8s 多集羣能力。 

雲原生應用平臺團隊招人啦！

阿里雲原生應用平臺團隊目前求賢若渴，若是你知足：

• 對容器和基礎設施相關領域的雲原生技術充滿熱情，在相關領域如 Kubernetes、Serverless 平臺、容器網絡與存儲、運維平臺等雲原生基礎設施其中某一方向有豐富的積累和突出成果（如產品落地，創新技術實現，開源貢獻，領先的學術成果）；

• 優秀的表達能力，溝通能力和團隊協做能力；對技術和業務有前瞻性思考；具有較強的 ownership，以結果爲導向，善於決策；

• 至少熟悉 Java、Golang 中的一項編程語言；

• 本科及以上學歷、3 年以上工做經驗。

課程推薦

爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

點擊便可免費觀看課程：http://www.jintianxuesha.com/?cate=2

www.shbkrcxzz.cn
www.moxinylzc.cn 
www.hongszaix.cn 
www.baijiazaixian.cn
www.hengxun2zc.cn

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