阿里云上萬(wàn)個(gè)Kubernetes 集群大規(guī)模管理實(shí)踐,阿里云kubernetes搭建-ESG跨境

阿里云上萬(wàn)個(gè)Kubernetes 集群大規(guī)模管理實(shí)踐,阿里云kubernetes搭建

阿里云上萬(wàn)個(gè)Kubernetes 集群大規(guī)模管理實(shí)踐

在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ù)量的Kubernetes集群

首先，容器服務(wù)ACK是阿里云上的云產(chǎn)品，提供了Kubernetes as a Service的能力，面向全球客戶(hù)，目前已經(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.集群種類(lèi)不同：有標(biāo)準(zhǔn)的、無(wú)服務(wù)器的、AI的、裸金屬的、邊緣、Windows等Kubernetes集群。不同種類(lèi)的集群參數(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)：

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

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

支持柔性架構(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專(zhuān)業(yè)團(tuán)隊(duì)，一個(gè)樸素的想法就是通過(guò)多個(gè)Kubernetes元集群來(lái)管理這些guest K8s master。而一個(gè)Kubernetes元集群的邊界就是一個(gè)單元。

曾經(jīng)我們經(jīng)常聽(tīng)說(shuō)某某機(jī)房光纖被挖斷，某某機(jī)房電力因故障而導(dǎo)致服務(wù)中斷，容器服務(wù)ACK在設(shè)計(jì)之初就支持了同城多活的架構(gòu)形態(tài)，任何一個(gè)用戶(hù)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等需要與kubeapiserver交互的組件數(shù)量和調(diào)用頻率息息相關(guān)，對(duì)于上萬(wàn)個(gè)Kubernetes集群，每個(gè)用戶(hù)Kubernetes集群的規(guī)模和業(yè)務(wù)形態(tài)都千差萬(wàn)別，我們無(wú)法用一套標(biāo)準(zhǔn)配置來(lái)去管理所有的用戶(hù)Kubernetes集群。

同時(shí)，從成本經(jīng)濟(jì)角度考慮，我們提供了一種更加靈活、更加智能的托管能力。考慮到不同資源類(lèi)型會(huì)對(duì)master產(chǎn)生不同的負(fù)載壓力，因此我們需要為每類(lèi)資源設(shè)置不同的因子，最終可歸納出一個(gè)計(jì)算范式，通過(guò)此范式可計(jì)算出每個(gè)用戶(hù)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è)用戶(hù)Kubernetes集群的master

首先，要確認(rèn)容器網(wǎng)絡(luò)規(guī)劃。這里我們選擇了阿里云自研的高性能容器網(wǎng)絡(luò)Terway,一方面需要通過(guò)彈性網(wǎng)卡ENI打通用戶(hù)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)類(lèi)別包括：

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

元集群以及用戶(hù)集群Kubernetes master指標(biāo)，例如kubeapiserver,kubecontrollermanager,kubescheduler等指標(biāo)；

Kubernetes組件（kubernetesstatemetrics，cadvisor）采集的關(guān)于Kubernetes集群狀態(tài)；

etcd指標(biāo)，例如etcd寫(xiě)磁盤(pán)時(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)為樹(shù)形結(jié)構(gòu)，可以分為三層：

邊緣Prometheus

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

級(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)。

中心Prometheus

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

圖2基于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通過(guò)API Server代理模式訪問(wèn)Kubernetes集群內(nèi)的Pod資源

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

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

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開(kāi)源，這里我們重點(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é)束。類(lèi)似于社區(qū)的DaemonSet,區(qū)別在于DaemonSet始終保持一個(gè)pod長(zhǎng)服務(wù)在每個(gè)node上跑，而B(niǎo)roadcastJob中最終這個(gè)pod會(huì)結(jié)束。）

集群模板

此外，考慮不同Kubernetes使用場(chǎng)景，我們提供了多種Kubernetes的cluster profile，可以方便用戶(hù)進(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公司，包括聚石塔電商云、菜鳥(niǎo)物流云、東南亞的支付系統(tǒng)等等。

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

有興趣的開(kāi)發(fā)者，可以前往阿里云控制臺(tái)，創(chuàng)建一個(gè)Kubernetes集群來(lái)體驗(yàn)。同時(shí)也歡迎容器生態(tài)的合作伙伴加入阿里云的容器應(yīng)用市場(chǎng)，和我們一起共創(chuàng)云原生時(shí)代。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問(wèn)題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。