在 2019 年 雙11 中，容器服務(wù) ACK 支撐了阿里巴巴內(nèi)部核心系統(tǒng)容器化和阿里云的云產(chǎn)品本身，也將阿里巴巴多年的大規(guī)模容器技術(shù)以產(chǎn)品化的能力輸出給眾多圍繞 雙11 的生態(tài)公司。通過(guò)支撐來(lái)自全球各行各業(yè)的容器云，容器服務(wù)沉淀了支持單元化全球化架構(gòu)和柔性架構(gòu)的云原生應(yīng)用托管中臺(tái)能力，管理了超過(guò) 1W 個(gè)以上的容器集群。本文將會(huì)介紹容器服務(wù)在海量 Kubernetes 集群管理上的實(shí)踐經(jīng)驗(yàn)。

什么是海量 Kubernetes 集群管理？

大家可能之前看過(guò)一些分享，介紹了阿里巴巴如何管理單集群 1W 節(jié)點(diǎn)的最佳實(shí)踐，管理大規(guī)模節(jié)點(diǎn)是一個(gè)很有意思的挑戰(zhàn)。不過(guò)這里講的海量 Kubernetes 集群管理，會(huì)側(cè)重講如何管理超過(guò) 1W 個(gè)以上不同規(guī)格的 Kubernetes 集群。根據(jù)我們和一些同行的溝通，往往一個(gè)企業(yè)內(nèi)部只要管理幾個(gè)到幾十個(gè) Kubernetes 集群，那么我們?yōu)槭裁葱枰紤]管理如此龐大數(shù)量的 Kbernetes 集群？

• 首先，容器服務(wù) ACK 是阿里云上的云產(chǎn)品，提供了 Kubernetes as a Service 的能力，面向全球客戶，目前已經(jīng)在全球 20 個(gè)地域支持；

• 其次，得益于云原生時(shí)代的發(fā)展，越來(lái)越多的企業(yè)擁抱 Kubernetes，Kubernetes 已經(jīng)逐漸成為云原生時(shí)代的基礎(chǔ)設(shè)施，成為 platform of platform。

背景介紹

首先我們一起來(lái)看下托管這些 Kubernetes 集群的痛點(diǎn)：

1.集群種類不同：有標(biāo)準(zhǔn)的、無(wú)服務(wù)器的、AI 的、裸金屬的、邊緣、Windows 等 Kubernetes 集群。不同種類的集群參數(shù)、組件和托管要求不一樣，并且需要支撐更多面向垂直場(chǎng)景的 Kubernetes；

2.集群大小不一：每個(gè)集群規(guī)模大小不一，從幾個(gè)節(jié)點(diǎn)到上萬(wàn)個(gè)節(jié)點(diǎn)，從幾個(gè) service 到幾千個(gè) service 等，需要能夠支撐每年持續(xù)幾倍集群數(shù)量的增長(zhǎng)；

3.集群安全合規(guī)：分布在不同的地域和環(huán)境的 Kubernetes 集群，需要遵循不同的合規(guī)性要求。比如歐洲的 Kubernetes 集群需要遵循歐盟的 GDPR 法案，在中國(guó)的金融業(yè)和政務(wù)云需要有額外的等級(jí)保護(hù)等要求；

4.集群持續(xù)演進(jìn)：需要能夠持續(xù)的支持 Kubernetes 的新版本新特性演進(jìn)。

設(shè)計(jì)目標(biāo)：

1. 支持單元化的分檔管理、容量規(guī)劃和水位管理；

2. 支持全球化的部署、發(fā)布、容災(zāi)和可觀測(cè)性；

3. 支持柔性架構(gòu)的可插拔、可定制、積木式的持續(xù)演進(jìn)能力。

1.支持單元化的分檔管理、容量規(guī)劃和水位管理

單元化

一般講到單元化，大家都會(huì)聯(lián)想到單機(jī)房容量不夠或二地三中心災(zāi)備等場(chǎng)景。那單元化和 Kubernetes 管理有什么關(guān)系？

對(duì)我們來(lái)說(shuō)，一個(gè)地域（比如：杭州）可能會(huì)管理幾千個(gè) Kubernetes，需要統(tǒng)一維護(hù)這些 Kubernetes 的集群生命周期管理。作為一個(gè) Kubernetes 專業(yè)團(tuán)隊(duì)，一個(gè)樸素的想法就是通過(guò)多個(gè) Kubernetes 元集群來(lái)管理這些 guest K8s master。而一個(gè) Kubernetes 元集群的邊界就是一個(gè)單元。

曾經(jīng)我們經(jīng)常聽說(shuō)某某機(jī)房光纖被挖斷，某某機(jī)房電力因故障而導(dǎo)致服務(wù)中斷，容器服務(wù) ACK 在設(shè)計(jì)之初就支持了同城多活的架構(gòu)形態(tài)，任何一個(gè)用戶 Kubernetes 集群的 master 組件都會(huì)自動(dòng)地分散在多個(gè)機(jī)房，不會(huì)因單機(jī)房問(wèn)題而影響集群穩(wěn)定性；另外一個(gè)層面，同時(shí)要保證 master 組件間的通信穩(wěn)定性，容器服務(wù) ACK 在打散 master 時(shí)調(diào)度策略上也會(huì)盡量保證 master 組件間通信延遲在毫秒級(jí)。

分檔化

大家都知道，Kubernetes 集群的 master 組件的負(fù)載主要與 Kubernetes 集群的節(jié)點(diǎn)規(guī)模、worker 側(cè)的 controller 或 workload 等需要與 kube-apiserver 交互的組件數(shù)量和調(diào)用頻率息息相關(guān)，對(duì)于上萬(wàn)個(gè) Kubernetes 集群，每個(gè)用戶 Kubernetes 集群的規(guī)模和業(yè)務(wù)形態(tài)都千差萬(wàn)別，我們無(wú)法用一套標(biāo)準(zhǔn)配置來(lái)去管理所有的用戶 Kubernetes 集群。

同時(shí)，從成本經(jīng)濟(jì)角度考慮，我們提供了一種更加靈活、更加智能的托管能力。考慮到不同資源類型會(huì)對(duì) master 產(chǎn)生不同的負(fù)載壓力，因此我們需要為每類資源設(shè)置不同的因子，最終可歸納出一個(gè)計(jì)算范式，通過(guò)此范式可計(jì)算出每個(gè)用戶 Kubernetes 集群 master 所適應(yīng)的檔位。另外，我們也會(huì)基于已構(gòu)建的 Kubernetes 統(tǒng)一監(jiān)控平臺(tái)實(shí)時(shí)指標(biāo)來(lái)不斷地優(yōu)化和調(diào)整這些因素值和范式，從而可實(shí)現(xiàn)智能平滑換擋的能力。

容量規(guī)劃

接下來(lái)我們看下 Kubernetes 元集群的容量模型，單個(gè)元集群到底能托管多少個(gè)用戶 Kubernetes 集群的 master?

• 首先，要確認(rèn)容器網(wǎng)絡(luò)規(guī)劃。這里我們選擇了阿里云自研的高性能容器網(wǎng)絡(luò) Terway, 一方面需要通過(guò)彈性網(wǎng)卡 ENI 打通用戶 VPC 和托管 master 的網(wǎng)絡(luò)，另一方面提供了高性能和豐富的安全策略；

• 接下來(lái)，我們需要結(jié)合 VPC 內(nèi)的 ip 資源，做網(wǎng)段的規(guī)劃，分別提供給 node、pod 和 service。

• 最后，我們會(huì)結(jié)合統(tǒng)計(jì)規(guī)律，結(jié)合成本、密度、性能、資源配額、檔位配比等多種因素的綜合考量，設(shè)計(jì)每個(gè)元集群?jiǎn)卧胁渴鸬牟煌瑱n位的 guest Kubernetes 的個(gè)數(shù)，并預(yù)留 40% 的水位。

2.支持全球化的部署、發(fā)布、容災(zāi)和可觀測(cè)性

容器服務(wù)已經(jīng)在全球 20 個(gè)地域支持，我們提供了完全自動(dòng)化的部署、發(fā)布、容災(zāi)和可觀測(cè)性能力，接下來(lái)將重點(diǎn)介紹全球化跨數(shù)據(jù)中心的可觀測(cè)。

全球跨數(shù)據(jù)中心的可觀測(cè)性

全球化布局的大型集群的可觀測(cè)性，對(duì)于 Kubernetes 集群的日常保障至關(guān)重要。如何在紛繁復(fù)雜的網(wǎng)絡(luò)環(huán)境下高效、合理、安全、可擴(kuò)展的采集各個(gè)數(shù)據(jù)中心中目標(biāo)集群的實(shí)時(shí)狀態(tài)指標(biāo)，是可觀測(cè)性設(shè)計(jì)的關(guān)鍵與核心。

我們需要兼顧區(qū)域化數(shù)據(jù)中心、單元化集群范圍內(nèi)可觀測(cè)性數(shù)據(jù)的收集，以及全局視圖的可觀測(cè)性和可視化。基于這種設(shè)計(jì)理念和客觀需求，全球化可觀測(cè)性必須使用多級(jí)聯(lián)合方式，也就是邊緣層的可觀測(cè)性實(shí)現(xiàn)下沉到需要觀測(cè)的集群內(nèi)部，中間層的可觀測(cè)性用于在若干區(qū)域內(nèi)實(shí)現(xiàn)監(jiān)控?cái)?shù)據(jù)的匯聚，中心層可觀測(cè)性進(jìn)行匯聚、形成全局化視圖以及告警。

這樣設(shè)計(jì)的好處在于可以靈活地在每一級(jí)別層內(nèi)進(jìn)行擴(kuò)展以及調(diào)整，適合于不斷增長(zhǎng)的集群規(guī)模，相應(yīng)的其他級(jí)別只需調(diào)整參數(shù)，層次結(jié)構(gòu)清晰；網(wǎng)絡(luò)結(jié)構(gòu)簡(jiǎn)單，可以實(shí)現(xiàn)內(nèi)網(wǎng)數(shù)據(jù)穿透到公網(wǎng)并匯聚。

針對(duì)該全球化布局的大型集群的監(jiān)控系統(tǒng)設(shè)計(jì)，對(duì)于保障集群的高效運(yùn)轉(zhuǎn)至關(guān)重要，我們的設(shè)計(jì)理念是在全球范圍內(nèi)將各個(gè)數(shù)據(jù)中心的數(shù)據(jù)實(shí)時(shí)收集并聚合，實(shí)現(xiàn)全局視圖查看和數(shù)據(jù)可視化，以及故障定位、告警通知。

進(jìn)入云原生時(shí)代，Prometheus 作為 CNCF 第二個(gè)畢業(yè)的項(xiàng)目，天生適用于容器場(chǎng)景，Prometheus 與 Kubernetes 結(jié)合一起，實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和對(duì)動(dòng)態(tài)調(diào)度服務(wù)的監(jiān)控，在各種監(jiān)控方案中具有很大的優(yōu)勢(shì)，實(shí)際上已經(jīng)成為容器監(jiān)控方案的標(biāo)準(zhǔn)，所以我們也選擇了 Prometheus 作為方案的基礎(chǔ)。

針對(duì)每個(gè)集群，需要采集的主要指標(biāo)類別包括：

1. OS 指標(biāo)，例如節(jié)點(diǎn)資源（CPU, 內(nèi)存，磁盤等）水位以及網(wǎng)絡(luò)吞吐；

2. 元集群以及用戶集群 Kubernetes master 指標(biāo)，例如 kube-apiserver, kube-controller-manager, kube-scheduler 等指標(biāo)；

3. Kubernetes 組件（kubernetes-state-metrics，cadvisor）采集的關(guān)于 Kubernetes 集群狀態(tài)；

4. etcd 指標(biāo)，例如 etcd 寫磁盤時(shí)間，DB size，Peer 之間吞吐量等等。

當(dāng)全局?jǐn)?shù)據(jù)聚合后，AlertManager 對(duì)接中心 Prometheus，驅(qū)動(dòng)各種不同的告警通知行為，例如釘釘、郵件、短信等方式。

監(jiān)控告警架構(gòu)

為了合理地將監(jiān)控壓力負(fù)擔(dān)分到多個(gè)層次的 Prometheus 并實(shí)現(xiàn)全局聚合，我們使用了聯(lián)邦 Federation 的功能。在聯(lián)邦集群中，每個(gè)數(shù)據(jù)中心部署單獨(dú)的 Prometheus，用于采集當(dāng)前數(shù)據(jù)中心監(jiān)控?cái)?shù)據(jù)，并由一個(gè)中心的 Prometheus 負(fù)責(zé)聚合多個(gè)數(shù)據(jù)中心的監(jiān)控?cái)?shù)據(jù)。

基于 Federation 的功能，我們?cè)O(shè)計(jì)的全球監(jiān)控架構(gòu)圖如下，包括監(jiān)控體系、告警體系和展示體系三部分。

監(jiān)控體系按照從元集群監(jiān)控向中心監(jiān)控匯聚的角度，呈現(xiàn)為樹形結(jié)構(gòu)，可以分為三層：

1、邊緣 Prometheus

為了有效監(jiān)控元集群 Kubernetes 和用戶集群 Kubernetes 的指標(biāo)、避免網(wǎng)絡(luò)配置的復(fù)雜性，將 Prometheus 下沉到每個(gè)元集群內(nèi)。

2、級(jí)聯(lián) Prometheus

級(jí)聯(lián) Prometheus 的作用在于匯聚多個(gè)區(qū)域的監(jiān)控?cái)?shù)據(jù)。級(jí)聯(lián) Prometheus 存在于每個(gè)大區(qū)域，例如中國(guó)區(qū)、歐洲區(qū)、美洲區(qū)、亞洲區(qū)。每個(gè)大區(qū)域內(nèi)包含若干個(gè)具體的區(qū)域，例如北京、上海、東京等。隨著每個(gè)大區(qū)域內(nèi)集群規(guī)模的增長(zhǎng)，大區(qū)域可以拆分成多個(gè)新的大區(qū)域，并始終維持每個(gè)大區(qū)域內(nèi)有一個(gè)級(jí)聯(lián) Prometheus，通過(guò)這種策略可以實(shí)現(xiàn)靈活的架構(gòu)擴(kuò)展和演進(jìn)。

3、中心 Prometheus

中心 Prometheus 用于連接所有的級(jí)聯(lián) Prometheus，實(shí)現(xiàn)最終的數(shù)據(jù)聚合、全局視圖和告警。為提高可靠性，中心 Prometheus 使用雙活架構(gòu)，也就是在不同可用區(qū)布置兩個(gè) Prometheus 中心節(jié)點(diǎn)，都連接相同的下一級(jí) Prometheus。

圖2-1 基于 Prometheus Federation 的全球多級(jí)別監(jiān)控架構(gòu)

優(yōu)化策略

1.監(jiān)控?cái)?shù)據(jù)流量與 API server 流量分離

API server 的代理功能可以使得 Kubernetes 集群外通過(guò) API server 訪問(wèn)集群內(nèi)的 Pod、Node 或者 Service。

圖3-1 通過(guò) API Server 代理模式訪問(wèn) Kubernetes 集群內(nèi)的 Pod 資源

常用的透?jìng)?Kubernetes 集群內(nèi) Prometheus 指標(biāo)到集群外的方式是通過(guò) API server 代理功能，優(yōu)點(diǎn)是可以重用 API server 的 6443 端口對(duì)外開放數(shù)據(jù)，管理簡(jiǎn)便；缺點(diǎn)也明顯，增加了 API server 的負(fù)載壓力。

如果使用 API Server 代理模式，考慮到客戶集群以及節(jié)點(diǎn)都會(huì)隨著售賣而不斷擴(kuò)大，對(duì) API server 的壓力也越來(lái)越大并增加了潛在的風(fēng)險(xiǎn)。對(duì)此，針對(duì)邊緣 Prometheus 增加了 LoadBalancer 類型的 service，監(jiān)控流量完全 LoadBalancer，實(shí)現(xiàn)流量分離。即便監(jiān)控的對(duì)象持續(xù)增加，也保證了 API server 不會(huì)因此增加 Proxy 功能的開銷。

2.收集指定 Metric

在中心 Prometheus 只收集需要使用的指標(biāo)，一定不能全量抓取，否則會(huì)造成網(wǎng)絡(luò)傳輸壓力過(guò)大丟失數(shù)據(jù)。

3.Label 管理

Label 用于在級(jí)聯(lián) Prometheus 上標(biāo)記 region 和元集群，所以在中心 Prometheus 匯聚是可以定位到元集群的顆粒度。同時(shí)，盡量減少不必要的 label，實(shí)現(xiàn)數(shù)據(jù)節(jié)省。

3.支持柔性架構(gòu)的可插拔、可定制、積木式的持續(xù)演進(jìn)能力

前面兩部分簡(jiǎn)要描述了如何管理海量 Kubernetes 集群的一些思考，然而光做到全球化、單元化的管理還遠(yuǎn)遠(yuǎn)不夠。Kubernetes 能夠成功，包含了聲明式的定義、高度活躍的社區(qū)、良好的架構(gòu)抽象等因素，Kubernetes 已經(jīng)成為云原生時(shí)代的 Linux。

我們必須要考慮 Kubernetes 版本的持續(xù)迭代和 CVE 漏洞的修復(fù)，必須要考慮 Kubernetes 相關(guān)組件的持續(xù)更新，無(wú)論是 CSI、CNI、Device Plugin 還是 Scheduler Plugin 等等。為此我們提供了完整的集群和組件的持續(xù)升級(jí)、灰度、暫停等功能。

組件可插拔

組件檢查

組件升級(jí)

2019 年 6 月，阿里巴巴將內(nèi)部的云原生應(yīng)用自動(dòng)化引擎 OpenKruise 開源，這里我們重點(diǎn)介紹下其中的 BroadcastJob 功能，它非常適用于每臺(tái) worker 機(jī)器上的組件進(jìn)行升級(jí)，或者對(duì)每臺(tái)機(jī)器上的節(jié)點(diǎn)進(jìn)行檢測(cè)。（Broadcast Job 會(huì)在集群中每個(gè) node 上面跑一個(gè) pod 直至結(jié)束。類似于社區(qū)的 DaemonSet, 區(qū)別在于 DaemonSet 始終保持一個(gè) pod 長(zhǎng)服務(wù)在每個(gè) node 上跑，而 BroadcastJob 中最終這個(gè) pod 會(huì)結(jié)束。） 

集群模板

此外，考慮不同 Kubernetes 使用場(chǎng)景，我們提供了多種 Kubernetes 的 cluster profile，可以方便用戶進(jìn)行更方便的集群選擇。我們會(huì)結(jié)合大量集群的實(shí)踐，持續(xù)提供更多更好的集群模板。

總結(jié)

隨著云計(jì)算的發(fā)展,以 Kubernetes 為基礎(chǔ)的云原生技術(shù)持續(xù)推動(dòng)行業(yè)進(jìn)行數(shù)字化轉(zhuǎn)型。

容器服務(wù) ACK 提供了安全穩(wěn)定、高性能的 Kubernetes 托管服務(wù)，已經(jīng)成為云上運(yùn)行 Kubernetes 的最佳載體。在本次 雙11，容器服務(wù) ACK 在各個(gè)場(chǎng)景為 雙11 做出貢獻(xiàn)，支撐了阿里巴巴內(nèi)部核心系統(tǒng)容器化上云，支撐了阿里云微服務(wù)引擎 MSE、視頻云、CDN 等云產(chǎn)品，也支撐了 雙11 的生態(tài)公司和 ISV 公司，包括聚石塔電商云、菜鳥物流云、東南亞的支付系統(tǒng)等等。

容器服務(wù) ACK 會(huì)持續(xù)前行，持續(xù)提供更高更好的云原生容器網(wǎng)絡(luò)、存儲(chǔ)、調(diào)度和彈性能力、端到端的全鏈路安全能力、serverless 和 servicemesh 等能力。