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

阿里云上萬個Kubernetes 集群大規(guī)模管理實踐,阿里云kubernetes搭建

阿里云上萬個Kubernetes 集群大規(guī)模管理實踐

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

什么是海量Kubernetes集群管理

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

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

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

背景介紹

首先我們一起來看下托管這些Kubernetes集群的痛點：

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

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

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

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

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

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

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

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

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

單元化

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

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

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

分檔化

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

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

容量規(guī)劃

接下來我們看下Kubernetes元集群的容量模型，單個元集群到底能托管多少個用戶Kubernetes集群的master

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

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

最后，我們會結(jié)合統(tǒng)計規(guī)律，結(jié)合成本、密度、性能、資源配額、檔位配比等多種因素的綜合考量，設(shè)計每個元集群單元中部署的不同檔位的guest Kubernetes的個數(shù)，并預(yù)留40%的水位。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

邊緣Prometheus

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

級聯(lián)Prometheus

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

中心Prometheus

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

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

優(yōu)化策略

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

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

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

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

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

2.收集指定Metric

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

3.Label管理

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

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

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

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

組件可插拔

組件檢查

組件升級

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

集群模板

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

總結(jié)

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

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

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

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

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