背景

作為國內(nèi)領(lǐng)先的生活服務(wù)平臺(tái)，美團(tuán)點(diǎn)評(píng)很多業(yè)務(wù)都具有非常顯著、規(guī)律的”高峰“和”低谷“特征。尤其遇到節(jié)假日或促銷活動(dòng)，流量還會(huì)在短時(shí)間內(nèi)出現(xiàn)爆發(fā)式的增長。這對(duì)集群中心的資源彈性和可用性有非常高的要求，同時(shí)也會(huì)使系統(tǒng)在支撐業(yè)務(wù)流量時(shí)的復(fù)雜度和成本支出呈現(xiàn)指數(shù)級(jí)增長。而我們需要做的，就是利用有限的資源最大化地提升集群的吞吐能力，以保障用戶體驗(yàn)。

本文將介紹美團(tuán)點(diǎn)評(píng)Kubernetes集群管理與使用實(shí)踐，包括美團(tuán)點(diǎn)評(píng)集群管理與調(diào)度系統(tǒng)介紹、Kubernetes管理與實(shí)踐、Kubernetes優(yōu)化與改造以及資源管理與優(yōu)化等。

美團(tuán)點(diǎn)評(píng)集群管理與調(diào)度系統(tǒng)

美團(tuán)點(diǎn)評(píng)在集群管理和資源優(yōu)化這條道路上已經(jīng)“摸爬滾打”多年。2013年，開始構(gòu)建基于傳統(tǒng)虛擬化技術(shù)的資源交付方式;2015年7月，開始建立完善的集群管理與調(diào)度系統(tǒng)——HULK，目標(biāo)是推動(dòng)美團(tuán)點(diǎn)評(píng)服務(wù)容器化;2016年，完成基于Docker容器技術(shù)自研實(shí)現(xiàn)了彈性伸縮能力，來提升交付速度和應(yīng)對(duì)快速擴(kuò)縮容的需求，實(shí)現(xiàn)彈性擴(kuò)容、縮容，提升資源利用率，提升業(yè)務(wù)運(yùn)維效率，合理有效的降低企業(yè)IT運(yùn)維成本;2018年，開始基于Kubernetes來進(jìn)行資源管理和調(diào)度，進(jìn)一步提升資源的使用效率。

最初，美團(tuán)點(diǎn)評(píng)通過基于Docker容器技術(shù)自研實(shí)現(xiàn)了彈性伸縮能力，主要是為了解決基于虛擬化技術(shù)的管理及部署機(jī)制在應(yīng)對(duì)服務(wù)快速擴(kuò)容、縮容需求時(shí)存在的諸多不足。例如資源實(shí)例創(chuàng)建慢、無法統(tǒng)一運(yùn)行環(huán)境、實(shí)例部署和交付流程長、資源回收效率低、彈性能力差等等。經(jīng)過調(diào)研與測(cè)試，結(jié)合業(yè)界的實(shí)踐經(jīng)驗(yàn)，我們決定基于Docker容器技術(shù)自研集群管理與調(diào)度系統(tǒng)，有效應(yīng)對(duì)快速擴(kuò)縮容的需求，提升資源的利用效率。我們把它叫做”綠巨人”——HULK，這個(gè)階段可以看作是HULK1.0。

之后，在生產(chǎn)環(huán)境中經(jīng)過不斷摸索和嘗試，我們逐漸意識(shí)到，僅僅滿足于集群的彈性伸縮能力是不夠的，成本和效率肯定是未來必將面臨且更為棘手的問題。我們吸取了2年來HULK 1.0的開發(fā)和運(yùn)維經(jīng)驗(yàn)，在架構(gòu)和支撐系統(tǒng)層面做了進(jìn)一步優(yōu)化和改進(jìn)，并借助于生態(tài)和開源的力量來為HULK賦能，即引入了開源的集群管理與調(diào)度系統(tǒng)Kubernetes，期望能進(jìn)一步提升集群管理、運(yùn)行的效率和穩(wěn)定性，同時(shí)降低資源成本。所以我們從自研平臺(tái)轉(zhuǎn)向了開源的Kubernetes系統(tǒng)，并基于Kubernetes系統(tǒng)打造了更加智能化的集群管理與調(diào)度系統(tǒng)——HULK2.0。

架構(gòu)全覽

在架構(gòu)層面，HULK2.0如何能與上層業(yè)務(wù)和底層Kubernetes平臺(tái)更好地分層和解耦，是我們?cè)谠O(shè)計(jì)之初就優(yōu)先考慮的問題。我們期望它既要能對(duì)業(yè)務(wù)使用友好，又能最大限度地發(fā)揮Kubernetes的調(diào)度能力，使得業(yè)務(wù)層和使用方毋需關(guān)注資源關(guān)系細(xì)節(jié)，所求即所得;同時(shí)使發(fā)布、配置、計(jì)費(fèi)、負(fù)載等邏輯層與底層的Kubernetes平臺(tái)解耦分層，并保持兼容原生Kubernetes API來訪問Kubernetes集群。從而可以借助于統(tǒng)一的、主流的、符合業(yè)界規(guī)范的標(biāo)準(zhǔn)，來解決美團(tuán)點(diǎn)評(píng)基礎(chǔ)架構(gòu)面臨的復(fù)雜的、多樣的、不統(tǒng)一的管理需求。

架構(gòu)介紹

自上而下來看，美團(tuán)集群管理與調(diào)度平臺(tái)面向全公司服務(wù)，有各個(gè)主要業(yè)務(wù)線、統(tǒng)一的OPS平臺(tái)以及Portal平臺(tái)，HULK不可能針對(duì)每個(gè)平臺(tái)定制化接口和解決方案，所以需要將多樣的業(yè)務(wù)和需求抽象收斂,最終統(tǒng)一通過HULK API來屏蔽HULK系統(tǒng)的細(xì)節(jié)，做到HULK與上層業(yè)務(wù)方的解耦。HULK API是對(duì)業(yè)務(wù)層和資源需求的抽象，是外界訪問HULK的唯一途徑。

解決了上層的問題后，我們?cè)賮砜磁c下層Kubernetes平臺(tái)的解耦。HULK接到上層資源請(qǐng)求后，首先要進(jìn)行一系列的初始化工作，包括參數(shù)校驗(yàn)、資源余量、IP和Hostname的分配等等，之后向Kubernetes平臺(tái)實(shí)際申請(qǐng)分配機(jī)器資源，最終將資源交付給用戶，Kubernetes API進(jìn)一步將資源需求收斂和轉(zhuǎn)換，讓我們可以借助于Kubernetes的資源管理優(yōu)勢(shì)。Kubernetes API旨在收斂HULK的資源管理邏輯并與業(yè)界主流對(duì)齊。此外，因?yàn)橥耆嫒軰ubernetes API，可以讓我們借助社區(qū)和生態(tài)的力量，共同建設(shè)和探索。

可以看到，HULK API和Kubernetes API將我們整個(gè)系統(tǒng)分為三層，這樣可以讓每一層都專注于各自的模塊。

Kubernetes管理與實(shí)踐

為什么會(huì)選擇Kubernetes呢?Kubernetes并不是市面上唯一的集群管理平臺(tái)(其他如Docker Swarm或Mesos)，之所以選擇它，除了它本身優(yōu)秀的架構(gòu)設(shè)計(jì)，我們更加看重的是Kubernetes提供的不是一個(gè)解決方案，而是一個(gè)平臺(tái)和一種能力。這種能力能夠讓我們真正基于美團(tuán)點(diǎn)評(píng)的實(shí)際情況來擴(kuò)展，同時(shí)能夠依賴和復(fù)用多年來的技術(shù)積累，給予我們更多選擇的自由，包括我們可以快速地部署應(yīng)用程序，而無須面對(duì)傳統(tǒng)平臺(tái)所具有的風(fēng)險(xiǎn)，動(dòng)態(tài)地?cái)U(kuò)展應(yīng)用程序以及更好的資源分配策略。

Kubernetes集群作為整個(gè)HULK集群資源管理與平臺(tái)的基礎(chǔ)，需求是穩(wěn)定性和可擴(kuò)展性，風(fēng)險(xiǎn)可控性和集群吞吐能力。

集群運(yùn)營現(xiàn)狀

• 集群規(guī)模：10萬+級(jí)別線上實(shí)例，多地域部署，還在不斷快速增長中。
• 業(yè)務(wù)的監(jiān)控告警：集群對(duì)應(yīng)用的啟動(dòng)和狀態(tài)數(shù)據(jù)進(jìn)行采集，container-init自動(dòng)集成業(yè)務(wù)監(jiān)控信息，業(yè)務(wù)程序毋需關(guān)注，做到可插拔、可配置。
• 資源的健康告警：從資源的角度對(duì) Node、Pod和 Container等重要數(shù)據(jù)監(jiān)控采集，及時(shí)發(fā)現(xiàn)它們的狀態(tài)信息，例如 Node不可用、Container不斷重啟等等。
• 定時(shí)巡檢與對(duì)賬：每天自動(dòng)對(duì)所有宿主機(jī)進(jìn)行狀態(tài)檢查，包括剩余磁盤量(數(shù)據(jù)卷)、D進(jìn)程數(shù)量、宿主機(jī)狀態(tài)等，并對(duì)AppKey擴(kuò)容數(shù)據(jù)和實(shí)際的Pod和容器數(shù)據(jù)同步校驗(yàn)，及時(shí)發(fā)現(xiàn)不一致情況。
• 集群數(shù)據(jù)可視化：對(duì)當(dāng)前集群狀態(tài)，包括宿主機(jī)資源狀態(tài)、服務(wù)數(shù)、Pod數(shù)、容器化率、服務(wù)狀態(tài)、擴(kuò)縮容數(shù)據(jù)等等可視化;并提供了界面化的服務(wù)配置、宿主機(jī)下線以及Pod遷移操作入口。
• 容量規(guī)劃與預(yù)測(cè)：提前感知集群資源狀態(tài)，預(yù)先準(zhǔn)備資源;基于規(guī)則和機(jī)器學(xué)習(xí)的方式感知流量和高峰，保證業(yè)務(wù)正常、穩(wěn)定、高效地運(yùn)行。

Kubernetes優(yōu)化與改造

kube-scheduler性能優(yōu)化

我們有集群在使用1.6版本的調(diào)度器，隨著集群規(guī)模的不斷增長，舊版本的Kubernetes調(diào)度器(1.10之前版本)在性能和穩(wěn)定性的問題逐漸凸顯，由于調(diào)度器的吞吐量低，導(dǎo)致業(yè)務(wù)擴(kuò)容超時(shí)失敗，在規(guī)模近3000臺(tái)的集群上，一次Pod的調(diào)度耗時(shí)在5s左右。Kubernetes的調(diào)度器是隊(duì)列化的調(diào)度器模型，一旦擴(kuò)容高峰等待的Pod數(shù)量過多就會(huì)導(dǎo)致后面Pod的擴(kuò)容超時(shí)。為此，我們對(duì)調(diào)度器性能進(jìn)行了大幅度的優(yōu)化，并取得了非常明顯的提升，根據(jù)我們的實(shí)際生產(chǎn)環(huán)境驗(yàn)證，性能比優(yōu)化前提升了400%以上。

Kubernetes調(diào)度器工作模型如下：

預(yù)選失敗中斷機(jī)制

一次調(diào)度過程在判斷一個(gè) Node是否可作為目標(biāo)機(jī)器時(shí)，主要分為三個(gè)階段：

• 預(yù)選階段：硬性條件，過濾掉不滿足條件的節(jié)點(diǎn)，這個(gè)過程稱為 Predicates。這是固定先后順序的一系列過濾條件，任何一個(gè) Predicate不符合則放棄該 Node。
• 優(yōu)選階段：軟性條件，對(duì)通過的節(jié)點(diǎn)按照優(yōu)先級(jí)排序，稱之為 Priorities。每一個(gè)Priority都是一個(gè)影響因素，都有一定的權(quán)重。
• 選定階段：從優(yōu)選列表中選擇優(yōu)先級(jí)最高的節(jié)點(diǎn)，稱為 Select。選擇的Node即為最終部署Pod的機(jī)器。

通過深入分析調(diào)度過程可以發(fā)現(xiàn)，調(diào)度器在預(yù)選階段即使已經(jīng)知道當(dāng)前 Node不符合某個(gè)過濾條件仍然會(huì)繼續(xù)判斷后續(xù)的過濾條件是否符合。試想如果有上萬臺(tái) Node節(jié)點(diǎn)，這些判斷邏輯會(huì)浪費(fèi)很多計(jì)算時(shí)間，這也是調(diào)度器性能低下的一個(gè)重要因素。

為此，我們提出了“預(yù)選失敗中斷機(jī)制”，即一旦某個(gè)預(yù)選條件不滿足，那么該 Node即被立即放棄，后面的預(yù)選條件不再做判斷計(jì)算，從而大大減少了計(jì)算量，調(diào)度性能也大大提升。如下圖所示：

我們把該項(xiàng)優(yōu)化貢獻(xiàn)給了 Kubernetes社區(qū)(詳見PR)，增加了 alwaysCheckAllPredicates 策略選項(xiàng)，并在 Kubernetes1.10版本發(fā)布并開始作為默認(rèn)的調(diào)度策略，當(dāng)然你也可以通過設(shè)置alwaysCheckAllPredicates=true使用原先的調(diào)度策略。

在實(shí)際測(cè)試中，調(diào)度器至少可以提升40%的性能，如果你目前在使用的Kube-scheduler的版本低于1.10，那么建議你嘗試升級(jí)到新的版本。

局部最優(yōu)解

對(duì)于優(yōu)化問題尤其是最優(yōu)化問題，我們總希望找到全局最優(yōu)的解或策略，但是當(dāng)問題的復(fù)雜度過高，要考慮的因素和處理的信息量過多時(shí)，我們往往會(huì)傾向于接受局部最優(yōu)解，因?yàn)榫植孔顑?yōu)解的質(zhì)量不一定都是差的。尤其是當(dāng)我們有確定的評(píng)判標(biāo)準(zhǔn)，同時(shí)標(biāo)明得出的解是可以接受的話，通常會(huì)接收局部最優(yōu)的結(jié)果。這樣，從成本、效率等多方面考慮，才是我們?cè)趯?shí)際工程中真正會(huì)采取的策略。

當(dāng)前調(diào)度策略中，每次調(diào)度調(diào)度器都會(huì)遍歷集群中所有的Node，以便找出最優(yōu)的節(jié)點(diǎn)，這在調(diào)度領(lǐng)域稱之為BestFit算法。但是在生產(chǎn)環(huán)境中，我們是選取最優(yōu)Node還是次優(yōu)Node，其實(shí)并沒有特別大的區(qū)別和影響，有時(shí)候我們還是會(huì)避免選取最優(yōu)的Node(例如我們集群為了解決新上線機(jī)器后頻繁在該機(jī)器上創(chuàng)建應(yīng)用的問題，就將最優(yōu)解隨機(jī)化)。換句話說，找出局部最優(yōu)解就能滿足需求。

假設(shè)集群一共1000個(gè)Node，一次調(diào)度過程PodA，這其中有700個(gè)Node都能通過Predicates(預(yù)選階段)，那么我們就會(huì)把所有的Node遍歷并找出這700個(gè)Node，然后經(jīng)過得分排序找出最優(yōu)的Node節(jié)點(diǎn)NodeX。但是采用局部最優(yōu)算法，即我們認(rèn)為只要能找出N個(gè)Node，并在這N個(gè)Node中選擇得分最高的Node即能滿足需求，比如默認(rèn)找出100個(gè)可以通過Predicates(預(yù)選階段)的Node即可，最優(yōu)解就在這100個(gè)Node中選擇。當(dāng)然全局最優(yōu)解NodeX也可能不在這100個(gè)Node中，但是我們?cè)谶@100個(gè)Node中選擇最優(yōu)的NodeY也能滿足要求。最好的情況是遍歷100個(gè)Node就找出這100個(gè)Node，也可能遍歷了200個(gè)或者300個(gè)Node等等，這樣我們可以大大減少計(jì)算時(shí)間，同時(shí)也不會(huì)對(duì)我們的調(diào)度結(jié)果產(chǎn)生太大的影響。

局部最優(yōu)的策略是我們與社區(qū)合作共同完成的，這里面還涉及到如何做到公平調(diào)度和計(jì)算任務(wù)優(yōu)化的細(xì)節(jié)(詳見PR1,PR2)，該項(xiàng)優(yōu)化在Kubernetes 1.12版本中發(fā)布，并作為當(dāng)前默認(rèn)調(diào)度策略，可以大幅度提升調(diào)度性能，尤其在大規(guī)模集群中的提升，效果非常明顯。

kubelet改造

風(fēng)險(xiǎn)可控性

前面提到，穩(wěn)定性和風(fēng)險(xiǎn)可控性對(duì)大規(guī)模集群管理來說非常重要。從架構(gòu)上來看，Kubelet是離真實(shí)業(yè)務(wù)最近的集群管理組件，我們知道社區(qū)版本的Kubelet對(duì)本機(jī)資源管理有著很大的自主性，試想一下，如果某個(gè)業(yè)務(wù)正在運(yùn)行，但是Kubelet由于出發(fā)了驅(qū)逐策略而把這個(gè)業(yè)務(wù)的容器干掉了會(huì)發(fā)生什么?這在我們的集群中是不應(yīng)該發(fā)生的，所以需要收斂和封鎖Kubelet的自決策能力，它對(duì)本機(jī)上業(yè)務(wù)容器的操作都應(yīng)該從上層平臺(tái)發(fā)起。

容器重啟策略

Kernel升級(jí)是日常的運(yùn)維操作，在通過重啟宿主機(jī)來升級(jí)Kernel版本的時(shí)候，我們發(fā)現(xiàn)宿主機(jī)重啟后，上面的容器無法自愈或者自愈后版本不對(duì)，這會(huì)引發(fā)業(yè)務(wù)的不滿，也造成了我們不小的運(yùn)維壓力。后來我們?yōu)镵ubelet增加了一個(gè)重啟策略(Reuse)，同時(shí)保留了原生重啟策略(Rebuild)，保證容器系統(tǒng)盤和數(shù)據(jù)盤的信息都能保留，宿主機(jī)重啟后容器也能自愈。

IP狀態(tài)保持

根據(jù)美團(tuán)點(diǎn)評(píng)的網(wǎng)絡(luò)環(huán)境，我們自研了CNI插件，并通過基于Pod唯一標(biāo)識(shí)來申請(qǐng)和復(fù)用IP。做到了應(yīng)用IP在Pod遷移和容器重啟之后也能復(fù)用，為業(yè)務(wù)上線和運(yùn)維帶來了不少的收益。

限制驅(qū)逐策略

我們知道Kubelet擁有節(jié)點(diǎn)自動(dòng)修復(fù)的能力，例如在發(fā)現(xiàn)異常容器或不合規(guī)容器后，會(huì)對(duì)它們進(jìn)行驅(qū)逐刪除操作，這對(duì)于我們來說風(fēng)險(xiǎn)太大，我們?cè)试S容器在一些次要因素方面可以不合規(guī)。例如當(dāng)Kubelet發(fā)現(xiàn)當(dāng)前宿主機(jī)上容器個(gè)數(shù)比設(shè)置的最大容器個(gè)數(shù)大時(shí)，會(huì)挑選驅(qū)逐和刪除某些容器，雖然正常情況下不會(huì)輕易發(fā)生這種問題，但是我們也需要對(duì)此進(jìn)行控制，降低此類風(fēng)險(xiǎn)。

可擴(kuò)展性

資源調(diào)配

在Kubelet的擴(kuò)展性方面我們?cè)鰪?qiáng)了資源的可操作性，例如為容器綁定Numa從而提升應(yīng)用的穩(wěn)定性;根據(jù)應(yīng)用等級(jí)為容器設(shè)置CPUShare，從而調(diào)整調(diào)度權(quán)重;為容器綁定CPUSet等等。

增強(qiáng)容器

我們打通并增強(qiáng)了業(yè)務(wù)對(duì)容器的配置能力，支持業(yè)務(wù)給自己的容器擴(kuò)展ulimit、io limit、pid limit、swap等參數(shù)的同時(shí)也增強(qiáng)容器之間的隔離能力。

應(yīng)用原地升級(jí)

大家都知道，Kubernetes默認(rèn)只要Pod的關(guān)鍵信息有改動(dòng)，例如鏡像信息，就會(huì)出發(fā)Pod的重建和替換，這在生產(chǎn)環(huán)境中代價(jià)是很大的，一方面IP和HostName會(huì)發(fā)生改變，另一方面頻繁的重建也給集群管理帶來了更多的壓力，甚至還可能導(dǎo)致無法調(diào)度成功。為了解決該問題，我們打通了自上而下的應(yīng)用原地升級(jí)功能，即可以動(dòng)態(tài)高效地修改應(yīng)用的信息，并能在原地(宿主機(jī))進(jìn)行升級(jí)。

鏡像分發(fā)

鏡像分發(fā)是影響容器擴(kuò)容時(shí)長的一個(gè)重要環(huán)節(jié)，我們采取了一系列手段來優(yōu)化，保證鏡像分發(fā)效率高且穩(wěn)定：

• 跨Site同步：保證服務(wù)器總能從就近的鏡像倉庫拉取到擴(kuò)容用的鏡像，減少拉取時(shí)間，降低跨Site帶寬消耗。
• 基礎(chǔ)鏡像預(yù)分發(fā)：美團(tuán)點(diǎn)評(píng)的基礎(chǔ)鏡像是構(gòu)建業(yè)務(wù)鏡像的公共鏡像。業(yè)務(wù)鏡像層是業(yè)務(wù)的應(yīng)用代碼，通常比基礎(chǔ)鏡像小很多。在容器擴(kuò)容的時(shí)候如果基礎(chǔ)鏡像已經(jīng)在本地，就只需要拉取業(yè)務(wù)鏡像的部分，可以明顯的加快擴(kuò)容速度。為達(dá)到這樣的效果，我們會(huì)把基礎(chǔ)鏡像事先分發(fā)到所有的服務(wù)器上。
• P2P鏡像分發(fā)：基礎(chǔ)鏡像預(yù)分發(fā)在有些場(chǎng)景會(huì)導(dǎo)致上千個(gè)服務(wù)器同時(shí)從鏡像倉庫拉取鏡像，對(duì)鏡像倉庫服務(wù)和帶寬帶來很大的壓力。因此我們開發(fā)了鏡像P2P分發(fā)的功能，服務(wù)器不僅能從鏡像倉庫中拉取鏡像，還能從其他服務(wù)器上獲取鏡像的分片。

資源管理與優(yōu)化

優(yōu)化關(guān)鍵技術(shù)

• 服務(wù)畫像：對(duì)應(yīng)用的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤和網(wǎng)絡(luò) I/O 容量和負(fù)載畫像，了解應(yīng)用的特征、資源規(guī)格和應(yīng)用類型以及不同時(shí)間對(duì)資源的真實(shí)使用，然后從服務(wù)角度和時(shí)間維度進(jìn)行相關(guān)性分析，從而進(jìn)行整體調(diào)度和部署優(yōu)化。
• 親和性和互斥性：哪些應(yīng)用放在一起使整體計(jì)算能力比較少而吞吐能力比較高，它們就存在一定親和性;反之如果應(yīng)用之間存在資源競爭或相互影響，則它們之間就存在著互斥性。
• 場(chǎng)景優(yōu)先：美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)大都是基本穩(wěn)定的場(chǎng)景，所以場(chǎng)景劃分很有必要。例如一類業(yè)務(wù)對(duì)延遲非常敏感，即使在高峰時(shí)刻也不允許有太多的資源競爭產(chǎn)生，這種場(chǎng)景就要避免和減少資源競爭引起的延遲，保證資源充足;一類業(yè)務(wù)在有些時(shí)間段需要的CPU資源可能會(huì)突破配置的上限，我們通過CPU Set化的方式讓這類業(yè)務(wù)共享這部分資源，以便能夠突破申請(qǐng)規(guī)格的機(jī)器資源限制，不僅服務(wù)能夠獲得更高的性能表現(xiàn)，同時(shí)也把空閑的資源利用了起來，資源使用率進(jìn)一步提升。
• 彈性伸縮：應(yīng)用部署做到流量預(yù)測(cè)、自動(dòng)伸縮、基于規(guī)則的高低峰伸縮以及基于機(jī)器學(xué)習(xí)的伸縮機(jī)制。
• 精細(xì)化資源調(diào)配：基于資源共享和隔離技術(shù)做到了精細(xì)化的資源調(diào)度和分配，例如Numa綁定、任務(wù)優(yōu)先級(jí)、CPU Set化等等。

策略優(yōu)化

調(diào)度策略的主要作用在兩方面，一方面是按照既定策略部署目標(biāo)機(jī)器;二是能做到集群資源的排布最優(yōu)。

• 親和性：有調(diào)用關(guān)系和依賴的應(yīng)用，或哪些應(yīng)用放在一起能使整體計(jì)算能力比較少、吞吐能力比較高，這些應(yīng)用間就存在一定親和性。我們的CPU Set化即是利用了對(duì)CPU的偏好構(gòu)建應(yīng)用的親和性約束，讓不同CPU偏好的應(yīng)用互補(bǔ)。
• 互斥性：跟親和性相對(duì)，主要是對(duì)有競爭關(guān)系或業(yè)務(wù)干擾的應(yīng)用在調(diào)度時(shí)盡量分開部署。
• 應(yīng)用優(yōu)先級(jí)：應(yīng)用優(yōu)先級(jí)的劃分是為我們解決資源競爭提供了前提。當(dāng)前當(dāng)容器發(fā)生資源競爭時(shí)，我們無法決策究竟應(yīng)該讓誰獲得資源，當(dāng)有了應(yīng)用優(yōu)先級(jí)的概念后，我們可以做到，在調(diào)度層，限制單臺(tái)宿主機(jī)上重要應(yīng)用的個(gè)數(shù)，減少單機(jī)的資源競爭，也為單機(jī)底層解決資源競爭提供可能;在宿主機(jī)層，根據(jù)應(yīng)用優(yōu)先級(jí)分配資源，保證重要應(yīng)用的資源充足，同時(shí)也可運(yùn)行低優(yōu)先級(jí)應(yīng)用。
• 打散性：應(yīng)用的打散主要是為了容災(zāi)，在這里分為不同級(jí)別的打散。我們提供了不同級(jí)別的打散粒度，包括宿主機(jī)、Tor、機(jī)房、Zone等等。
• 隔離與獨(dú)占：這是一類特殊的應(yīng)用，必須是獨(dú)立使用一臺(tái)宿主機(jī)或虛擬機(jī)隔離環(huán)境部署，例如搜索團(tuán)隊(duì)的業(yè)務(wù)。
• 特殊資源：特殊資源是滿足某些業(yè)務(wù)對(duì)GPU、SSD、特殊網(wǎng)卡等特殊硬件需求。

在線集群優(yōu)化

在線集群資源的優(yōu)化問題，不像離線集群那樣可以通過預(yù)知資源需求從而達(dá)到非常好的效果，由于未來需求的未知性，在線集群很難在資源排布上達(dá)到離線集群的效果。針對(duì)在線集群的問題，我們從上層調(diào)度到底層的資源使用都采取了一系列的優(yōu)化。

• Numa綁定：主要是解決業(yè)務(wù)側(cè)反饋服務(wù)不穩(wěn)定的問題，通過綁定Numa，將同一個(gè)應(yīng)用的CPU和Memory綁定到最合適的Numa Node上，減少跨Node訪問的開銷，提升應(yīng)用性能。
• CPU Set化：將一組特性互補(bǔ)的應(yīng)用綁定在同一組CPU上，從而讓他們能充分使用CPU資源。
• 應(yīng)用錯(cuò)峰：基于服務(wù)畫像數(shù)據(jù)為應(yīng)用錯(cuò)開高峰，減少資源競爭和相互干擾，提升業(yè)務(wù)SLA。
• 重調(diào)度：資源排布優(yōu)化，用更少的資源提升業(yè)務(wù)性能和SLA;解決碎片問題，提升資源的分配率。
• 干擾分析：基于業(yè)務(wù)監(jiān)控?cái)?shù)據(jù)指標(biāo)和容器信息判斷哪些容器有異常，提升業(yè)務(wù)SLA，發(fā)現(xiàn)并處理異常應(yīng)用。

結(jié)束語

當(dāng)前，在以下幾個(gè)方面我們正在積極探索：

• 在線-離線業(yè)務(wù)混合部署，進(jìn)一步提升資源使用效率。
• 智能化調(diào)度，業(yè)務(wù)流量和資源使用感知調(diào)度，提升服務(wù)SLA。
• 高性能、強(qiáng)隔離和更安全的容器技術(shù)。

作者簡介

國梁，美團(tuán)點(diǎn)評(píng)基礎(chǔ)研發(fā)平臺(tái)集群調(diào)度中心高級(jí)工程師。