作者 | 淮右、臨石
導讀：單 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 年以上工作經驗。
簡歷可投遞至郵箱：[email protected]，如有疑問歡迎加微信諮詢：mdx252525。
課程推薦
為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。
點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”
