Categories
程式開發

阿里雲上萬個 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

背景介紹

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

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

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

  2. 集群大小不一:每個集群規模大小不一,從幾個節點到上萬個節點,從幾個 service 到幾千個 service 等,需要能夠支撐每年持續幾倍集群數量的增長;

  3. 集群安全合規:分佈在不同的地域和環境的 Kubernetes 集群,需要遵循不同的合規性要求。比如歐洲的 Kubernetes 集群需要遵循歐盟的 GDPR 法案,在中國的金融業和政務雲需要有額外的等級保護等要求;

  4. 集群持續演進:需要能夠持續的支持 Kubernetes 的新版本新特性演進。

設計目標:

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

  • 支持全球化的部署、發布、容災和可觀測性;

  • 支持柔性架構的可插拔、可定制、積木式的持續演進能力。

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 集群大規模管理實踐 3

容量規劃

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

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

  • 接下來,我們需要結合 VPC 內的 ip 資源,做網段的規劃,分別提供給 node、pod 和 service。

  • 最後,我們會結合統計規律,結合成本、密度、性能、資源配額、檔位配比等多種因素的綜合考量,設計每個元集群單元中部署的不同檔位的guest Kubernetes 的個數,並預留40% 的水位。

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

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

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

容器服務已經在全球 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。

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

基於 Prometheus Federation 的全球多級別監控架構

優化策略

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

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

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

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

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

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

  1. 收集指定 Metric

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

  1. Label 管理

Label 用於在級聯 Prometheus 上標記 region 和元集群,所以在中心 Prometheus 匯聚是可以定位到元集群的顆粒度。同時,盡量減少不必要的 label,實現數據節省。

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

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

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

組件可插拔

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

組件檢查

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

組件升級

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

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

集群模板

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

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

總結

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

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

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

有興趣的開發者,可以前往阿里雲控制台,創建一個 Kubernetes 集群來體驗。

本文選自《不一樣的雙11,阿里巴巴經濟體雲原生實踐》電子書,點擊下載