作者 | 譚霖

本文介紹了美團在如何解決大規模集群管理的難題、設計優秀且合理的集群調度系統方面的實踐，闡述了美團在落地以Kubernetes為代表的云原生技術時，比較關心的問題、挑戰以及對應的推進策略。同時本文也介紹了針對美團業務需求場景做的一些特色支持，希望本文能夠對云原生領域感興趣的同學有所幫助或者啟發。

• 導語
• 集群調度系統介紹
• 大規模集群管理的難題
• 運營大規模集群的挑戰
• 設計集群調度系統時的取舍
• 美團集群調度系統演變之路
• 多集群統一調度：提升數據中心資源利用率
• 調度引擎服務：賦能PaaS服務云原生落地
• 未來展望：構建云原生操作系統

導語

集群調度系統在企業數據中心中占有舉足輕重的地位，隨著集群規模與應用數量的不斷激增，開發者處理業務問題的復雜度也顯著提升。如何解決大規模集群管理的難題，設計優秀且合理的集群調度系統，做到保穩定，降成本，提效率？本文將會逐一進行解答。| 備注：文章最早發布于《新程序員003》云原生時代的開發者專欄。

集群調度系統介紹

集群調度系統，又被稱為數據中心資源調度系統，普遍用來解決數據中心的資源管理和任務調度問題，它的目標是做到數據中心資源的有效利用，提升資源的利用率，并為業務方提供自動化的運維能力，降低服務的運維管理成本。工業界比較知名的集群調度系統，如開源的OpenStack、YARN、Mesos和Kubernetes等等，再如知名互聯網公司Google的Borg、微軟的Apollo、百度的Matrix、阿里巴巴的Fuxi和ASI。集群調度系統作為各互聯網公司核心的IaaS基礎設施，在近十幾年經歷了多次架構演進。伴隨著業務從單體架構向SOA（面向服務的架構）演進和微服務的發展，底層的IaaS設施也從物理機裸機時代逐步跨越到容器時代。雖然在演進過程中我們要處理的核心問題沒有改變，但由于集群規模和應用數量的急劇膨脹，問題的復雜度也成指數級增長。本文將闡述大規模集群管理的挑戰和集群調度系統的設計思路，并以美團集群調度系統落地實踐為例，講述通過打造多集群統一調度服務，持續提升資源的利用率，提供Kubernetes引擎服務賦能PaaS組件，為業務提供更好的計算服務體驗等一系列云原生實踐。

大規模集群管理的難題

眾所周知，業務快速增長帶來的是服務器規模和數據中心數量的暴增。對于開發者而言，在大規模集群調度系統的業務場景下，必須要解決的兩個難題是：

1. 如何管理好數據中心大規模集群部署調度，特別是在跨數據中心場景下，如何實現資源的彈性和調度能力，在保障應用服務質量的前提下盡可能地提升資源的利用率，充分降低數據中心成本。
2. 如何改造底層基礎設施，為業務方打造云原生操作系統，提升計算服務體驗，實現應用的自動化容災響應和部署升級等，減少業務方對底層資源管理的心智負擔，讓業務方可以更專注于業務本身。

運營大規模集群的挑戰

為了在真實的生產環境解決上述兩個難題，具體又可以再拆分成以下四個大規模集群運營管理挑戰：

1. 如何解決用戶多樣化需求并快速響應。業務的調度需求和場景豐富且動態多變，作為集群調度系統這樣的平臺型服務，一方面需要能夠快速交付功能，及時滿足業務需求；另一方面還需要把平臺打造得足夠通用，將業務個性化需求抽象為可落地到平臺的通用能力，并長期進行迭代。這非常考驗平臺服務團隊的技術演進規劃，因為一不小心，團隊就會陷入無休止的業務功能開發中，雖然滿足了業務需求，卻會造成團隊工作低水平重復的現象。
2. 如何提高在線應用數據中心的資源利用率且同時保障應用服務質量。資源調度一直是業界公認的難題，隨著云計算市場快速發展，各云計算廠商不斷加大對數據中心的投入。數據中心的資源使用率卻非常低，更加劇了問題的嚴重性。Gartner調研發現全球數據中心服務器CPU利用率只有6%～12%，即使是亞馬遜彈性計算云平臺（EC2，Elastic Compute Cloud）也只有7%～17%的資源利用率，可見資源浪費有多嚴重。究其原因，在線應用對于資源利用率非常敏感，業界不得不預留額外資源以保障重要應用的服務質量（QoS，Qualityof Service）。集群調度系統需要在多應用混合運行時消除應用間的干擾，實現不同應用之間的資源隔離。
3. 如何為應用，特別是有狀態應用提供實例異常自動處理，屏蔽機房差異，降低用戶對底層的感知。隨著服務應用規模的持續擴大，以及云計算市場的日趨成熟，分布式應用往往會配置在不同地域的數據中心，甚至是跨越不同的云環境，實現了多云或混合云部署。而集群調度系統需要為業務方提供統一的基礎設施，實現混合多云架構，屏蔽底層的異構環境。同時降低應用運維管理的復雜性，提升應用的自動化程度，為業務提供更好的運維體驗。
4. 如何解決單集群過大或集群數量過多，而帶來的與集群管理相關的性能和穩定性風險。集群本身的生命周期管理復雜度會伴隨集群規模和數量的增多而增大。以美團為例，我們所采取的兩地多中心多集群方案，雖然在一定程度上規避了集群規模過大的隱患，解決了業務隔離性、地域延遲等問題。隨著邊緣集群場景和數據庫等PaaS組件上云需求的出現，可以預見小集群數量將會有明顯的上漲趨勢。隨之帶來的是集群管理復雜度、監控配置成本、運維成本的明顯增加，這時集群調度系統需要提供更有效的操作規范，并保證操作安全性、報警自愈和變更效率。

設計集群調度系統時的取舍

為了解決上述挑戰，一個好的集群調度器將發揮關鍵作用。但現實中從來不存在一個完美的系統，所以在設計集群調度系統時，我們需要根據實際場景在幾個矛盾中做出取舍：

1. 集群調度系統的系統吞吐量和調度質量。系統吞吐量是我們通常評估一個系統好壞很重要的標準，但在面向在線服務的集群調度系統里更重要的是調度質量。因為每次調度結果的影響是長期的（數天、數周甚至數月），非異常情況不會調整。所以如果調度結果錯誤，會直接導致服務時延增高。而調度質量越高則意味著需要考慮的計算約束條件越多，而且調度性能越差的話，系統吞吐量越低。
2. 集群調度系統的架構復雜度和可擴展性。系統對上層PaaS用戶開放的功能和配置越多，通過支持更多功能來提升用戶體驗（比如支持應用資源搶占回收和應用實例異常自愈），也就意味著系統復雜度越高，各子系統越容易發生沖突。
3. 集群調度系統的可靠性和單集群規模。單集群規模越大，則可調度范圍則越大，但對集群的可靠性挑戰也越大，因為爆炸半徑會增加，出現故障的影響也越大。單集群規模較小的情況下，雖然可以提升調度并發度，但可調度范圍變小，調度失敗概率變高，且集群管理復雜度變大。

目前，業內的集群調度系統按照架構區分，可以分為單體式調度器、兩級調度器、共享狀態調度器、分布式調度器和混合調度器這五種不同架構（見下圖1），都是根據各自的場景需求做了不同的選擇，沒有絕對的好與壞。

圖1 集群調度系統架構分類（摘自Malte Schwarzkopf - The evolution of cluster scheduler architectures）

• 單體式調度器使用復雜的調度算法結合集群的全局信息，計算出高質量的放置點，不過延遲較高。如Google的Borg系統、開源的Kubernetes系統。
• 兩級調度器通過將資源調度和作業調度分離，解決單體式調度器的局限性。兩級調度器允許根據特定的應用做不同的作業調度邏輯，且同時保持了不同作業之間共享集群資源的特性，可是無法實現高優先級應用的搶占。具有代表性的系統是Apache Mesos和Hadoop YARN。
• 共享狀態調度器通過半分布式的方式來解決兩級調度器的局限性，共享狀態下的每個調度器都擁有一份集群狀態的副本，且調度器獨立對集群狀態副本進行更新。一旦本地的狀態副本發生變化，整個集群的狀態信息就會被更新，但持續資源爭搶會導致調度器性能下降。具有代表性的系統是Google的Omega和微軟的Apollo。
• 分布式調度器使用較為簡單的調度算法以實現針對大規模的高吞吐、低延遲并行任務放置，但由于調度算法較為簡單并缺乏全局的資源使用視角，很難達到高質量的作業放置效果，代表性系統如加州大學的Sparrow。
• 混合調度器將工作負載分散到集中式和分布式組件上，對長時間運行的任務使用復雜算法，對短時間運行的任務則依賴于分布式布局。微軟Mercury就采取了這種這種方案。

所以，如何評價一個調度系統的好壞，主要取決于實際的調度場景。以業內使用最廣泛的YARN和Kubernetes為例，雖然兩個系統都是通用資源調度器，實際上YARN專注于離線批處理短任務，Kubernetes專注于在線長時間運行的服務。除了架構設計和功能的不同（Kubernetes是單體式調度器，YARN是兩級調度器），二者的設計理念和視角也不同。YARN更專注任務，關注資源復用，避免遠程數據多次拷貝，目標是以更低成本、更高速度執行任務。Kubernetes更專注服務狀態，關注錯峰、服務畫像、資源隔離，目標是保障服務質量。

美團集群調度系統演變之路

美團在落地容器化的過程中，根據業務場景需求，集群調度系統核心引擎由OpenStack轉變為Kubernetes，并在2019年底完成了在線業務容器化覆蓋率超過了98%的既定目標。但依然面臨資源利用率低、運維成本高等問題：

• 集群整體的資源利用率不高。如CPU資源平均利用率還處于業內平均水平，相較于其他一線互聯網公司差距較大。
• 有狀態服務的容器化率程度不夠，特別是MySQL、Elasticsearch等產品沒有使用容器，業務運維成本和資源成本存在較大的優化空間。
• 從業務需求考慮，VM產品會長期存在，VM調度和容器調度是兩套環境，導致團隊虛擬化產品運維成本較高。

因此，我們決定開始對集群調度系統進行云原生改造。打造一個具有多集群管理和自動化運維能力、支持調度策略推薦和自助配置、提供云原生底層擴展能力，并在保障應用服務質量的前提下提升資源使用率的大規模高可用調度系統。核心工作圍繞保穩定、降成本、提效率三大方向來構建調度系統。

• 保穩定：提升調度系統的健壯性、可觀測性；降低系統各模塊之間的耦合，減少復雜度；提升多集群管理平臺的自動化運維能力；優化系統核心組件性能；確保大規模集群的可用性。
• 降成本：深度優化調度模型，打通集群調度和單機調度鏈路。從資源靜態調度轉向資源動態調度，引入離線業務容器，形成自由競爭與強控結合，在保障高優業務應用服務質量的前提下，提升資源使用率，降低IT成本。
• 提效率：支持用戶自助調整調度策略，滿足業務個性化需求，積極擁抱云原生領域，為PaaS組件提供包括編排、調度、跨集群、高可用等核心能力，提升運維效率。

圖2 美團集群調度系統架構圖

最終，美團集群調度系統架構按照領域劃分為三層（見上圖2），調度平臺層、調度策略層、調度引擎層：

• 平臺層負責業務接入，打通美團基礎設施，封裝原生接口和邏輯，提供容器管理接口（擴容、更新、重啟、縮容）等功能。
• 策略層提供多集群統一調度能力，持續優化調度算法和策略，結合業務的服務等級和敏感資源等信息，通過服務分級提升CPU使用率和分配率。
• 引擎層提供Kubernetes服務，保障多個PaaS組件的云原生集群穩定性，并把通用能力下沉到編排引擎，降低業務云原生落地的接入成本。

通過精細化運營和產品功能打磨，我們一方面統一納管了美團近百萬的容器/虛擬機實例，另一方面將資源利用率從業內平均水平提升到了一流水平，同時還支撐了PaaS組件的容器化和云原生落地。

多集群統一調度：提升數據中心資源利用率

評估考核集群調度系統的好壞，資源利用率是最重要的指標之一。因此，雖然我們在2019年完成了容器化，不過容器化不是目的，只是手段。我們的目標是通過從VM技術棧切換到容器技術棧，為用戶帶來更多的收益，比如全面降低用戶的計算成本。而提升資源利用率受限于集群的個別熱點宿主，一旦擴容，業務容器就有可能擴容到熱點宿主，業務的性能指標如TP95耗時會出現波動，以至于我們只能像業界其他公司一樣，通過增加資源冗余來保障服務質量。究其原因，Kubernetes調度引擎的分配方式僅簡單考慮了Request/Limit Quota（Kubernetes為容器設定了請求值Request和約束值Limit，作為用戶申請容器的資源配額），屬于靜態資源分配。導致不同宿主機雖然分配了同樣多的資源，卻因宿主機的服務差異性使得宿主機的資源利用率也存在較大的差異。在學術界和工業界中，有兩種常用的方法解決資源使用效率和應用服務質量之間的矛盾。第一種方法是通過高效的任務調度器在全局角度解決；第二種方法是通過單機資源管理手段來加強應用之間的資源隔離。不管是哪一種方法，都意味著我們需要全面掌握集群狀態，所以我們做了三件事：

• 系統地建立了集群狀態、宿主狀態、服務狀態的關聯，并結合調度仿真平臺，綜合考慮了峰值利用率和平均利用率，實現了基于宿主歷史負載和業務實時負載的預測和調度。
• 通過自研的動態負載調節系統和跨集群重調度系統，實現了集群調度和單機調度鏈路的聯動，根據業務分級實現了不同資源池的服務質量保障策略。
• 經過三版迭代，實現了自有集群聯邦服務，較好地解決了資源預占和狀態數據同步問題，提升了集群間的調度并發度，實現了計算分離、集群映射、負載均衡和跨集群編排控制（見下圖3）。

圖3 集群聯邦V3版本架構

集群聯邦服務第三版本按照模塊拆分為Proxy層和Worker層，獨立部署：

• Proxy層會綜合集群狀態的因子及權重選擇合適的集群進行調度，并選擇合適的Worker分發請求。Proxy模塊使用etcd做服務注冊、選主和發現，Leader節點負責調度時預占任務，所有節點都能負責查詢任務。
• Worker層對應處理一部分Cluster的查詢請求，當某集群任務阻塞，可以快速擴容一臺對應的Worker實例緩解問題。當單集群規模較大時會對應多個Worker實例，Proxy將調度請求分發給多個Worker實例處理，提升調度并發度，并減少每一個Worker的負載。

最終通過多集群統一調度，我們實現了從靜態資源調度模型轉向動態資源調度模型，從而降低了熱點宿主比例，減少了資源碎片比例，保障了高優業務應用的服務質量，將在線業務集群的服務器CPU利用率均值提升了10個百分點。集群資源利用率均值計算方式：Sum(nodeA.cpu.當前使用核數 + nodeB.cpu.當前使用核數 + xxx) / Sum(nodeA.cpu.總核數 + nodeB.cpu.總核數 + xxx），一分鐘一個點，當天所有值取平均。

調度引擎服務：賦能PaaS服務云原生落地

集群調度系統除了解決資源調度的問題之外，還解決服務使用計算資源的問題。正如《Software Engineering at Google》一書中提到的，集群調度系統作為Compute as a Service中關鍵組件之一，既要解決資源調度（從物理機拆解到CPU/Mem這樣的資源維度）和資源競爭（解決“吵鬧鄰居”），還需要解決應用管理（實例自動化部署、環境監控、異常處理、保障服務實例數、確定業務需求資源量、不同服務種類等）。而且從某種程度上來說應用管理比資源調度更重要，因為這會直接影響業務的開發運維效率和服務容災效果，畢竟互聯網的人力成本比機器成本更高。復雜的有狀態應用的容器化一直是業界難題，因為這些不同場景下的分布式系統中通常維護了自己的狀態機。當應用系統發生擴縮容或升級時，如何保證當前已有實例服務的可用性，以及如何保證它們之間的可連通性，是相較無狀態應用復雜許多的棘手問題。雖然我們已經把無狀態服務都容器化了，但我們還沒有充分發揮出一個良好的集群調度系統的全部價值。如果要想管好計算資源，必須管理好服務的狀態，做到資源和服務分離，提升服務韌性，而這也是Kubernetes引擎所擅長的。我們基于美團優化定制的Kubernetes版本，打造了美團Kubernetes引擎服務MKE：

• 加強集群運維能力，完善了集群的自動化運維能力建設，包括集群自愈、報警體系、Event日志分析等，持續提升集群的可觀測性。
• 豎立重點業務標桿，與幾個重要的PaaS組件深入合作，針對用戶的痛點如Sidecar升級管理、Operator灰度迭代、報警分離做快速優化，滿足用戶的訴求。
• 持續改進產品體驗，持續優化Kubernetes引擎，除了支持用戶使用自定義Operator之外，也提供了通用的調度和編排框架（見圖4），幫助用戶以更低的成本接入MKE，獲得技術紅利。

圖4 美團Kubernetes引擎服務調度和編排框架

在我們推進云原生落地過程中，一個廣泛被關注的問題是：基于Kubernetes云原生方式來管理有狀態應用，相比于之前自己打造管理平臺有什么區別？對于這個問題，需要從問題根源——可運維性考慮：

• 基于Kubernetes意味著系統做到了閉環，不用擔心兩套系統經常出現的數據不一致問題。
• 異常響應可以做到毫秒級別，降低了系統的RTO（Recovery Time Objective，即恢復時間目標，主要指所能容忍的業務停止服務的最長時間，也是從災難發生到業務系統恢復服務功能所需要的最短時間周期）。
• 系統運維復雜度也降低了，服務做到了自動化容災。除了服務本身之外，服務依賴的配置和狀態數據都可以一起恢復。
• 相比于之前各個PaaS組件“煙囪式”的管理平臺，通用能力可以下沉到引擎服務，減少開發維護成本，而通過依托于引擎服務，可以屏蔽底層異構環境，實現跨數據中心和多云環境的服務管理。

未來展望：構建云原生操作系統

我們認為，云原生時代的集群管理，會從之前的管理硬件、資源等職能全面轉變為以應用為中心的云原生操作系統。以此為目標，美團集群調度系統還需從以下幾方面發力：

• 應用鏈路交付管理。隨著業務規模和鏈路復雜度的增大，業務所依賴的PaaS組件和底層基礎設施的運維復雜度早已超過普遍認知，對于剛接手項目的新人更是難上加難。所以我們需要支持業務通過聲明式配置交付服務并實現自運維，給業務提供更好的運維體驗，提升應用的可用性和可觀測性，減少業務對底層資源管理的負擔。
• 邊緣計算解決方案。隨著美團業務場景的不斷豐富，業務對邊緣計算節點的需求增長，比預期快很多。我們會參考業內最佳實踐，形成適合在美團落地的邊緣解決方案，盡快為有需求的服務提供邊緣計算節點管理能力，實現云邊端協同。
• 在離線混部能力建設。在線業務集群的資源利用率提升是有上限的，根據Google在論文《Borg: the Next Generation》中披露的2019年數據中心集群數據，刨去離線任務，在線任務的資源利用率僅為30%左右，這也說明了再往上提升風險較大，投入產出比不高。后續，美團集群調度系統將持續探索在離線混部，不過由于美團的離線機房相對獨立，我們的實施路徑會與業界的普遍方案有所不同，會先從在線服務和近實時任務的混部開始，完成底層能力的構建，再探索在線任務和離線任務的混部。

總結

美團集群調度系統在設計時，整體遵循合適原則，在滿足業務基本需求的情況下，保證系統穩定后再逐步完善架構，提升性能和豐富功能。因此，我們選擇了：

• 在系統吞吐量和調度質量中我們選擇優先滿足業務對系統的吞吐量需求，不過度追求單次調度質量，而是通過重調度調整完善。
• 在架構復雜度和可擴展性中我們選擇降低系統各模塊之間的耦合，減少系統復雜度，擴展功能必需可降級。
• 在可靠性和單集群規模中我們選擇通過多集群統一調度來控制單集群規模，保障系統可靠性，減少爆炸半徑。

未來，我們也會根據同樣的邏輯持續優化迭代美團的集群調度系統，徹底轉變為以應用為中心的云原生操作系統。

作者簡介

譚霖，來自美團基礎研發平臺/基礎技術部。