内容簡介：
阿裡雲容器服務從2015年上線後，一路伴随并支撐雙十一發展。在2019年的雙十一中，容器服務ACK除了支撐集團内部核心系統容器化上雲和阿裡雲的雲産品本身，也将阿裡多年的大規模容器技術以産品化的能力輸出給衆多圍繞雙十一的生态公司和ISV公司。通過支撐來自全球各行各業的容器雲，容器服務已經沉澱了支援單元化架構、全球化架構、柔性架構的雲原生應用托管中台能力，管理了超過1W個以上的容器叢集。本文會介紹下容器服務ACK在海量k8s叢集管理上的實踐經驗。
引言
什麼是海量k8s叢集管理。大家可能之前看過一些分享，介紹了阿裡巴巴或螞蟻金服内部如何管理單叢集1W節點的最佳實踐，管理大規模的節點是一個很有意思的挑戰。不過這裡講的海量k8s叢集管理，會側重講如何管理超過1W個以上不同規格的k8s叢集。跟據我們和一些同行的溝通，往往一個企業内部隻要管理幾個到幾十個k8s叢集，那麼我們為什麼需要考慮管理如此龐大數量的k8s叢集？首先，容器服務ACK是阿裡雲上的雲産品，提供了Kubernetes as a Service的能力，面向全球客戶，目前已經在全球20個地域支援。其次，得益于雲原生時代的發展，越來越多的企業擁抱k8s，K8s已經逐漸成為雲原生時代的基礎設施，成為platform of platform。
背景介紹
首先我們一起來看下托管這些k8s叢集的痛點：
1.叢集種類不同：有标準的、無伺服器的、AI的、裸金屬的、邊緣、Windows等k8s叢集。不同種類的叢集參數、元件和托管要求不一樣，并且需要支撐更多面向垂直場景的k8s。
2.叢集大小不一：每個叢集規模大小不一，從幾個節點到上萬個節點，從幾個service到幾千個service等。需要能夠支撐每年持續幾倍叢集數量的增長。
3.叢集安全合規：分布在不同的地域和環境的k8s叢集，需要遵循不同的合規性要求。比如歐洲的k8s叢集需要遵循歐盟的GDPR法案，在中國的金融業和政務雲需要有額外的等級保護等要求。
4.叢集持續演進：需要能夠持續的支援k8s的新版本新特性演進。。
設計目标：
1.支援單元化的分檔管理、容量規劃和水位管理
2.支援全球化的部署、釋出、容災和可觀測性
3.支援柔性架構的可插拔、可定制、積木式的持續演進能力
單元化：
一般講到單元化，大家都會聯想到單機房容量不夠或二地三中心災備等場景。那單元化和k8s管理有什麼關系？對我們來說，一個地域（比如杭州）可能會管理幾千個k8s，需要統一維護這些k8s的叢集生命周期管理。作為一個k8s專業團隊，一個樸素的想法就是通過多個k8s元叢集來管理這些guest K8s master。而一個k8s元叢集的邊界就是一個單元。
曾經我們經常聽說某某機房光纖被挖斷，某某機房電力故障而導緻服務中斷，容器服務ACK在設計之初就支援了同城多活的架構形态，任何一個使用者k8s叢集的master元件都會自動地分散在多個機房，采用主主模式運作，不會因單機房問題而影響叢集穩定性；另外一個層面，同時要保證master元件間的通信穩定性，容器服務ACK在打散master時排程政策上也會盡量保證master元件間通信延遲在毫秒級。
分檔化：
大家都知道，k8s叢集的master元件的負載主要與k8s叢集的節點規模、worker側的controller或workload等需要與kube-apiserver互動的元件數量和調用頻率息息相關，對于上萬個k8s叢集，每個使用者k8s叢集的規模和業務形态都千差萬别，我們無法用一套标準配置來去管理所有的使用者k8s叢集，同時從成本經濟角度考慮，我們提供了一種更加靈活、更加智能的托管能力。考慮到不同資源類型會對master産生不同的負載壓力，是以我們需要為每類資源設定不同的因子，最終可歸納出一個計算範式，通過此範式可計算出每個使用者k8s叢集master所适應的檔位；同時我們也會基于已建構的k8s統一監控平台實時名額來不斷地優化和調整這些因素值和範式，進而可實作智能平滑換擋的能力。
容量規劃： 接下來我們看下k8s元叢集的容量模型，單個元叢集到底能托管多少個使用者k8s叢集的master? 首先要确認容器網絡規劃。這裡我們選擇了阿裡雲自研的高性能容器網絡Terway, 一方面需要通過彈性網卡ENI打通使用者VPC和托管master的網絡，另一方面提供了高性能和豐富的安全政策。接下來我們需要結合VPC内的ip資源，做網段的規劃，分别提供給node、pod和service。最後，我們會結合統計規律，結合成本、密度、性能、資源配額、檔位配比等多種因素的綜合考量，設計每個元叢集單元中部署的不同檔位的guest k8s的個數，并預留40%的水位。
容器服務已經在全球20個地域支援，我們提供了完全自動化的部署、釋出、容災和可觀測性能力。這裡重點介紹下全球化跨資料中心的可觀測。
全球跨資料中心的可觀測性
全球化布局的大型叢集的可觀測性，對于k8s叢集的日常保障至關重要。如何在紛繁複雜的網絡環境下高效、合理、安全、可擴充的采集各個資料中心中目标叢集的實時狀态名額，是可觀測性設計的關鍵與核心。我們需要兼顧區域化資料中心、單元化叢集範圍内可觀測性資料的收集，以及全局視圖的可觀測性和可視化。基于這種設計理念和客觀需求，全球化可觀測性必須使用多級聯合方式，也就是邊緣層的可觀測性實作下沉到需要觀測的叢集内部，中間層的可觀測性用于在若幹區域内實作監控資料的彙聚，中心層可觀測性進行彙聚、形成全局化視圖以及告警。樣設計的好處在于可以靈活的在每一級别層内進行擴充以及調整，适合于不斷增長的叢集規模，相應的其他級别隻需調整參數，層次結構清晰；網絡結構簡單，可以實作内網資料穿透到公網并彙聚。
針對該全球化布局的大型叢集的監控系統設計，對于保障叢集的高效運轉至關重要，我們的設計理念是在全球範圍内将各個資料中心的資料實時收集并聚合，實作全局視圖檢視和資料可視化，以及故障定位、告警通知。進入雲原生時代，Prometheus作為CNCF中第二個畢業的項目，天生适用于容器場景，Prometheus 與 Kubernetes 結合一起，實作服務發現和對動态排程服務的監控，在各種監控方案中具有很大的優勢，實際上已經成為容器監控方案的标準，是以我們也選擇了Prometheus作為方案的基礎。
針對每個叢集，需要采集的主要名額類别包括：
- OS名額，例如節點資源（CPU, 記憶體，磁盤等）水位以及網絡吞吐；
- 元叢集以及使用者叢集K8s master名額，例如kube-apiserver, kube-controller-manager, kube-scheduler等名額；
- K8s元件（kubernetes-state-metrics，cadvisor）采集的關于K8s叢集狀态；
- etcd名額，例如etcd寫磁盤時間，DB size，Peer之間吞吐量等等。
當全局資料聚合後，AlertManager對接中心Prometheus，驅動各種不同的告警通知行為，例如釘釘、郵件、短信等方式。
監控告警架構
為了合理的将監控壓力負擔分到到多個層次的Prometheus并實作全局聚合，我們使用了聯邦Federation的功能。在聯邦叢集中，每個資料中心部署單獨的Prometheus，用于采集目前資料中心監控資料，并由一個中心的Prometheus負責聚合多個資料中心的監控資料。基于Federation的功能，我們設計的全球監控架構圖如下，包括監控體系、告警體系和展示體系三部分。
監控體系按照從元叢集監控向中心監控彙聚的角度，呈現為樹形結構，可以分為三層：
- 邊緣Prometheus
為了有效監控元叢集K8s和使用者叢集K8s的名額、避免網絡配置的複雜性，将Prometheus下沉到每個元叢集内，
- 級聯Prometheus
級聯Prometheus的作用在于彙聚多個區域的監控資料。級聯Prometheus存在于每個大區域，例如中國區，歐洲美洲區，亞洲區。每個大區域内包含若幹個具體的區域，例如北京，上海，東京等。随着每個大區域内叢集規模的增長，大區域可以拆分成多個新的大區域，并始終維持每個大區域内有一個級聯Prometheus，通過這種政策可以實作靈活的架構擴充和演進。
- 中心Prometheus
中心Prometheus用于連接配接所有的級聯Prometheus，實作最終的資料聚合、全局視圖和告警。為提高可靠性，中心Prometheus使用雙活架構，也就是在不同可用區布置兩個Prometheus中心節點，都連接配接相同的下一級Prometheus。
圖2-1 基于Prometheus Federation的全球多級别監控架構
優化政策
- 監控資料流量與API server流量分離
API server的代理功能可以使得K8s叢集外通過API server通路叢集内的Pod、Node或者Service。
圖3-1 通過API Server代理模式通路K8s叢集内的Pod資源
常用的透傳K8s叢集内Prometheus名額到叢集外的方式是通過API server代理功能，優點是可以重用API server的6443端口對外開放資料，管理簡便；缺點也明顯，增加了API server的負載壓力。如果使用API Server代理模式，考慮到客戶叢集以及節點都會随着售賣而不斷擴大，對API server的壓力也越來越大并增加了潛在的風險。對此，針對邊緣Prometheus增加了LoadBalancer類型的service，監控流量完全走LoadBalancer，實作流量分離。即便監控的對象持續增加，也保證了API server不會是以增加Proxy功能的開銷。
- 收集指定Metric
在中心Prometheus隻收集需要使用的名額，一定不能全量抓取，否則會造成網絡傳輸壓力過大丢失資料。
- Label管理
Label用于在級聯Prometheus上标記region和元叢集，是以在中心Prometheus彙聚是可以定位到元叢集的顆粒度。
同時，盡量減少不必要的label，實作資料節省。
前面兩部分簡要描述了如何管理海量k8s叢集的一些思考，然而光做到全球化、單元化的管理還遠遠不夠。k8s能夠成功，包含了聲明式的定義、高度活躍的社群、良好的架構抽象等因素，k8s已經成為雲原生時代的Linux。我們必須要考慮k8s版本的持續疊代和CVE漏洞的修複，必須要考慮k8s相關元件的持續更新，無論是CSI、CNI、Device Plugin還是Scheduler Plugin等等。為此我們提供了完整的叢集群組件的持續更新、灰階、暫停等功能。
2019年6月，阿裡巴巴将内部的雲原生應用自動化引擎OpenKruise開源，這裡我們重點介紹下其中的BroadcastJob功能，他非常适用于每台worker機器上的元件進行更新，或者對每台機器上的節點進行檢測。（Broadcast Job 會在叢集中每個node上面跑一個pod直至結束。類似于社群的DaemonSet, 差別在于DaemonSet始終保持一個pod長服務在每個node上跑，而BroadcastJob中最終這個pod會結束。）
此外，考慮不同k8s使用場景，我們提供了多種k8s的cluster profile，可以幫助使用者提供更友善的叢集選擇。我們會結合大量叢集的實踐，持續提供更多更好的叢集模闆。
總結
随着雲計算的發展,以Kubernetes為基礎的雲原生技術持續推動行業進行數字化轉型。容器服務ACK提供了安全穩定、高性能的Kubernetes托管服務已經成為雲上運作Kubernetes的最佳載體。在本次雙11，容器服務 ACK 在各個場景為雙十一作出貢獻，支撐了阿裡巴巴内部核心系統容器化上雲，支撐了阿裡雲微服務引擎MSE、視訊雲、CDN等雲産品，也支撐了雙11 的生态公司和 ISV 公司，包括聚石塔電商雲、菜鳥物流雲、東南亞的支付系統等等。容器服務ACK會持續前行，持續提供更高更好的雲原生容器網絡、存儲、排程和彈性能力，端到端的全鍊路安全能力，serverless 和 servicemesh 等能力。對于有興趣的開發者，可以前往阿裡雲控制台
https://cn.aliyun.com/product/kubernetes，建立一個 Kubernetes 叢集來體驗。對于容器生态的合作夥伴，也歡迎加入阿裡雲的容器應用市場，和我們一起共創雲原生時代。