內容簡介：
阿里雲容器服務從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集羣的痛點：
- 集羣種類不同：有標準的、無服務器的、AI的、裸金屬的、邊緣、Windows等k8s集羣。不同種類的集羣參數、組件和託管要求不一樣，並且需要支撐更多面向垂直場景的k8s。
- 集羣大小不一：每個集羣規模大小不一，從幾個節點到上萬個節點，從幾個service到幾千個service等。需要能夠支撐每年持續幾倍集羣數量的增長。
- 集羣安全合規：分佈在不同的地域和環境的k8s集羣，需要遵循不同的合規性要求。比如歐洲的k8s集羣需要遵循歐盟的GDPR法案，在中國的金融業和政務雲需要有額外的等級保護等要求。
- 集羣持續演進：需要能夠持續的支持k8s的新版本新特性演進。。
設計目標：
1.支持單元化的分檔管理、容量規劃和水位管理
2.支持全球化的部署、發佈、容災和可觀測性
3.支持柔性架構的可插拔、可定製、積木式的持續演進能力
1.支持單元化的分檔管理、容量規劃和水位管理
單元化：
一般講到單元化，大家都會聯想到單機房容量不夠或二地三中心災備等場景。那單元化和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%的水位。
2.支持全球化的部署、發佈、容災和可觀測性
容器服務已經在全球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的功能，我們設計的全球監控架構圖如下，包括監控體系、告警體系和展示體系三部分。
監控體系按照從元集羣監控向中心監控匯聚的角度，呈現爲樹形結構，可以分爲三層：
1. 邊緣Prometheus
爲了有效監控元集羣K8s和用戶集羣K8s的指標、避免網絡配置的複雜性，將Prometheus下沉到每個元集羣內，
2. 級聯Prometheus
級聯Prometheus的作用在於匯聚多個區域的監控數據。級聯Prometheus存在於每個大區域，例如中國區，歐洲美洲區，亞洲區。每個大區域內包含若干個具體的區域，例如北京，上海，東京等。隨着每個大區域內集羣規模的增長，大區域可以拆分成多個新的大區域，並始終維持每個大區域內有一個級聯Prometheus，通過這種策略可以實現靈活的架構擴展和演進。
3. 中心Prometheus
中心Prometheus用於連接所有的級聯Prometheus，實現最終的數據聚合、全局視圖和告警。爲提高可靠性，中心Prometheus使用雙活架構，也就是在不同可用區佈置兩個Prometheus中心節點，都連接相同的下一級Prometheus。
優化策略
- 監控數據流量與API server流量分離
API server的代理功能可以使得K8s集羣外通過API server訪問集羣內的Pod、Node或者Service。
常用的透傳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，實現數據節省。
3.支持柔性架構的可插拔、可定製、積木式的持續演進能力
前面兩部分簡要描述瞭如何管理海量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 集羣來體驗。對於容器生態的合作伙伴，也歡迎加入阿里雲的容器應用市場，和我們一起共創雲原生時代。
本文轉載自雲棲社區。
原文鏈接：
https://yq.aliyun.com/articles/732358?spm=a2c4e.11153959.0.0.715cd55arelKky