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

調度器的目標則是快速準確地實現這一能力，但快速和準確這兩個目標在資源有限的場景下會往往產生產生矛盾，需要在二者間權衡。

調度器原理和設計

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

兩個控制循環

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

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

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

大規模集群調度帶來的問題和挑戰

k8s默認調度器策略在小規模集群下有著優異的表現，但是隨著業務量級的增加以及業務種類的多樣性變化，默認調度策略則逐漸顯露出了局限性：調度維度較少，無并發，存在性能瓶頸，以及調度器越來越復雜

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

問題1：高峰期的節點負載不均勻

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

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

我們的方案：高峰預測時調度

所以針對這種情況，需要預測性調度，根據以往高峰時候cpu、IO、網絡、日志等資源的使用量，通過對服務在節點上進行最優排列組合回歸測算，得到各個服務和資源的權重系數，基于資源的權重打分擴展，也就是使用過去高峰數據來預測未來高峰節點服務使用量，從而干預調度節點打分結果。

問題2：調度維度多樣化

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

我們的方案：補全調度決策因子

該問題顯然需要我們對調度決策補全，我們擴展了預測調度打分策略，添加了日志的決策因子，將日志也作為節點的一種資源，并根據歷史監控獲取到服務對應的日志使用量來計算分數

問題3：大批量服務擴縮導帶來的調度時延

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

我們的方案：拆分任務調度器，加大并發調度域、批量調度

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

對比圖：
原生調度器在晚高峰下節點CPU使用率

優化后調度器在晚高峰下節點CPU使用率

總結

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

預測調度器管理大部分在線業務，其中擴展了資源維度，添加了預測打分策略。

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

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

未來的演進探討

更細粒度的資源域劃分

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

資源搶占和重調度

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

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