點(diǎn)擊下載《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》一書，點(diǎn)擊上方圖片即可下載！

作者 | 湯志敏，阿里云容器服務(wù)高級(jí)技術(shù)專家

在 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)用托管中臺(tái)能力，管理了超過 1W 個(gè)以上的容器集群。本文將會(huì)介紹容器服務(wù)在海量 Kubernetes 集群管理上的實(shí)踐經(jīng)驗(yàn)。

什么是海量 Kubernetes 集群管理？

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

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

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

背景介紹

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

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

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

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

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

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

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

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

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

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

單元化

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

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

曾經(jīng)我們經(jīng)常聽說某某機(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)定性；另外一個(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ì)于上萬個(gè) Kubernetes?集群，每個(gè)用戶 Kubernetes?集群的規(guī)模和業(yè)務(wù)形態(tài)都千差萬別，我們無法用一套標(biāo)準(zhǔn)配置來去管理所有的用戶 Kubernetes?集群。

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

容量規(guī)劃

接下來我們看下 Kubernetes?元集群的容量模型，單個(gè)元集群到底能托管多少個(gè)用戶?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。

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

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

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

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

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

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

這樣設(shè)計(jì)的好處在于可以靈活地在每一級(jí)別層內(nèi)進(jìn)行擴(kuò)展以及調(diào)整，適合于不斷增長的集群規(guī)模，相應(yīng)的其他級(jí)別只需調(diào)整參數(shù)，層次結(jié)構(gòu)清晰；網(wǎng)絡(luò)結(jié)構(gòu)簡單，可以實(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)目，天生適用于容器場景，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í)際上已經(jīng)成為容器監(jiān)控方案的標(biāo)準(zhǔn)，所以我們也選擇了 Prometheus 作為方案的基礎(chǔ)。

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

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

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

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

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)，可以分為三層：

邊緣 Prometheus

為了有效監(jiān)控元集群 Kubernetes?和用戶集群 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ū)域，例如中國區(qū)、歐洲區(qū)、美洲區(qū)、亞洲區(qū)。每個(gè)大區(qū)域內(nèi)包含若干個(gè)具體的區(qū)域，例如北京、上海、東京等。隨著每個(gè)大區(qū)域內(nèi)集群規(guī)模的增長，大區(qū)域可以拆分成多個(gè)新的大區(qū)域，并始終維持每個(gè)大區(qū)域內(nèi)有一個(gè)級(jí)聯(lián) Prometheus，通過這種策略可以實(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-1?基于 Prometheus Federation 的全球多級(jí)別監(jiān)控架構(gòu)

優(yōu)化策略

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

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

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

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

如果使用 API Server 代理模式，考慮到客戶集群以及節(jié)點(diǎn)都會(huì)隨著售賣而不斷擴(kuò)大，對(duì) API server 的壓力也越來越大并增加了潛在的風(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ò)傳輸壓力過大丟失數(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)能力

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

我們必須要考慮 Kubernetes 版本的持續(xù)迭代和 CVE 漏洞的修復(fù)，必須要考慮 Kubernetes?相關(guān)組件的持續(xù)更新，無論是 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)行檢測。（Broadcast Job 會(huì)在集群中每個(gè) node 上面跑一個(gè) pod 直至結(jié)束。類似于社區(qū)的 DaemonSet, 區(qū)別在于 DaemonSet 始終保持一個(gè) pod 長服務(wù)在每個(gè) node 上跑，而 BroadcastJob 中最終這個(gè) pod 會(huì)結(jié)束。）

集群模板

此外，考慮不同 Kubernetes?使用場景，我們提供了多種 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è)場景為 雙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 等能力。

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

本書亮點(diǎn)

• 雙11 超大規(guī)模 K8s 集群實(shí)踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes 容器 神龍，實(shí)現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細(xì)節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

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

更多相關(guān)信息，請(qǐng)關(guān)注“阿里巴巴云原生”。

總結(jié)

以上是生活随笔為你收集整理的阿里云上万个 Kubernetes 集群大规模管理实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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