作者 | 淮右、臨石

**導(dǎo)讀：**單 K8s 集群為用戶提供了 Namespace 級(jí)別的隔離能力，理論上支持不超過(guò) 5K Node、15W Pod。多 K8s 集群則解決了單集群的資源隔離、故障隔離難題，打破可支持節(jié)點(diǎn)數(shù)、Pod 數(shù)的限制，但與此同時(shí)也帶來(lái)了集群管理復(fù)雜度的上升；尤其在專有云場(chǎng)景中，K8s 工程師不可能像在公有云中一樣快速觸達(dá)客戶環(huán)境，運(yùn)維成本被進(jìn)一步放大。因此如何低成本、高效率、自動(dòng)化低管理多套 K8s 集群，成為業(yè)內(nèi)普遍難題。

背景

多集群主要應(yīng)用在如下場(chǎng)景：

1.產(chǎn)品本身需要多集群能力。產(chǎn)品的管控需要部署在 K8s 集群內(nèi)，同時(shí)，該產(chǎn)品還需要提供 K8s 集群給用戶使用，從故障隔離、穩(wěn)定性、安全多重角度考慮，容器服務(wù)的管控和業(yè)務(wù)應(yīng)該分別部署在不同的集群內(nèi)；
2.用戶在使用 K8s 的時(shí)候，也希望具備生產(chǎn)多套集群供不同業(yè)務(wù)使用，從而進(jìn)行資源隔離、故障隔離；
3.同一用戶可能需要多種類型集群的能力，以邊緣計(jì)算 IOT 為例，它需要一個(gè)定制的邊緣 K8s 集群，如果按照普通的獨(dú)立 K8s 集群來(lái)創(chuàng)建，一方面會(huì)存在資源浪費(fèi)，另一方面獨(dú)立的集群為用戶增加了運(yùn)維的成本。

我們總結(jié)了運(yùn)維 K8s 集群的難點(diǎn)，可以分為兩部分：

難點(diǎn) 1：運(yùn)維 K8s 集群的管控面

• 如何支持用戶一鍵彈出新的 Kubernetes 集群？
• 如何升級(jí)多個(gè) K8s 集群的版本，當(dāng)社區(qū)重大 CVE 發(fā)現(xiàn)時(shí)，是否要一個(gè)個(gè)升級(jí)集群？
• 如何自動(dòng)修復(fù)多個(gè) K8s 集群運(yùn)行時(shí)發(fā)生的故障？
• 如何對(duì)集群的 etcd 進(jìn)行維護(hù)，包括升級(jí)、備份、恢復(fù)、節(jié)點(diǎn)遷移？

難點(diǎn) 2：運(yùn)維 Worker 節(jié)點(diǎn)

• 如何快速擴(kuò)縮容 Worker 節(jié)點(diǎn)？同時(shí)需要確保每個(gè)節(jié)點(diǎn)的 on-host 軟件（例如 docker、kubelet 等無(wú)法被 K8s 托管的組件）版本、配置和其他節(jié)點(diǎn)拉齊。
• 如何升級(jí)若干 Worker 節(jié)點(diǎn)上的 on-host 軟件？如何灰度發(fā)布 Worker 節(jié)點(diǎn)上的軟件包？
• 如何自動(dòng)修復(fù)若干 Worker 節(jié)點(diǎn)可能出現(xiàn)的 on-host 軟件故障？比如要是 docker/kubelet 發(fā)生 panic，我們是否能自動(dòng)化的處理？

K8s 作為一個(gè)復(fù)雜的自動(dòng)化運(yùn)維系統(tǒng)，支撐了上層業(yè)務(wù)的發(fā)布、升級(jí)、生命周期管理，但 K8s 本身的運(yùn)維在業(yè)內(nèi)卻往往還是由一個(gè)工作流（ansible、argo 等）來(lái)執(zhí)行。這個(gè)過(guò)程的自動(dòng)化程度不高，需要運(yùn)維人員具備比較專業(yè)的 K8s 知識(shí)。而當(dāng)需要運(yùn)維多套 K8s 集群后，運(yùn)維成本在理想情況下也會(huì)線性上升，在專有云場(chǎng)景下成本還會(huì)被再次放大。

阿里內(nèi)部很早就遇到了運(yùn)維大量 K8s 集群的難題，我們摒棄了傳統(tǒng)工作流的模式，探索另外一條路徑：使用 K8s 管理 K8s，CNCF 的文章《Demystifying Kubernetes as a Service – How Alibaba Cloud Manages 10,000s of Kubernetes Clusters》介紹了阿里巴巴在大規(guī)模 K8s 集群管理上的探索與經(jīng)驗(yàn)。

當(dāng)然，專有云場(chǎng)景和阿里巴巴內(nèi)部場(chǎng)景還是有較大不同，阿里集團(tuán)內(nèi)使用 Kube-On-Kube 技術(shù)主要看重它的規(guī)模效應(yīng)，可以使用一個(gè)元 K8s 集群來(lái)管理成百上千的業(yè)務(wù) K8s 集群，而專有云場(chǎng)景的規(guī)模效應(yīng)小，專有云主要看重的是Kube-On-Kube 技術(shù)自動(dòng)化運(yùn)維 K8s 集群和兼容多種 K8s 集群的能力，在提高穩(wěn)定性的同時(shí)豐富了用戶的使用場(chǎng)景。

K8s 聲明式運(yùn)維哲學(xué)：用 K8s 管理 K8s

K8s 的聲明式 API 顛覆了傳統(tǒng)的過(guò)程式運(yùn)維模式，聲明式 API 對(duì)應(yīng)的是面向終態(tài)的運(yùn)維模式：使用者將在 Spec 里定義自己所期望的狀態(tài)，K8s 的 Controller 會(huì)進(jìn)行一系列操作幫助使用者達(dá)到期望狀態(tài)，只要不滿足要求，Controller 會(huì)一直嘗試。

對(duì)于 Deployment 等 K8s 原生資源，由 K8s 的 Controller 負(fù)責(zé)終態(tài)維護(hù)，而對(duì)于用戶自定義的資源，例如一個(gè) Cluster，K8s 提供了強(qiáng)大易用的 CRD+Operator 機(jī)制，只需要簡(jiǎn)單幾步就可以實(shí)現(xiàn)自定義的面向終態(tài)運(yùn)維：

1.定義自己的資源類型（CRD），實(shí)現(xiàn)自己的 Operator，Operator 中包含了自定義 Controller；
2.用戶只需要提交自己的 CR，表現(xiàn)形式為一個(gè) yaml 或者 json；
3.Operator 監(jiān)聽(tīng)到 CR 的變化，Controller 開(kāi)始執(zhí)行對(duì)應(yīng)的運(yùn)維邏輯；
4.在運(yùn)行過(guò)程中，當(dāng)終態(tài)不滿足要求時(shí)，Operator 也能夠監(jiān)聽(tīng)到變化，并做出相應(yīng)的恢復(fù)操作。

Operator 是用代碼運(yùn)維應(yīng)用最好的實(shí)踐之一。當(dāng)然，這只是一個(gè)框架，它節(jié)省了使用者的一些重復(fù)性勞動(dòng)，如事件監(jiān)聽(tīng)機(jī)制、RESTful API 監(jiān)聽(tīng)，但核心的運(yùn)維邏輯，還是需要 case by case 由使用者編寫(xiě)。

云原生的 KOK 架構(gòu)

Kube-On-Kube 不是新概念，業(yè)內(nèi)已有很多優(yōu)秀的解決方案：

• 螞蟻
• 社區(qū)項(xiàng)目

但是以上方案對(duì)公有云基礎(chǔ)設(shè)施有較強(qiáng)依賴，專有云的特殊性讓我們要考慮：

• 足夠輕量化用戶才會(huì)買單，客戶通常很排斥獨(dú)占的管理節(jié)點(diǎn)開(kāi)銷；
• 不依賴公有云和阿里集團(tuán)內(nèi)部的差異性基礎(chǔ)設(shè)施；
• 采用云原生架構(gòu)。

在考慮到這 3 個(gè)因素后，我們?cè)O(shè)計(jì)出更為通用的 KOK 方案：

名詞解釋：

• Meta Cluster：元集群，即 Kube-On-Kube 的下層 Kube；
• Production Cluster：業(yè)務(wù)集群，即 Kube-On-Kube 的上層 Kube；
• etcd cluster：由運(yùn)行在元集群中的 etcd operator 創(chuàng)建和維護(hù)的 etcd 集群，可以每個(gè)業(yè)務(wù)集群獨(dú)占一個(gè) etcd，或者多個(gè)業(yè)務(wù)集群共享；
• PC-master-pod：業(yè)務(wù)集群管控 pod，實(shí)際上是 apiserver/scheduler/controller-manager 這 3 種 pod，由運(yùn)行在元集群的 Cluster Operator 維護(hù)；
• PC-nodes：業(yè)務(wù)集群的 Node 節(jié)點(diǎn)，由 Machine Operator 負(fù)責(zé)初始化并加入到業(yè)務(wù)集群，由 Machine Operator 維護(hù)；

etcd Operator

etcd Operator 負(fù)責(zé) etcd 集群的創(chuàng)建、銷毀、升級(jí)、故障恢復(fù)等，還提供了 etcd 集群的狀態(tài)監(jiān)控，包括集群健康狀態(tài)、member 健康狀態(tài)、存儲(chǔ)數(shù)據(jù)量等。

阿里云-云原生應(yīng)用平臺(tái)-SRE 團(tuán)隊(duì)對(duì)開(kāi)源版 etcd Operator 進(jìn)行了改進(jìn)，增強(qiáng)了運(yùn)維功能和穩(wěn)定性，該 Operator 負(fù)責(zé)阿里內(nèi)部大量 etcd 集群的運(yùn)維管理，運(yùn)行穩(wěn)定，久經(jīng)考驗(yàn)。

Cluster Operator

Cluster Operator 負(fù)責(zé)業(yè)務(wù)集群 K8s 管控組件（Apiserver、Controller Manager、Scheduler）的創(chuàng)建、維護(hù)，以及相應(yīng)的證書(shū)生成、kubeconfig 生成。

我們和螞蟻集團(tuán)-PaaS 引擎與專有云產(chǎn)品團(tuán)隊(duì)共建了 Cluster Operator，具備自定義渲染、版本溯源、動(dòng)態(tài)增加可支持版本等能力。

業(yè)務(wù)集群的 K8s 管控組件部署在元集群，從元集群的視角看就是一堆普通的 Resource，包括 Deployment、Secret、Pod、PVC 等，因此，業(yè)務(wù)集群不具備 Master 節(jié)點(diǎn)的概念：

• kube-apiserver：由 1 個(gè) Deployment +1 個(gè) Service 組成。kube-apiserver 本身無(wú)狀態(tài)，Deployment 可以滿足要求，同時(shí)，Apiserver 需要對(duì)接 etcd Operator 拉起的 etcd cluster；Service 用于對(duì)業(yè)務(wù)集群其他組件以及對(duì)外暴露 Apiserver 的服務(wù)，此處我們考慮了，如果用戶環(huán)境具備 LoadBalancer Service 的能力，建議優(yōu)先使用 LoadBalancer 暴露 Apiserver，如果沒(méi)有此能力，我們也提供了 NodePort 的暴露形態(tài)；
• kube-controller-manager：1 個(gè) Deployment，無(wú)狀態(tài)應(yīng)用；
• kube-scheduler：1 個(gè) Deployment 即可，無(wú)狀態(tài)應(yīng)用；

但是，只部署以上 3 個(gè)組件還不能提供一個(gè)可用 K8s，我們還需要滿足以下場(chǎng)景：

1.一個(gè)可用的業(yè)務(wù) K8s 除了 etcd、3 大件之外，還需要部署 coredns、kube-proxy 或者其他任意組件；
2.部分組件需要和 etcd、3 大件一樣的部署在元集群，例如 Machine Operator 是拉起節(jié)點(diǎn)的組件，它必須在業(yè)務(wù)集群有節(jié)點(diǎn)之前就能運(yùn)作，所以它不能部署在業(yè)務(wù)集群；
3.組件版本的升級(jí)。

因此，為了應(yīng)對(duì)擴(kuò)展性要求，我們?cè)O(shè)計(jì)了 addons 熱插拔能力，只需一條命令即可導(dǎo)入所有 Addon 組件；同時(shí) addons 支持動(dòng)態(tài)渲染能力，可自定義 addons 的配置項(xiàng)，細(xì)節(jié)不再贅述。

Machine Operator

Machine Operator 負(fù)責(zé)對(duì)節(jié)點(diǎn)做必要的初始化操作，然后創(chuàng)建節(jié)點(diǎn)的 docker、k8s、NVIDIA 等組件并維護(hù)其終態(tài)；最后，將節(jié)點(diǎn)加入業(yè)務(wù)集群。

我們采用了阿里云-云原生應(yīng)用平臺(tái)-Serverless 節(jié)點(diǎn)管理團(tuán)隊(duì)維護(hù)的 KubeNode 組件，該 Operator 負(fù)責(zé)集團(tuán)內(nèi)節(jié)點(diǎn)的上下線，實(shí)現(xiàn)了一個(gè)面向終態(tài)的運(yùn)維框架，可以針對(duì)不同 Arch 或者不同 OS 定制運(yùn)維 CRD，比較適合在環(huán)境多變的專有云環(huán)境使用。

KubeNode 簡(jiǎn)而言之實(shí)現(xiàn)了一個(gè)面向終態(tài)的運(yùn)維框架，它主要包含 Component+Machine 兩個(gè)概念。

1.使用者按模板提供運(yùn)維腳本，生成 Component CR；
2.如果要上線節(jié)點(diǎn)，就生成一個(gè) Machine CR，Machine CR 里會(huì)指定需要部署哪些 Component；
3.KubeNode 監(jiān)聽(tīng)到 Machine CR，會(huì)到對(duì)應(yīng)節(jié)點(diǎn)進(jìn)行運(yùn)維操作。

這種設(shè)計(jì)理論上可以針對(duì)不同 Arch 或者不同 OS 可以在不改動(dòng) Operator 源碼的前提下進(jìn)行擴(kuò)展，靈活度很高。同時(shí)，我們也在探索如何結(jié)合 IaaS provider，最終實(shí)現(xiàn) RunAnyWhere 的目標(biāo)。

多集群方案成本對(duì)比

在使用自動(dòng)化工具（也是一個(gè)云原生的 Operator，后續(xù)會(huì)有文章介紹）串接上述流程后，我們可以將一個(gè)集群的生產(chǎn)時(shí)間壓縮到分鐘級(jí)。

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

平鋪式多集群解決方案KOK多集群解決方案

交付成本	TKG	TG+tG*(K-1)
升級(jí)成本	UGP*K	UGP+uGP*(K-1)
用戶使用成本	T*K	t*K

其中，T 為單個(gè) K8s 集群部署時(shí)間，t 為單個(gè)業(yè)務(wù)集群的部署時(shí)間，K 為集群數(shù)，G 為局點(diǎn)數(shù)，U 為升級(jí)元集群時(shí)間，u 為升級(jí)業(yè)務(wù)集群時(shí)間，P 為升級(jí)次數(shù)。

從我們的實(shí)踐經(jīng)驗(yàn)得到，正常情況下，T、U 為約為 1 小時(shí)，t、u 約為 10 分鐘，我們預(yù)計(jì)：

• 交付多集群（集群數(shù)為 3）時(shí)間將由 > 3小時(shí)降為 <1 小時(shí)；
• 升級(jí) 1 套集群的時(shí)間將由 >1 小時(shí)降為 10 分鐘；
• 用戶自建 1 套新集群的時(shí)間開(kāi)銷將由 >2 小時(shí)降為 10 分鐘。

總結(jié)

平鋪式多集群勢(shì)必帶來(lái)運(yùn)維復(fù)雜度的線性上升，難以維護(hù)；而 KOK 多集群將 K8s 集群本身視為一個(gè) K8s 資源，利用 K8s 強(qiáng)大的 CRD+Operator 能力，將 K8s 的運(yùn)維本身也從傳統(tǒng)的過(guò)程式升級(jí)為聲明式，對(duì) K8s 集群的運(yùn)維復(fù)雜度實(shí)行了降維打擊。

與此同時(shí)，本文介紹的多集群設(shè)計(jì)方案，在借鑒阿里巴巴集團(tuán)內(nèi)多年運(yùn)維經(jīng)驗(yàn)的基礎(chǔ)上，采用云原生的架構(gòu)，擺脫了對(duì)差異性基礎(chǔ)設(shè)施的依賴，實(shí)現(xiàn)了 RunAnyWhere。使用者只需要提供普通的 IaaS 設(shè)施，就可以享受到易用、穩(wěn)定、輕量的 K8s 多集群能力。

云原生應(yīng)用平臺(tái)團(tuán)隊(duì)招人啦！

阿里云原生應(yīng)用平臺(tái)團(tuán)隊(duì)目前求賢若渴，如果你滿足：

• 對(duì)容器和基礎(chǔ)設(shè)施相關(guān)領(lǐng)域的云原生技術(shù)充滿熱情，在相關(guān)領(lǐng)域如 Kubernetes、Serverless 平臺(tái)、容器網(wǎng)絡(luò)與存儲(chǔ)、運(yùn)維平臺(tái)等云原生基礎(chǔ)設(shè)施其中某一方向有豐富的積累和突出成果（如產(chǎn)品落地，創(chuàng)新技術(shù)實(shí)現(xiàn)，開(kāi)源貢獻(xiàn)，領(lǐng)先的學(xué)術(shù)成果）；

• 優(yōu)秀的表達(dá)能力，溝通能力和團(tuán)隊(duì)協(xié)作能力；對(duì)技術(shù)和業(yè)務(wù)有前瞻性思考；具備較強(qiáng)的 ownership，以結(jié)果為導(dǎo)向，善于決策；

• 至少熟悉 Java、Golang 中的一項(xiàng)編程語(yǔ)言；

• 本科及以上學(xué)歷、3 年以上工作經(jīng)驗(yàn)。

簡(jiǎn)歷可投遞至郵箱：huaiyou.cyz@alibaba-inc.com，如有疑問(wèn)歡迎加微信咨詢：mdx252525。

課程推薦

為了更多開(kāi)發(fā)者能夠享受到 Serverless 帶來(lái)的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開(kāi)發(fā)者入門(mén)的 Serverless 公開(kāi)課，讓你即學(xué)即用，輕松擁抱云計(jì)算的新范式——Serverless。

點(diǎn)擊即可免費(fèi)觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的灵活、高效的云原生集群管理经验：用 K8s 管理 K8s的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。