調(diào)度系統(tǒng)的本質(zhì)是為計(jì)算服務(wù)/任務(wù)匹配合適的資源，使其能夠穩(wěn)定高效地運(yùn)行，以及在此的基礎(chǔ)上進(jìn)一步提高資源使用密度，而影響應(yīng)用運(yùn)行的因素非常多，比如CPU、內(nèi)存、io、差異化的資源設(shè)備等等一系列因素都會(huì)影響應(yīng)用運(yùn)行的表現(xiàn)。同時(shí)，單獨(dú)和整體的資源請(qǐng)求、硬件/軟件/策略限制、 親和性要求、數(shù)據(jù)區(qū)域、負(fù)載間的干擾等因素以及周期性流量場(chǎng)景、計(jì)算密集場(chǎng)景、在離線混合等不同的應(yīng)用場(chǎng)景的交織也帶來了決策上的多變。

調(diào)度器的目標(biāo)則是快速準(zhǔn)確地實(shí)現(xiàn)這一能力，但快速和準(zhǔn)確這兩個(gè)目標(biāo)在資源有限的場(chǎng)景下會(huì)往往產(chǎn)生產(chǎn)生矛盾，需要在二者間權(quán)衡。

調(diào)度器原理和設(shè)計(jì)

k8s默認(rèn)調(diào)度器的整體工作框架，可以簡(jiǎn)單用下圖概括：

兩個(gè)控制循環(huán)

1. 第一個(gè)控制循環(huán)，稱為 Informer Path。它的主要工作，是啟動(dòng)一系列的 Informer，用來監(jiān)聽（Watch）集群中 Pod、Node、Service 等與調(diào)度相關(guān)的 API 對(duì)象的變化。比如，當(dāng)一個(gè)待調(diào)度 Pod被創(chuàng)建出來之后，調(diào)度器就會(huì)通過 Pod Informer 的 Handler，將這個(gè)待調(diào)度 Pod 添加進(jìn)調(diào)度隊(duì)列；同時(shí)，調(diào)度器還要負(fù)責(zé)對(duì)調(diào)度器緩存Scheduler Cache進(jìn)行更新，并以這個(gè)cache為參考信息，來提高整個(gè)調(diào)度流程的性能。

2. 第二個(gè)控制循環(huán)，即為對(duì)pod進(jìn)行調(diào)度的主循環(huán)，稱為Scheduling Path。這一循環(huán)的工作流程是不斷地從調(diào)度隊(duì)列中取出待調(diào)度的pod，運(yùn)行2個(gè)步驟的算法，來選出最優(yōu)node
1. 在集群的所有節(jié)點(diǎn)中，選出所有“可以”運(yùn)行該pod的節(jié)點(diǎn)，這一步被稱為Predicates。
2. 在上一步選出的節(jié)點(diǎn)中，根據(jù)一些列優(yōu)選算法對(duì)節(jié)點(diǎn)就行打分，選出“最優(yōu)”即得分最高的節(jié)點(diǎn)，這一步被稱為Priorities。

調(diào)度完成之后，調(diào)度器就會(huì)為pod的spec.NodeName賦值這個(gè)節(jié)點(diǎn)，這一步稱為Bind。而為了不在主流程路徑中訪問Api Server影響性能，調(diào)度器只會(huì)更新Scheduler Cache中的相關(guān)pod和node信息：這種基于樂觀的假設(shè)的Api對(duì)象更新方式，在k8s中稱為Assume。之后才會(huì)創(chuàng)建一個(gè)goroutine來異步地向Api Server發(fā)起更新Bind操作，這一步就算失敗了也沒有關(guān)系，Scheduler Cache更新后就會(huì)一切正常。

大規(guī)模集群調(diào)度帶來的問題和挑戰(zhàn)

k8s默認(rèn)調(diào)度器策略在小規(guī)模集群下有著優(yōu)異的表現(xiàn)，但是隨著業(yè)務(wù)量級(jí)的增加以及業(yè)務(wù)種類的多樣性變化，默認(rèn)調(diào)度策略則逐漸顯露出了局限性：調(diào)度維度較少，無并發(fā)，存在性能瓶頸，以及調(diào)度器越來越復(fù)雜

迄今為止，我們當(dāng)前單個(gè)集群規(guī)模節(jié)點(diǎn)量千級(jí)，pod量級(jí)則在10w以上，整體資源分配率超過60%，其中更是包含了gpu，在離線混合部署等復(fù)雜場(chǎng)景；在這個(gè)過程中，我們遇到了不少調(diào)度方面的問題：

問題1：高峰期的節(jié)點(diǎn)負(fù)載不均勻

默認(rèn)調(diào)度器，參考的是workload的request值，如果我們針對(duì)request設(shè)置的過高，會(huì)帶來資源的浪費(fèi)；過低則有可能帶來高峰期cpu不均衡差異嚴(yán)重的情況；使用親和策略雖然可以一定程度避免這種，但是需要頻繁填充大量的策略，維護(hù)成本就會(huì)非常大。而且服務(wù)的request往往不能體現(xiàn)服務(wù)真實(shí)的負(fù)載，帶來差異誤差。而這種差異誤差，會(huì)在高峰時(shí)體現(xiàn)到節(jié)點(diǎn)負(fù)載不均上。

實(shí)時(shí)調(diào)度器，在調(diào)度的時(shí)候獲取各節(jié)點(diǎn)實(shí)時(shí)數(shù)據(jù)來參與節(jié)點(diǎn)打分，但是實(shí)際上實(shí)時(shí)調(diào)度在很多場(chǎng)景并不適用，尤其是對(duì)于具備明顯規(guī)律性的業(yè)務(wù)來說；比如我們大部分服務(wù)晚高峰流量是平時(shí)流量的幾十倍，高低峰資源使用差距劇大，而業(yè)務(wù)發(fā)版一般選擇低峰發(fā)版，采用實(shí)時(shí)調(diào)度器，往往發(fā)版的時(shí)候比較均衡，到晚高峰就出現(xiàn)節(jié)點(diǎn)間巨大差異，很多實(shí)時(shí)調(diào)度器，往往在出現(xiàn)巨大差異的時(shí)候會(huì)使用再平衡策略來重新調(diào)度，高峰時(shí)段對(duì)服務(wù)POD進(jìn)行遷移，服務(wù)高可用角度來考慮是不現(xiàn)實(shí)的。顯然實(shí)時(shí)調(diào)度是遠(yuǎn)遠(yuǎn)無法滿足業(yè)務(wù)場(chǎng)景的。

我們的方案：高峰預(yù)測(cè)時(shí)調(diào)度

所以針對(duì)這種情況，需要預(yù)測(cè)性調(diào)度，根據(jù)以往高峰時(shí)候cpu、IO、網(wǎng)絡(luò)、日志等資源的使用量，通過對(duì)服務(wù)在節(jié)點(diǎn)上進(jìn)行最優(yōu)排列組合回歸測(cè)算，得到各個(gè)服務(wù)和資源的權(quán)重系數(shù)，基于資源的權(quán)重打分?jǐn)U展，也就是使用過去高峰數(shù)據(jù)來預(yù)測(cè)未來高峰節(jié)點(diǎn)服務(wù)使用量，從而干預(yù)調(diào)度節(jié)點(diǎn)打分結(jié)果。

問題2：調(diào)度維度多樣化

隨著業(yè)務(wù)越來越多樣性，需要加入更多的調(diào)度維度，比如日志。由于采集器不可能無限速率采集日志且日志采集是基于節(jié)點(diǎn)維度。需要將平衡日志采集速率，不能各個(gè)節(jié)點(diǎn)差異過大。部分服務(wù)cpu使用量一般但是日志輸出量很大；而日志并不屬于默認(rèn)調(diào)度器決策的一環(huán)，所以當(dāng)這些日志量很大的服務(wù)多個(gè)服務(wù)的pod在同一個(gè)節(jié)點(diǎn)上的時(shí)候，該機(jī)器上的日志上報(bào)就有可能出現(xiàn)部分延遲。

我們的方案：補(bǔ)全調(diào)度決策因子

該問題顯然需要我們對(duì)調(diào)度決策補(bǔ)全，我們擴(kuò)展了預(yù)測(cè)調(diào)度打分策略，添加了日志的決策因子，將日志也作為節(jié)點(diǎn)的一種資源，并根據(jù)歷史監(jiān)控獲取到服務(wù)對(duì)應(yīng)的日志使用量來計(jì)算分?jǐn)?shù)

問題3：大批量服務(wù)擴(kuò)縮導(dǎo)帶來的調(diào)度時(shí)延

隨著業(yè)務(wù)的復(fù)雜度進(jìn)一步上升，在高峰時(shí)段出現(xiàn)，會(huì)有大量定時(shí)任務(wù)和集中大量彈性擴(kuò)縮，大批量（上千POD）同時(shí)調(diào)度導(dǎo)致調(diào)度時(shí)延的上漲，這兩者對(duì)調(diào)度時(shí)間比較敏感，尤其對(duì)于定時(shí)任務(wù)來說，調(diào)度延時(shí)的上漲會(huì)被明顯感知到。原因是k8s調(diào)度pod本身是對(duì)集群資源的分配，反應(yīng)在調(diào)度流程上則是預(yù)選和打分階段是順序進(jìn)行的；如此一來，當(dāng)集群規(guī)模大到一定程度的時(shí)候，大批量更新就會(huì)出現(xiàn)可感知到的pod調(diào)度延遲。

我們的方案：拆分任務(wù)調(diào)度器，加大并發(fā)調(diào)度域、批量調(diào)度

解決吞吐能力低下的最直接的方法就是串行改并行，對(duì)于資源搶占場(chǎng)景，盡量細(xì)化資源域，資源域之間并行。給予以上策略，我們拆分出了獨(dú)立的job調(diào)度器，同時(shí)使用了serverless作為job運(yùn)行的底層資源。k8s serverless為每一個(gè)JOB POD，單獨(dú)申請(qǐng)了獨(dú)立的POD運(yùn)行sanbox，也就是任務(wù)調(diào)度器，是完整并行。

對(duì)比圖：
原生調(diào)度器在晚高峰下節(jié)點(diǎn)CPU使用率

優(yōu)化后調(diào)度器在晚高峰下節(jié)點(diǎn)CPU使用率

總結(jié)

work節(jié)點(diǎn)資源、gpu資源、serverless資源這就是我們集群異構(gòu)資源分屬于這三類資源域，這三種資源上運(yùn)行的服務(wù)存在天然的差異性，我們使用forecast-scheduler、gpu-scheduler、job-schedule 三個(gè)調(diào)度器來管理這三種資源域上的pod的調(diào)度情況。

預(yù)測(cè)調(diào)度器管理大部分在線業(yè)務(wù)，其中擴(kuò)展了資源維度，添加了預(yù)測(cè)打分策略。

gpu調(diào)度器管理gpu資源機(jī)器的分配，運(yùn)行在線推理和離線訓(xùn)練，兩者的比例處于長(zhǎng)期波動(dòng)中，高峰期間離線訓(xùn)練縮容、在線推理擴(kuò)容；非高峰期間離線訓(xùn)練擴(kuò)容、在線推理縮容；同時(shí)處理一些離線圖片處理任務(wù)來復(fù)用gpu機(jī)器上比較空閑的cpu等資源。

job調(diào)度器負(fù)責(zé)管理我們定時(shí)任務(wù)的調(diào)度，定時(shí)任務(wù)量大且創(chuàng)建銷毀頻繁，資源使用非常碎片化，而且對(duì)實(shí)效性要求更高；所以我們將任務(wù)盡量調(diào)度到serverless服務(wù)上，壓縮集群中為了能容納大量的任務(wù)而冗余的機(jī)器資源，提升資源利用率。

未來的演進(jìn)探討

更細(xì)粒度的資源域劃分

將資源域劃分至節(jié)點(diǎn)級(jí)別，節(jié)點(diǎn)級(jí)別加鎖來進(jìn)行

資源搶占和重調(diào)度

正常場(chǎng)景下，當(dāng)一個(gè)pod調(diào)度失敗的時(shí)候，這個(gè)pod會(huì)保持在pending的狀態(tài)，等待pod更新或者集群資源發(fā)生變化進(jìn)行重新調(diào)度，但是k8s調(diào)度器依然存在一個(gè)搶占功能，可以使得高優(yōu)先級(jí)pod在調(diào)度失敗的時(shí)候，擠走某個(gè)節(jié)點(diǎn)上的部分低優(yōu)先級(jí)pod以保證高優(yōu)pod的正常，迄今為止我們并沒有使用調(diào)度器的搶占能力，即使我們通過以上多種策略來加強(qiáng)調(diào)度的準(zhǔn)確性，但依然無法避免部分場(chǎng)景下由于業(yè)務(wù)帶來的不均衡情況，這種非正常場(chǎng)景中，重調(diào)度的能力就有了用武之地，也許重調(diào)度將會(huì)成為日后針對(duì)異常場(chǎng)景的一種自動(dòng)修復(fù)的方式。

正常場(chǎng)景下，當(dāng)一個(gè)pod調(diào)度失敗的時(shí)候，這個(gè)pod會(huì)保持在pending的狀態(tài)，等待pod更新或者集群資源發(fā)生變化進(jìn)行重新調(diào)度，但是k8s調(diào)度器依然存在一個(gè)搶占功能，可以使得高優(yōu)先級(jí)pod在調(diào)度失敗的時(shí)候，擠走某個(gè)節(jié)點(diǎn)上的部分低優(yōu)先級(jí)pod以保證高優(yōu)pod的正常，迄今為止我們并沒有使用調(diào)度器的搶占能力，即使我們通過以上多種策略來加強(qiáng)調(diào)度的準(zhǔn)確性，但依然無法避免部分場(chǎng)景下由于業(yè)務(wù)帶來的不均衡情況，這種非正常場(chǎng)景中，重調(diào)度的能力就有了用武之地，也許重調(diào)度將會(huì)成為日后針對(duì)異常場(chǎng)景的一種自動(dòng)修復(fù)的方式。