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

什么是海量 Kubernetes 集群管理？

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

• 首先，容器服務 ACK 是阿里云上的云產品，提供了 Kubernetes as a Service 的能力，面向全球客戶，目前已經在全球 20 個地域支持；

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

背景介紹

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

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

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

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

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

設計目標：

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

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

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

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

單元化

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

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

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

分檔化

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

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

容量規(guī)劃

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

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

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

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

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

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

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

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

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

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

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

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

針對每個集群，需要采集的主要指標類別包括：

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

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

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

4. etcd 指標，例如 etcd 寫磁盤時間，DB size，Peer 之間吞吐量等等。

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

監(jiān)控告警架構

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

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

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

1、邊緣 Prometheus

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

2、級聯(lián) Prometheus

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

3、中心 Prometheus

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

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

優(yōu)化策略

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

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

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

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

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

2.收集指定 Metric

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

3.Label 管理

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

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

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

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

組件可插拔

組件檢查

組件升級

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

集群模板

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

總結

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

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

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