作者 | 譚霖

本文介紹了美團(tuán)在如何解決大規(guī)模集群管理的難題、設(shè)計(jì)優(yōu)秀且合理的集群調(diào)度系統(tǒng)方面的實(shí)踐，闡述了美團(tuán)在落地以Kubernetes為代表的云原生技術(shù)時(shí)，比較關(guān)心的問題、挑戰(zhàn)以及對應(yīng)的推進(jìn)策略。同時(shí)本文也介紹了針對美團(tuán)業(yè)務(wù)需求場景做的一些特色支持，希望本文能夠?qū)υ圃I(lǐng)域感興趣的同學(xué)有所幫助或者啟發(fā)。

• 導(dǎo)語
• 集群調(diào)度系統(tǒng)介紹
• 大規(guī)模集群管理的難題
• 運(yùn)營大規(guī)模集群的挑戰(zhàn)
• 設(shè)計(jì)集群調(diào)度系統(tǒng)時(shí)的取舍
• 美團(tuán)集群調(diào)度系統(tǒng)演變之路
• 多集群統(tǒng)一調(diào)度：提升數(shù)據(jù)中心資源利用率
• 調(diào)度引擎服務(wù)：賦能PaaS服務(wù)云原生落地
• 未來展望：構(gòu)建云原生操作系統(tǒng)

導(dǎo)語

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

集群調(diào)度系統(tǒng)介紹

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

大規(guī)模集群管理的難題

眾所周知，業(yè)務(wù)快速增長帶來的是服務(wù)器規(guī)模和數(shù)據(jù)中心數(shù)量的暴增。對于開發(fā)者而言，在大規(guī)模集群調(diào)度系統(tǒng)的業(yè)務(wù)場景下，必須要解決的兩個(gè)難題是：

1. 如何管理好數(shù)據(jù)中心大規(guī)模集群部署調(diào)度，特別是在跨數(shù)據(jù)中心場景下，如何實(shí)現(xiàn)資源的彈性和調(diào)度能力，在保障應(yīng)用服務(wù)質(zhì)量的前提下盡可能地提升資源的利用率，充分降低數(shù)據(jù)中心成本。
2. 如何改造底層基礎(chǔ)設(shè)施，為業(yè)務(wù)方打造云原生操作系統(tǒng)，提升計(jì)算服務(wù)體驗(yàn)，實(shí)現(xiàn)應(yīng)用的自動(dòng)化容災(zāi)響應(yīng)和部署升級等，減少業(yè)務(wù)方對底層資源管理的心智負(fù)擔(dān)，讓業(yè)務(wù)方可以更專注于業(yè)務(wù)本身。

運(yùn)營大規(guī)模集群的挑戰(zhàn)

為了在真實(shí)的生產(chǎn)環(huán)境解決上述兩個(gè)難題，具體又可以再拆分成以下四個(gè)大規(guī)模集群運(yùn)營管理挑戰(zhàn)：

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

設(shè)計(jì)集群調(diào)度系統(tǒng)時(shí)的取舍

為了解決上述挑戰(zhàn)，一個(gè)好的集群調(diào)度器將發(fā)揮關(guān)鍵作用。但現(xiàn)實(shí)中從來不存在一個(gè)完美的系統(tǒng)，所以在設(shè)計(jì)集群調(diào)度系統(tǒng)時(shí)，我們需要根據(jù)實(shí)際場景在幾個(gè)矛盾中做出取舍：

1. 集群調(diào)度系統(tǒng)的系統(tǒng)吞吐量和調(diào)度質(zhì)量。系統(tǒng)吞吐量是我們通常評估一個(gè)系統(tǒng)好壞很重要的標(biāo)準(zhǔn)，但在面向在線服務(wù)的集群調(diào)度系統(tǒng)里更重要的是調(diào)度質(zhì)量。因?yàn)槊看握{(diào)度結(jié)果的影響是長期的（數(shù)天、數(shù)周甚至數(shù)月），非異常情況不會(huì)調(diào)整。所以如果調(diào)度結(jié)果錯(cuò)誤，會(huì)直接導(dǎo)致服務(wù)時(shí)延增高。而調(diào)度質(zhì)量越高則意味著需要考慮的計(jì)算約束條件越多，而且調(diào)度性能越差的話，系統(tǒng)吞吐量越低。
2. 集群調(diào)度系統(tǒng)的架構(gòu)復(fù)雜度和可擴(kuò)展性。系統(tǒng)對上層PaaS用戶開放的功能和配置越多，通過支持更多功能來提升用戶體驗(yàn)（比如支持應(yīng)用資源搶占回收和應(yīng)用實(shí)例異常自愈），也就意味著系統(tǒng)復(fù)雜度越高，各子系統(tǒng)越容易發(fā)生沖突。
3. 集群調(diào)度系統(tǒng)的可靠性和單集群規(guī)模。單集群規(guī)模越大，則可調(diào)度范圍則越大，但對集群的可靠性挑戰(zhàn)也越大，因?yàn)楸ò霃綍?huì)增加，出現(xiàn)故障的影響也越大。單集群規(guī)模較小的情況下，雖然可以提升調(diào)度并發(fā)度，但可調(diào)度范圍變小，調(diào)度失敗概率變高，且集群管理復(fù)雜度變大。

目前，業(yè)內(nèi)的集群調(diào)度系統(tǒng)按照架構(gòu)區(qū)分，可以分為單體式調(diào)度器、兩級調(diào)度器、共享狀態(tài)調(diào)度器、分布式調(diào)度器和混合調(diào)度器這五種不同架構(gòu)（見下圖1），都是根據(jù)各自的場景需求做了不同的選擇，沒有絕對的好與壞。

圖1 集群調(diào)度系統(tǒng)架構(gòu)分類（摘自Malte Schwarzkopf - The evolution of cluster scheduler architectures）

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

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

美團(tuán)集群調(diào)度系統(tǒng)演變之路

美團(tuán)在落地容器化的過程中，根據(jù)業(yè)務(wù)場景需求，集群調(diào)度系統(tǒng)核心引擎由OpenStack轉(zhuǎn)變?yōu)镵ubernetes，并在2019年底完成了在線業(yè)務(wù)容器化覆蓋率超過了98%的既定目標(biāo)。但依然面臨資源利用率低、運(yùn)維成本高等問題：

• 集群整體的資源利用率不高。如CPU資源平均利用率還處于業(yè)內(nèi)平均水平，相較于其他一線互聯(lián)網(wǎng)公司差距較大。
• 有狀態(tài)服務(wù)的容器化率程度不夠，特別是MySQL、Elasticsearch等產(chǎn)品沒有使用容器，業(yè)務(wù)運(yùn)維成本和資源成本存在較大的優(yōu)化空間。
• 從業(yè)務(wù)需求考慮，VM產(chǎn)品會(huì)長期存在，VM調(diào)度和容器調(diào)度是兩套環(huán)境，導(dǎo)致團(tuán)隊(duì)虛擬化產(chǎn)品運(yùn)維成本較高。

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

• 保穩(wěn)定：提升調(diào)度系統(tǒng)的健壯性、可觀測性；降低系統(tǒng)各模塊之間的耦合，減少復(fù)雜度；提升多集群管理平臺(tái)的自動(dòng)化運(yùn)維能力；優(yōu)化系統(tǒng)核心組件性能；確保大規(guī)模集群的可用性。
• 降成本：深度優(yōu)化調(diào)度模型，打通集群調(diào)度和單機(jī)調(diào)度鏈路。從資源靜態(tài)調(diào)度轉(zhuǎn)向資源動(dòng)態(tài)調(diào)度，引入離線業(yè)務(wù)容器，形成自由競爭與強(qiáng)控結(jié)合，在保障高優(yōu)業(yè)務(wù)應(yīng)用服務(wù)質(zhì)量的前提下，提升資源使用率，降低IT成本。
• 提效率：支持用戶自助調(diào)整調(diào)度策略，滿足業(yè)務(wù)個(gè)性化需求，積極擁抱云原生領(lǐng)域，為PaaS組件提供包括編排、調(diào)度、跨集群、高可用等核心能力，提升運(yùn)維效率。

圖2 美團(tuán)集群調(diào)度系統(tǒng)架構(gòu)圖

最終，美團(tuán)集群調(diào)度系統(tǒng)架構(gòu)按照領(lǐng)域劃分為三層（見上圖2），調(diào)度平臺(tái)層、調(diào)度策略層、調(diào)度引擎層：

• 平臺(tái)層負(fù)責(zé)業(yè)務(wù)接入，打通美團(tuán)基礎(chǔ)設(shè)施，封裝原生接口和邏輯，提供容器管理接口（擴(kuò)容、更新、重啟、縮容）等功能。
• 策略層提供多集群統(tǒng)一調(diào)度能力，持續(xù)優(yōu)化調(diào)度算法和策略，結(jié)合業(yè)務(wù)的服務(wù)等級和敏感資源等信息，通過服務(wù)分級提升CPU使用率和分配率。
• 引擎層提供Kubernetes服務(wù)，保障多個(gè)PaaS組件的云原生集群穩(wěn)定性，并把通用能力下沉到編排引擎，降低業(yè)務(wù)云原生落地的接入成本。

通過精細(xì)化運(yùn)營和產(chǎn)品功能打磨，我們一方面統(tǒng)一納管了美團(tuán)近百萬的容器/虛擬機(jī)實(shí)例，另一方面將資源利用率從業(yè)內(nèi)平均水平提升到了一流水平，同時(shí)還支撐了PaaS組件的容器化和云原生落地。

多集群統(tǒng)一調(diào)度：提升數(shù)據(jù)中心資源利用率

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

• 系統(tǒng)地建立了集群狀態(tài)、宿主狀態(tài)、服務(wù)狀態(tài)的關(guān)聯(lián)，并結(jié)合調(diào)度仿真平臺(tái)，綜合考慮了峰值利用率和平均利用率，實(shí)現(xiàn)了基于宿主歷史負(fù)載和業(yè)務(wù)實(shí)時(shí)負(fù)載的預(yù)測和調(diào)度。
• 通過自研的動(dòng)態(tài)負(fù)載調(diào)節(jié)系統(tǒng)和跨集群重調(diào)度系統(tǒng)，實(shí)現(xiàn)了集群調(diào)度和單機(jī)調(diào)度鏈路的聯(lián)動(dòng)，根據(jù)業(yè)務(wù)分級實(shí)現(xiàn)了不同資源池的服務(wù)質(zhì)量保障策略。
• 經(jīng)過三版迭代，實(shí)現(xiàn)了自有集群聯(lián)邦服務(wù)，較好地解決了資源預(yù)占和狀態(tài)數(shù)據(jù)同步問題，提升了集群間的調(diào)度并發(fā)度，實(shí)現(xiàn)了計(jì)算分離、集群映射、負(fù)載均衡和跨集群編排控制（見下圖3）。

圖3 集群聯(lián)邦V3版本架構(gòu)

集群聯(lián)邦服務(wù)第三版本按照模塊拆分為Proxy層和Worker層，獨(dú)立部署：

• Proxy層會(huì)綜合集群狀態(tài)的因子及權(quán)重選擇合適的集群進(jìn)行調(diào)度，并選擇合適的Worker分發(fā)請求。Proxy模塊使用etcd做服務(wù)注冊、選主和發(fā)現(xiàn)，Leader節(jié)點(diǎn)負(fù)責(zé)調(diào)度時(shí)預(yù)占任務(wù)，所有節(jié)點(diǎn)都能負(fù)責(zé)查詢?nèi)蝿?wù)。
• Worker層對應(yīng)處理一部分Cluster的查詢請求，當(dāng)某集群任務(wù)阻塞，可以快速擴(kuò)容一臺(tái)對應(yīng)的Worker實(shí)例緩解問題。當(dāng)單集群規(guī)模較大時(shí)會(huì)對應(yīng)多個(gè)Worker實(shí)例，Proxy將調(diào)度請求分發(fā)給多個(gè)Worker實(shí)例處理，提升調(diào)度并發(fā)度，并減少每一個(gè)Worker的負(fù)載。

最終通過多集群統(tǒng)一調(diào)度，我們實(shí)現(xiàn)了從靜態(tài)資源調(diào)度模型轉(zhuǎn)向動(dòng)態(tài)資源調(diào)度模型，從而降低了熱點(diǎn)宿主比例，減少了資源碎片比例，保障了高優(yōu)業(yè)務(wù)應(yīng)用的服務(wù)質(zhì)量，將在線業(yè)務(wù)集群的服務(wù)器CPU利用率均值提升了10個(gè)百分點(diǎn)。集群資源利用率均值計(jì)算方式：Sum(nodeA.cpu.當(dāng)前使用核數(shù) + nodeB.cpu.當(dāng)前使用核數(shù) + xxx) / Sum(nodeA.cpu.總核數(shù) + nodeB.cpu.總核數(shù) + xxx），一分鐘一個(gè)點(diǎn)，當(dāng)天所有值取平均。

調(diào)度引擎服務(wù)：賦能PaaS服務(wù)云原生落地

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

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

圖4 美團(tuán)Kubernetes引擎服務(wù)調(diào)度和編排框架

在我們推進(jìn)云原生落地過程中，一個(gè)廣泛被關(guān)注的問題是：基于Kubernetes云原生方式來管理有狀態(tài)應(yīng)用，相比于之前自己打造管理平臺(tái)有什么區(qū)別？對于這個(gè)問題，需要從問題根源——可運(yùn)維性考慮：

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

未來展望：構(gòu)建云原生操作系統(tǒng)

我們認(rèn)為，云原生時(shí)代的集群管理，會(huì)從之前的管理硬件、資源等職能全面轉(zhuǎn)變?yōu)橐詰?yīng)用為中心的云原生操作系統(tǒng)。以此為目標(biāo)，美團(tuán)集群調(diào)度系統(tǒng)還需從以下幾方面發(fā)力：

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

總結(jié)

美團(tuán)集群調(diào)度系統(tǒng)在設(shè)計(jì)時(shí)，整體遵循合適原則，在滿足業(yè)務(wù)基本需求的情況下，保證系統(tǒng)穩(wěn)定后再逐步完善架構(gòu)，提升性能和豐富功能。因此，我們選擇了：

• 在系統(tǒng)吞吐量和調(diào)度質(zhì)量中我們選擇優(yōu)先滿足業(yè)務(wù)對系統(tǒng)的吞吐量需求，不過度追求單次調(diào)度質(zhì)量，而是通過重調(diào)度調(diào)整完善。
• 在架構(gòu)復(fù)雜度和可擴(kuò)展性中我們選擇降低系統(tǒng)各模塊之間的耦合，減少系統(tǒng)復(fù)雜度，擴(kuò)展功能必需可降級。
• 在可靠性和單集群規(guī)模中我們選擇通過多集群統(tǒng)一調(diào)度來控制單集群規(guī)模，保障系統(tǒng)可靠性，減少爆炸半徑。

未來，我們也會(huì)根據(jù)同樣的邏輯持續(xù)優(yōu)化迭代美團(tuán)的集群調(diào)度系統(tǒng)，徹底轉(zhuǎn)變?yōu)橐詰?yīng)用為中心的云原生操作系統(tǒng)。

作者簡介

譚霖，來自美團(tuán)基礎(chǔ)研發(fā)平臺(tái)/基礎(chǔ)技術(shù)部。