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

阿里云上萬個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.支持單元化的分檔管理、容量規劃和水位管理

單元化

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

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

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

分檔化

大家都知道，Kubernetes集群的master組件的負載主要與Kubernetes集群的節點規模、worker側的controller或workload等需要與kubeapiserver交互的組件數量和調用頻率息息相關，對于上萬個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作為方案的基礎。

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

OS指標，例如節點資源（CPU,內存，磁盤等）水位以及網絡吞吐；

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

Kubernetes組件（kubernetesstatemetrics，cadvisor）采集的關于Kubernetes集群狀態；

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

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

監控告警架構

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

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

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

邊緣Prometheus

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

級聯Prometheus

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

中心Prometheus

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

圖2基于Prometheus Federation的全球多級別監控架構

優化策略

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

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

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

常用的透傳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集群來體驗。同時也歡迎容器生態的合作伙伴加入阿里云的容器應用市場，和我們一起共創云原生時代。

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