阿里雲上萬個 Kubernetes 集羣大規模管理實踐

在 2019 年 雙11 中，容器服務 ACK 支撐了阿里巴巴內部核心系統容器化和阿里雲的雲產品自己，也將阿里巴巴多年的大規模容器技術以產品化的能力輸出給衆多圍繞 雙11 的生態公司。經過支撐來自全球各行各業的容器雲，容器服務沉澱了支持單元化全球化架構和柔性架構的雲原生應用託管中臺能力，管理了超過 1W 個以上的容器集羣。本文將會介紹容器服務在海量 Kubernetes 集羣管理上的實踐經驗。

什麼是海量 Kubernetes 集羣管理？

你們可能以前看過一些分享，介紹了阿里巴巴如何管理單集羣 1W 節點的最佳實踐，管理大規模節點是一個頗有意思的挑戰。不過這裏講的海量 Kubernetes 集羣管理，會側重講如何管理超過 1W 個以上不一樣規格的 Kubernetes 集羣。根據咱們和一些同行的溝通，每每一個企業內部只要管理幾個到幾十個 Kubernetes 集羣，那麼咱們爲何須要考慮管理如此龐大數量的 Kubernetes 集羣？

• 首先，容器服務 ACK 是阿里雲上的雲產品，提供了 Kubernetes as a Service 的能力，面向全球客戶，目前已經在全球 20 個地域支持；
• 其次，得益於雲原生時代的發展，愈來愈多的企業擁抱 Kubernetes，Kubernetes 已經逐漸成爲雲原生時代的基礎設施，成爲 platform of platform。

背景介紹

首先咱們一塊兒來看下託管這些 Kubernetes 集羣的痛點：

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

2.集羣大小不一：每一個集羣規模大小不一，從幾個節點到上萬個節點，從幾個 service 到幾千個 service 等，須要可以支撐每一年持續幾倍集羣數量的增加；

3.集羣安全合規：分佈在不一樣的地域和環境的 Kubernetes 集羣，須要遵循不一樣的合規性要求。好比歐洲的 Kubernetes 集羣須要遵循歐盟的 GDPR 法案，在中國的金融業和政務雲鬚要有額外的等級保護等要求；

4.集羣持續演進：須要可以持續的支持 Kubernetes 的新版本新特性演進。

設計目標：

1. 支持單元化的分檔管理、容量規劃和水位管理；
2. 支持全球化的部署、發佈、容災和可觀測性；
3. 支持柔性架構的可插拔、可定製、積木式的持續演進能力。

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

單元化

通常講到單元化，你們都會聯想到單機房容量不夠或二地三中心災備等場景。那單元化和 Kubernetes 管理有什麼關係？

對咱們來講，一個地域（好比：杭州）可能會管理幾千個 Kubernetes，須要統一維護這些 Kubernetes 的集羣生命週期管理。做爲一個 Kubernetes 專業團隊，一個樸素的想法就是經過多個 Kubernetes 元集羣來管理這些 guest K8s master。而一個 Kubernetes 元集羣的邊界就是一個單元。

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

分檔化

你們都知道，Kubernetes 集羣的 master 組件的負載主要與 Kubernetes 集羣的節點規模、worker 側的 controller 或 workload 等須要與 kube-apiserver 交互的組件數量和調用頻率息息相關，對於上萬個 Kubernetes 集羣，每一個用戶 Kubernetes 集羣的規模和業務形態都千差萬別，咱們沒法用一套標準配置來去管理全部的用戶 Kubernetes 集羣。

同時，從成本經濟角度考慮，咱們提供了一種更加靈活、更加智能的託管能力。考慮到不一樣資源類型會對 master 產生不一樣的負載壓力，所以咱們須要爲每類資源設置不一樣的因子，最終可概括出一個計算範式，經過此範式可計算出每一個用戶 Kubernetes 集羣 master 所適應的檔位。另外，咱們也會基於已構建的 Kubernetes 統一監控平臺實時指標來不斷地優化和調整這些因素值和範式，從而可實現智能平滑換擋的能力。

容量規劃

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

• 首先，要確認容器網絡規劃。這裏咱們選擇了阿里雲自研的高性能容器網絡 Terway, 一方面須要經過彈性網卡 ENI 打通用戶 VPC 和託管 master 的網絡，另外一方面提供了高性能和豐富的安全策略；
• 接下來，咱們須要結合 VPC 內的 ip 資源，作網段的規劃，分別提供給 node、pod 和 service。
• 最後，咱們會結合統計規律，結合成本、密度、性能、資源配額、檔位配比等多種因素的綜合考量，設計每一個元集羣單元中部署的不一樣檔位的 guest Kubernetes 的個數，並預留 40% 的水位。

2.支持全球化的部署、發佈、容災和可觀測性

容器服務已經在全球 20 個地域支持，咱們提供了徹底自動化的部署、發佈、容災和可觀測性能力，接下來將重點介紹全球化跨數據中心的可觀測。

全球跨數據中心的可觀測性

全球化佈局的大型集羣的可觀測性，對於 Kubernetes 集羣的平常保障相當重要。如何在紛繁複雜的網絡環境下高效、合理、安全、可擴展的採集各個數據中心中目標集羣的實時狀態指標，是可觀測性設計的關鍵與核心。

咱們須要兼顧區域化數據中心、單元化集羣範圍內可觀測性數據的收集，以及全局視圖的可觀測性和可視化。基於這種設計理念和客觀需求，全球化可觀測性必須使用多級聯合方式，也就是邊緣層的可觀測性實現下沉到須要觀測的集羣內部，中間層的可觀測性用於在若干區域內實現監控數據的匯聚，中心層可觀測性進行匯聚、造成全局化視圖以及告警。

這樣設計的好處在於能夠靈活地在每一級別層內進行擴展以及調整，適合於不斷增加的集羣規模，相應的其餘級別只需調整參數，層次結構清晰；網絡結構簡單，能夠實現內網數據穿透到公網並匯聚。

針對該全球化佈局的大型集羣的監控系統設計，對於保障集羣的高效運轉相當重要，咱們的設計理念是在全球範圍內將各個數據中心的數據實時收集並聚合，實現全局視圖查看和數據可視化，以及故障定位、告警通知。

進入雲原生時代，Prometheus 做爲 CNCF 第二個畢業的項目，天生適用於容器場景，Prometheus 與 Kubernetes 結合一塊兒，實現服務發現和對動態調度服務的監控，在各類監控方案中具備很大的優點，實際上已經成爲容器監控方案的標準，因此咱們也選擇了 Prometheus 做爲方案的基礎。

針對每一個集羣，須要採集的主要指標類別包括：

1. OS 指標，例如節點資源（CPU, 內存，磁盤等）水位以及網絡吞吐；
2. 元集羣以及用戶集羣 Kubernetes master 指標，例如 kube-apiserver, kube-controller-manager, kube-scheduler 等指標；
3. Kubernetes 組件（kubernetes-state-metrics，cadvisor）採集的關於 Kubernetes 集羣狀態；
4. etcd 指標，例如 etcd 寫磁盤時間，DB size，Peer 之間吞吐量等等。

當全局數據聚合後，AlertManager 對接中心 Prometheus，驅動各類不一樣的告警通知行爲，例如釘釘、郵件、短信等方式。

監控告警架構

爲了合理地將監控壓力負擔分到多個層次的 Prometheus 並實現全局聚合，咱們使用了聯邦 Federation 的功能。在聯邦集羣中，每一個數據中心部署單獨的 Prometheus，用於採集當前數據中心監控數據，並由一箇中心的 Prometheus 負責聚合多個數據中心的監控數據。

基於 Federation 的功能，咱們設計的全球監控架構圖以下，包括監控體系、告警體系和展現體系三部分。

監控體系按照從元集羣監控向中心監控匯聚的角度，呈現爲樹形結構，能夠分爲三層：

1. 邊緣 Prometheus

爲了有效監控元集羣 Kubernetes 和用戶集羣 Kubernetes 的指標、避免網絡配置的複雜性，將 Prometheus 下沉到每一個元集羣內。

1. 級聯 Prometheus

級聯 Prometheus 的做用在於匯聚多個區域的監控數據。級聯 Prometheus 存在於每一個大區域，例如中國區、歐洲區、美洲區、亞洲區。每一個大區域內包含若干個具體的區域，例如北京、上海、東京等。隨着每一個大區域內集羣規模的增加，大區域能夠拆分紅多個新的大區域，並始終維持每一個大區域內有一個級聯 Prometheus，經過這種策略能夠實現靈活的架構擴展和演進。

1. 中心 Prometheus

中心 Prometheus 用於鏈接全部的級聯 Prometheus，實現最終的數據聚合、全局視圖和告警。爲提升可靠性，中心 Prometheus 使用雙活架構，也就是在不一樣可用區佈置兩個 Prometheus 中心節點，都鏈接相同的下一級 Prometheus。

優化策略

1.監控數據流量與 API server 流量分離

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

經常使用的透傳 Kubernetes 集羣內 Prometheus 指標到集羣外的方式是經過 API server 代理功能，優勢是能夠重用 API server 的 6443 端口對外開放數據，管理簡便；缺點也明顯，增長了 API server 的負載壓力。

若是使用 API Server 代理模式，考慮到客戶集羣以及節點都會隨着售賣而不斷擴大，對 API server 的壓力也愈來愈大並增長了潛在的風險。對此，針對邊緣 Prometheus 增長了 LoadBalancer 類型的 service，監控流量徹底 LoadBalancer，實現流量分離。即使監控的對象持續增長，也保證了 API server 不會所以增長 Proxy 功能的開銷。

2.收集指定 Metric

在中心 Prometheus 只收集須要使用的指標，必定不能全量抓取，不然會形成網絡傳輸壓力過大丟失數據。

3.Label 管理

Label 用於在級聯 Prometheus 上標記 region 和元集羣，因此在中心 Prometheus 匯聚是能夠定位到元集羣的顆粒度。同時，儘可能減小沒必要要的 label，實現數據節省。

3.支持柔性架構的可插拔、可定製、積木式的持續演進能力

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

咱們必需要考慮 Kubernetes 版本的持續迭代和 CVE 漏洞的修復，必需要考慮 Kubernetes 相關組件的持續更新，不管是 CSI、CNI、Device Plugin 仍是 Scheduler Plugin 等等。爲此咱們提供了完整的集羣和組件的持續升級、灰度、暫停等功能。

組件可插拔

組件檢查

組件升級

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

集羣模板

此外，考慮不一樣 Kubernetes 使用場景，咱們提供了多種 Kubernetes 的 cluster profile，能夠方便用戶進行更方便的集羣選擇。咱們會結合大量集羣的實踐，持續提供更多更好的集羣模板。

總結

隨着雲計算的發展,以 Kubernetes 爲基礎的雲原生技術持續推進行業進行數字化轉型。

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

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

有興趣的開發者，能夠前往阿里雲控制檯，建立一個 Kubernetes 集羣來體驗。同時也歡迎容器生態的合做夥伴加入阿里雲的容器應用市場，和咱們一塊兒共創雲原生時代。

---

本文做者： 湯志敏

原文連接

本文爲阿里雲內容，未經容許不得轉載。