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

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

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

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

兩個控制循環(huán)

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

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

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

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

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

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

問題1：高峰期的節(jié)點負載不均勻

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

未來的演進探討

更細粒度的資源域劃分

將資源域劃分至節(jié)點級別，節(jié)點級別加鎖來進行

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

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

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