本文根據(jù)美團(tuán)基礎(chǔ)架構(gòu)部/彈性策略團(tuán)隊(duì)負(fù)責(zé)人涂揚(yáng)在2019 QCon（全球軟件開(kāi)發(fā)大會(huì)）上的演講內(nèi)容整理而成。本文涉及Kubernetes集群管理技術(shù)，美團(tuán)相關(guān)的技術(shù)實(shí)踐可參考此前發(fā)布的《美團(tuán)點(diǎn)評(píng)Kubernetes集群管理實(shí)踐》。

一、背景

HULK是美團(tuán)的容器集群管理平臺(tái)。在HULK之前，美團(tuán)的在線服務(wù)大部分部署都是在VM上，在此期間，我們遇到了很大的挑戰(zhàn)，主要包括以下兩點(diǎn)：

環(huán)境配置信息不一致：部分業(yè)務(wù)線下驗(yàn)證正常，但線上驗(yàn)證卻不正常。
業(yè)務(wù)擴(kuò)容流程長(zhǎng)：從申請(qǐng)機(jī)器、資源審核到服務(wù)部署，需要5分鐘才能完成。

因?yàn)槊缊F(tuán)很多業(yè)務(wù)都具有明顯的高低峰特性，大家一般會(huì)根據(jù)最高峰的流量情況來(lái)部署機(jī)器資源，然而在業(yè)務(wù)低峰期的時(shí)候，往往用不了那么多的資源。在這種背景下，我們希望打造一個(gè)容器集群管理平臺(tái)來(lái)解決上述的痛點(diǎn)問(wèn)題，于是HULK項(xiàng)目就應(yīng)運(yùn)而生了。

HULK平臺(tái)包含容器以及彈性調(diào)度系統(tǒng)，容器可以統(tǒng)一運(yùn)行環(huán)境、提升交付效率，而彈性調(diào)度可以提升業(yè)務(wù)的資源利用率。在漫威里有個(gè)叫HULK的英雄，在情緒激動(dòng)的時(shí)候會(huì)變成“綠巨人”，情緒平穩(wěn)后則恢復(fù)人身，這一點(diǎn)跟我們?nèi)萜鞯?rdquo;彈性伸縮“特性比較相像，所以我們的系統(tǒng)就取名為”HULK“。

總的來(lái)講，美團(tuán)HULK的演進(jìn)可以分為1.0和2.0兩個(gè)階段，如下圖所示：

在早期，HULK 1.0是基于OpenStack演進(jìn)的一個(gè)集群調(diào)度系統(tǒng)版本。這個(gè)階段工作的重點(diǎn)是將容器和美團(tuán)的基礎(chǔ)設(shè)施進(jìn)行融合，比如打通CMDB系統(tǒng)、公司內(nèi)部的服務(wù)治理平臺(tái)、發(fā)布平臺(tái)以及監(jiān)控平臺(tái)等等，并驗(yàn)證容器在生產(chǎn)環(huán)境的可行性。2018年，基礎(chǔ)架構(gòu)部將底層的OpenStack升級(jí)為容器編排標(biāo)準(zhǔn)Kubernetes，然后我們把這個(gè)版本稱之為HULK 2.0，新版本還針對(duì)在1.0運(yùn)營(yíng)過(guò)程中遇到的一些問(wèn)題，對(duì)系統(tǒng)專門(mén)進(jìn)行了優(yōu)化和打磨，主要包括以下幾個(gè)方面：

進(jìn)一步打磨了彈性策略和調(diào)度系統(tǒng)。
構(gòu)建了一站式容器運(yùn)營(yíng)平臺(tái)。
對(duì)基礎(chǔ)系統(tǒng)軟件進(jìn)行加強(qiáng)，自研內(nèi)核，提升安全隔離能力。

截止發(fā)稿時(shí)，美團(tuán)生產(chǎn)環(huán)境超過(guò)1萬(wàn)個(gè)應(yīng)用在使用容器，容器數(shù)過(guò)10萬(wàn)。

二、HULK2.0集群調(diào)度系統(tǒng)總體架構(gòu)圖

上圖中，最上層是集群調(diào)度系統(tǒng)對(duì)接的各個(gè)平臺(tái)，包括服務(wù)治理、發(fā)布平臺(tái)、測(cè)試部署平臺(tái)、CMDB系統(tǒng)、監(jiān)控平臺(tái)等，我們將這些系統(tǒng)打通，業(yè)務(wù)就可以無(wú)感知地從VM遷移到容器中。其中：

容器彈性：可以讓接入的業(yè)務(wù)按需使用容器實(shí)例。
服務(wù)畫(huà)像：負(fù)責(zé)應(yīng)用運(yùn)行情況的搜集和統(tǒng)計(jì)，如CPU/IO使用、服務(wù)高峰期、上下游等信息，為彈性伸縮、調(diào)度系統(tǒng)提供支持。
容器編排和鏡像管理：負(fù)責(zé)對(duì)實(shí)例進(jìn)行調(diào)度與應(yīng)用實(shí)例構(gòu)建。

最底層的HULK Agent是我們?cè)诿總€(gè)Node上的代理程序。此前，在美團(tuán)技術(shù)團(tuán)隊(duì)官方博客上，我們也分享過(guò)底層的鏡像管理和容器運(yùn)行時(shí)相關(guān)內(nèi)容，參見(jiàn)《美團(tuán)容器技術(shù)研發(fā)實(shí)踐》一文。而本文將重點(diǎn)闡述容器編排（調(diào)度系統(tǒng)）和容器彈性（彈性伸縮平臺(tái)），以及團(tuán)隊(duì)遇到的一些問(wèn)題以及對(duì)應(yīng)的解決方案，希望對(duì)大家能有所啟發(fā)。

三、調(diào)度系統(tǒng)痛點(diǎn)、解法

3.1 業(yè)務(wù)擴(kuò)縮容異常

痛點(diǎn)：集群運(yùn)維人員排查成本較高。

為了解決這個(gè)問(wèn)題，我們可以先看一下調(diào)度系統(tǒng)的簡(jiǎn)化版架構(gòu)，如下圖所示：

可以看到，一次擴(kuò)縮容請(qǐng)求基本上會(huì)經(jīng)歷以下這些流程：

a. 用戶或者上層系統(tǒng)發(fā)起擴(kuò)縮容請(qǐng)求。 b. 擴(kuò)縮容組件從策略配置中心獲取對(duì)應(yīng)服務(wù)的配置信息。 c. 將對(duì)應(yīng)的配置信息提交到美團(tuán)自研的一個(gè)API服務(wù)（擴(kuò)展的K8s組件），然后K8s各Master組件就按照原生的工作流程開(kāi)始Work。 d. 當(dāng)某個(gè)實(shí)例調(diào)度到具體的Node上的時(shí)候，開(kāi)始通過(guò)IP分配服務(wù)獲取對(duì)應(yīng)的Hostname和IP。 e. Container-init是一號(hào)進(jìn)程，在容器內(nèi)部拉起各個(gè)Agent，然后啟動(dòng)應(yīng)用程序。針對(duì)已經(jīng)標(biāo)準(zhǔn)化接入的應(yīng)用，會(huì)自動(dòng)進(jìn)行服務(wù)注冊(cè)，從而承載流量。

而這些模塊是由美團(tuán)內(nèi)部的不同同學(xué)分別進(jìn)行維護(hù)，每次遇到問(wèn)題時(shí)，就需要多個(gè)同學(xué)分別核對(duì)日志信息。可想而知，這種排查問(wèn)題的方式的成本會(huì)有多高。

解法：類似于分布式調(diào)用鏈中的traceId，每次擴(kuò)縮容會(huì)生成一個(gè)TaskId，我們?cè)陉P(guān)鍵鏈路上進(jìn)行打點(diǎn)的同時(shí)帶上TaskId，并按照約定的格式統(tǒng)一接入到美團(tuán)點(diǎn)評(píng)日志中心，然后在可視化平臺(tái)HULK Portal進(jìn)行展示。

落地效果：

問(wèn)題排查提效：之前排查類似問(wèn)題，多人累計(jì)耗時(shí)平均需要半個(gè)小時(shí)。目前，1個(gè)管理員通過(guò)可視化的界面即可達(dá)到分鐘級(jí)定位到問(wèn)題。
系統(tǒng)瓶頸可視化：全鏈路上每個(gè)時(shí)段的平均耗時(shí)信息一覽無(wú)遺。

3.2 業(yè)務(wù)定制化需求

痛點(diǎn)：每次業(yè)務(wù)的特殊配置都可能變更核心鏈路代碼，導(dǎo)致整體系統(tǒng)的靈活性不夠。

具體業(yè)務(wù)場(chǎng)景如下：

業(yè)務(wù)希望能夠去設(shè)置一些系統(tǒng)參數(shù)，比如開(kāi)啟swap，設(shè)置memlock、ulimit等。
環(huán)境變量配置，比如應(yīng)用名、ZooKeeper地址等。

解法：建設(shè)一體化的調(diào)度策略配置中心，通過(guò)調(diào)度策略配置中心，可定制化調(diào)度規(guī)則。

實(shí)例基本配置，比如業(yè)務(wù)想給機(jī)器加Set化、泳道標(biāo)識(shí)。
實(shí)例的擴(kuò)展配置：如部分業(yè)務(wù)，比如某些服務(wù)想將實(shí)例部署在包含特定硬件的宿主機(jī)，會(huì)對(duì)核心業(yè)務(wù)有N+1的容災(zāi)需求，并且還需要將實(shí)例部署在不同的IDC上。
相同配置的應(yīng)用可以創(chuàng)建一個(gè)組，將應(yīng)用和組進(jìn)行關(guān)聯(lián)。

在策略配置中心，我們會(huì)將這些策略進(jìn)行Manifest組裝，然后轉(zhuǎn)換成Kubernetes可識(shí)別的YAML文件。

落地效果：實(shí)現(xiàn)了平臺(tái)自動(dòng)化配置，運(yùn)維人員得到解放。

3.3 調(diào)度策略優(yōu)化

接下來(lái)，介紹一下Kubernetes調(diào)度器Scheduler的默認(rèn)行為：它啟動(dòng)之后，會(huì)一直監(jiān)聽(tīng)ApiServer，通過(guò)ApiServer去查看未Bind的Pod列表，然后根據(jù)特定的算法和策略選出一個(gè)合適的Node，并進(jìn)行Bind操作。具體的調(diào)度策略分為兩個(gè)階段：Predicates預(yù)選階段和Priorities打分階段。

Predicates 預(yù)選階段（一堆的預(yù)選條件）：PodFitsResources檢查是否有足夠的資源（比如CPU、內(nèi)存）來(lái)滿足一個(gè)Pod的運(yùn)行需求，如果不滿足，就直接過(guò)濾掉這個(gè)Node。

Priorities 打分階段（一堆的優(yōu)先級(jí)函數(shù)）：

LeastRequested：CPU和內(nèi)存具有相同的權(quán)重，資源空閑比越高的節(jié)點(diǎn)得分越高。
BalancedResourcesAllocation：CPU和內(nèi)存使用率越接近的節(jié)點(diǎn)得分越高。

將以上優(yōu)先級(jí)函數(shù)算出來(lái)的值加權(quán)平均算出來(lái)一個(gè)得分（0-10），分?jǐn)?shù)越高，節(jié)點(diǎn)越優(yōu)。

痛點(diǎn)一：當(dāng)集群達(dá)到3000臺(tái)規(guī)模的時(shí)候，一次Pod調(diào)度耗時(shí)5s左右（K8s 1.6版本）。如果在預(yù)選階段，當(dāng)前Node不符合過(guò)濾條件，依然會(huì)判斷后續(xù)的過(guò)濾條件是否符合。假設(shè)有上萬(wàn)臺(tái)Node節(jié)點(diǎn)，這種判斷邏輯便會(huì)浪費(fèi)較多時(shí)間，造成調(diào)度器的性能下降。

解法：當(dāng)前Node中，如果遇到一個(gè)預(yù)選條件不滿足（比較像是短路徑原則），就將這個(gè)Node過(guò)濾掉，大大減少了計(jì)算量，調(diào)度性能也得到大幅提升。

成效：生產(chǎn)環(huán)境驗(yàn)證，提升了40%的性能。這個(gè)方案目前已經(jīng)成為社區(qū)1.10版本默認(rèn)的調(diào)度策略，技術(shù)細(xì)節(jié)可以參考GitHub上的PR。

痛點(diǎn)二：資源利用率最大化和服務(wù)SLA保障之間的權(quán)衡。

解法：我們基于服務(wù)的行為數(shù)據(jù)構(gòu)建了服務(wù)畫(huà)像系統(tǒng)，下圖是我們針對(duì)某個(gè)應(yīng)用進(jìn)行服務(wù)畫(huà)像后的樹(shù)圖展現(xiàn)。

調(diào)度前：可以將有調(diào)用關(guān)系的Pod設(shè)置親和性，競(jìng)爭(zhēng)相同資源的Pod設(shè)置反親和性，相同宿主機(jī)上最多包含N個(gè)核心應(yīng)用。調(diào)度后：經(jīng)過(guò)上述規(guī)則調(diào)度后，在宿主機(jī)上如果依然出現(xiàn)了資源競(jìng)爭(zhēng)，優(yōu)先保障高優(yōu)先級(jí)應(yīng)用的SLA。

3.4 重編排問(wèn)題

痛點(diǎn)：

（1）容器重啟/遷移場(chǎng)景：

容器和系統(tǒng)盤(pán)的信息丟失。
容器的IP變更。

（2）驅(qū)逐場(chǎng)景：Kubelet會(huì)自動(dòng)殺死一些違例容器，但有可能是非常核心的業(yè)務(wù)。

解法：

（1）容器重啟/遷移場(chǎng)景：

新增Reuse策略，保留原生重啟策略（Rebuild）。
定制化CNI插件，基于Pod標(biāo)識(shí)申請(qǐng)和復(fù)用IP。

（2）關(guān)閉原生的驅(qū)逐策略，通過(guò)外部組件來(lái)做決策。

四、彈性伸縮平臺(tái)痛點(diǎn)、解法

彈性伸縮平臺(tái)整體架構(gòu)圖如下：

注：Raptor是美團(tuán)點(diǎn)評(píng)內(nèi)部的大監(jiān)控平臺(tái)，整合了CAT、Falcon等監(jiān)控產(chǎn)品。

在彈性伸縮平臺(tái)演進(jìn)的過(guò)程中，我們主要遇到了以下5個(gè)問(wèn)題。

4.1 多策略決策不一致

如上圖所示，一個(gè)業(yè)務(wù)配置了2條監(jiān)控策略和1條周期策略：

監(jiān)控策略：當(dāng)某個(gè)指標(biāo)（比如QPS、CPU）超過(guò)閾值上限后開(kāi)始擴(kuò)容，低于閾值下限后開(kāi)始縮容。
周期策略：在某個(gè)固定的時(shí)間開(kāi)始擴(kuò)容，另外一個(gè)固定的時(shí)間開(kāi)始縮容。

早期的設(shè)計(jì)是各條策略獨(dú)自決策，擴(kuò)容順序有可能是：縮5臺(tái)、縮2臺(tái)、擴(kuò)10臺(tái)，也有可能是：擴(kuò)10臺(tái)、縮5臺(tái)、縮2臺(tái)，就可能造成一些無(wú)效的擴(kuò)縮行為。

解法：增加了一個(gè)聚合層（或者把它稱之為策略協(xié)商層），提供一些聚合策略：默認(rèn)策略（多擴(kuò)少縮）和權(quán)重策略（權(quán)重高的來(lái)決策擴(kuò)縮行為），減少了大量的無(wú)效擴(kuò)縮現(xiàn)象。

4.2 擴(kuò)縮不冪等

如上圖所示，聚合層發(fā)起具體擴(kuò)縮容的時(shí)候，因之前采用的是增量擴(kuò)容方式，在一些場(chǎng)景下會(huì)出現(xiàn)頻繁擴(kuò)縮現(xiàn)象。比如，原先12臺(tái)，這個(gè)時(shí)候彈性伸縮平臺(tái)告訴調(diào)度系統(tǒng)要擴(kuò)容8臺(tái)，在返回TaskId的過(guò)程中超時(shí)或保存TaskId失敗了，這個(gè)時(shí)候彈性伸縮平臺(tái)會(huì)繼續(xù)發(fā)起擴(kuò)容8臺(tái)的操作，最后導(dǎo)致服務(wù)下有28臺(tái)實(shí)例（不冪等）。

解法：采用按目標(biāo)擴(kuò)容方式，直接告訴對(duì)端，希望能擴(kuò)容到20臺(tái)，避免了短時(shí)間內(nèi)的頻繁擴(kuò)縮容現(xiàn)象。

4.3 線上代碼多版本

如上圖所示，一個(gè)業(yè)務(wù)線上有30臺(tái)機(jī)器，存在3個(gè)版本（A、B、C）。之前我們彈性擴(kuò)容的做法是采用業(yè)務(wù)構(gòu)建的最新鏡像進(jìn)行擴(kuò)容，但在實(shí)際生產(chǎn)環(huán)境運(yùn)行過(guò)程中卻遇到問(wèn)題。比如一些業(yè)務(wù)構(gòu)建的最新鏡像是用來(lái)做小流量測(cè)試的，本身的穩(wěn)定性沒(méi)有保障，高峰期擴(kuò)容的時(shí)候會(huì)提升這個(gè)版本在線上機(jī)器中的比例，低峰期的時(shí)候又把之前穩(wěn)定版本給縮容了，經(jīng)過(guò)一段時(shí)間的頻繁擴(kuò)縮之后，最后線上遺留的實(shí)例可能都存在問(wèn)題。

解法：基于約定優(yōu)于配置原則，我們采用業(yè)務(wù)的穩(wěn)定鏡像（采用灰度發(fā)布流程將線上所有實(shí)例均覆蓋過(guò)一遍的鏡像，會(huì)自動(dòng)標(biāo)記為穩(wěn)定鏡像）進(jìn)行擴(kuò)容，這樣就比較好地解決了這個(gè)問(wèn)題。

4.4 資源保障問(wèn)題

如上圖所示，存量中有2個(gè)服務(wù)，一個(gè)需要擴(kuò)容20臺(tái)，一個(gè)需要擴(kuò)容15臺(tái)，這個(gè)時(shí)候如果新接入一個(gè)服務(wù)，同一時(shí)間需要擴(kuò)容30臺(tái)，但是資源池只剩余50臺(tái)實(shí)例了。這個(gè)時(shí)候就意味著，誰(shuí)先擴(kuò)容誰(shuí)就可以獲得資源保障，后發(fā)起的請(qǐng)求就無(wú)法獲得資源保障。

解法：

（1）存量資源水位檢測(cè)：當(dāng)存量資源的使用水位超過(guò)閾值的時(shí)候，比如達(dá)到80%的時(shí)候會(huì)有報(bào)警，告訴我們需要做資源補(bǔ)充操作。 （2）增量服務(wù)彈性資源預(yù)估：如果這個(gè)服務(wù)通過(guò)預(yù)判算法評(píng)估，接入之后可能會(huì)導(dǎo)致存量服務(wù)的擴(kuò)容得不到保障，則拒絕或者補(bǔ)充資源后，再讓這個(gè)業(yè)務(wù)接入。

4.5 端到端時(shí)效問(wèn)題

如圖所示，我們的分鐘級(jí)監(jiān)控時(shí)延（比如1:00:00~1:01:00的監(jiān)控?cái)?shù)據(jù)，大概需要到1:01:10后可將采集到的所有數(shù)據(jù)聚合完成）是70s+，調(diào)度鏈路時(shí)延是30s+，整體需要上100s+，在生產(chǎn)環(huán)境的業(yè)務(wù)往往會(huì)比較關(guān)注擴(kuò)容時(shí)延。

解法：監(jiān)控系統(tǒng)這塊已經(jīng)建設(shè)秒級(jí)監(jiān)控功能。基于這些做法都屬于后驗(yàn)性擴(kuò)容，存在一定的延遲性，目前我們也在探索基于歷史行為數(shù)據(jù)進(jìn)行服務(wù)預(yù)測(cè)，在監(jiān)控指標(biāo)達(dá)到擴(kuò)容閾值前的1~2分鐘進(jìn)行提前擴(kuò)容。

五、經(jīng)驗(yàn)總結(jié)

技術(shù)側(cè)：

開(kāi)源產(chǎn)品“本土化”： 原生的Kubernetes需要和內(nèi)部已有的基礎(chǔ)設(shè)施，如服務(wù)樹(shù)、發(fā)布系統(tǒng)、服務(wù)治理平臺(tái)、監(jiān)控系統(tǒng)等做融合，才能更容易在公司內(nèi)進(jìn)行落地。
調(diào)度決策：增量的調(diào)度均使用新策略來(lái)進(jìn)行規(guī)范化，存量的可采用重調(diào)度器進(jìn)行治理。
彈性伸縮：公有云在彈性伸縮這塊是沒(méi)有SLA保障的，但是做內(nèi)部私有云，就需要做好擴(kuò)容成功率、端到端時(shí)延這兩塊的SLA保障。

業(yè)務(wù)側(cè)：

業(yè)務(wù)遷移：建設(shè)了全自動(dòng)化遷移平臺(tái)，幫助業(yè)務(wù)從VM自動(dòng)遷移到容器，極大地降低了因遷移而帶來(lái)的人力投入。
業(yè)務(wù)成本：使用HULK可較好地提升業(yè)務(wù)運(yùn)維效率（HULK具備資源利用率更高、彈性擴(kuò)容、一鍵擴(kuò)容等特點(diǎn)），降低了業(yè)務(wù)成本。

作者簡(jiǎn)介

涂揚(yáng)，美團(tuán)點(diǎn)評(píng)技術(shù)專家，現(xiàn)任基礎(chǔ)架構(gòu)部彈性策略團(tuán)隊(duì)負(fù)責(zé)人。

招聘信息

美團(tuán)點(diǎn)評(píng)基礎(chǔ)架構(gòu)團(tuán)隊(duì)誠(chéng)招高級(jí)、資深技術(shù)專家，Base北京、上海。我們致力于建設(shè)美團(tuán)點(diǎn)評(píng)全公司統(tǒng)一的高并發(fā)高性能分布式基礎(chǔ)架構(gòu)平臺(tái)，涵蓋數(shù)據(jù)庫(kù)、分布式監(jiān)控、服務(wù)治理、高性能通信、消息中間件、基礎(chǔ)存儲(chǔ)、容器化、集群調(diào)度等基礎(chǔ)架構(gòu)主要的技術(shù)領(lǐng)域。歡迎有興趣的同學(xué)投送簡(jiǎn)歷到 tech@meituan.com（郵件標(biāo)題注明：基礎(chǔ)架構(gòu)部彈性策略團(tuán)隊(duì)）

總結(jié)

以上是生活随笔為你收集整理的美团集群调度系统HULK技术演进的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。