作者 | 呂亞霖
策劃 | 趙鈺瑩
排程系統的本質是為計算服務或任務匹配合適的資源，使其能夠穩定高效地執行，以及在此基礎上進一步提高資源使用密度，而影響應用執行的因素非常多，比如 CPU、記憶體、IO、差異化的資源裝置等一系列因素都會影響應用執行的表現。同時，單獨和整體的資源請求、硬體 / 軟體 / 策略限制、 親和性要求、資料區域、負載間的干擾等因素以及週期性流量場景、計算密集場景、在離線混合等不同應用場景的交織也帶來了決策上的很多變化。
排程器的目標則是快速準確地實現這一能力，但快速和準確這兩個目標在資源有限的場景下往往會產生矛盾，這需要在二者間權衡，本文主要分享了作業幫在實際應用 K8s 過程中遇到的問題以及最終探討出的解決方案，希望對廣大開發者有所幫助。
1
排程器原理和設計
K8s 預設排程器的整體工作框架可以簡單用下圖概括：
兩個控制迴圈
1、第一個控制迴圈稱為 Informer Path，主要工作是啟動一系列 Informer，用來監聽（Watch）叢集中 Pod、Node、Service 等與排程相關的 API 物件的變化。比如，當一個待排程 Pod 被創建出來之後，排程器就會透過 Pod Informer 的 Handler，將這個待排程 Pod 新增進排程佇列；同時，排程器還要負責對排程器快取 Scheduler Cache 進行更新，並以這個 cache 為參考資訊，來提高整個排程流程的效能。
2、第二個控制迴圈即為對 pod 進行排程的主迴圈，稱為 Scheduling Path。這一迴圈的工作流程是不斷地從排程佇列中取出待排程的 pod，執行兩個步驟的演算法，來選出最優 node
在叢集的所有節點中選出所有“可以”執行該 pod 的節點，這一步被稱為 Predicates；
在上一步選出的節點中，根據一系列優選演算法對節點打分，選出“最優”即得分最高的節點，這一步被稱為 Priorities。
排程完成之後，排程器就會為 pod 的 spec。NodeName 賦值這個節點，這一步稱為 Bind。而為了不在主流程路徑中訪問 Api Server 影響效能，排程器只會更新 Scheduler Cache 中的相關 pod 和 node 資訊：這種基於樂觀假設的 API 物件更新方式，在 K8s 中稱為 Assume。之後才會建立一個 goroutine 來非同步地向 API Server 發起更新 Bind 操作，這一步就算失敗了也沒有關係，Scheduler Cache 更新後就會一切正常。
2
大規模叢集排程帶來的問題和挑戰
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 使用率
3
總結
Work 節點資源、GPU 資源、Serverless 資源是我們叢集異構資源的三類資源域，這三種資源上執行的服務存在天然差異，我們使用 forecast-scheduler、gpu-scheduler、job-schedule 三個排程器來管理這三種資源域上的 Pod 排程情況。
預測排程器管理大部分線上業務，其中擴充套件了資源維度，添加了預測打分策略。
GPU 排程器管理 GPU 資源機器的分配，執行線上推理和離線訓練，兩者的比例處於長期波動中，高峰期間離線訓練縮容、線上推理擴容；非高峰期間離線訓練擴容、線上推理縮容；同時處理一些離線圖片任務來複用 GPU 機器上比較空閒的 CPU 等資源。
Job 排程器負責管理定時任務排程，定時任務量大且建立銷燬頻繁，資源使用非常碎片化，而且對時效性要求更高；所以我們將任務儘量排程到 Serverless 服務上，壓縮叢集中為了能容納大量任務而冗餘的機器資源，提升資源利用率。
4
未來演進探討
更細粒度的資源域劃分，將資源域劃分至節點級別，節點級別加鎖來進行。
資源搶佔和重排程。正常場景下，當一個 Pod 排程失敗，這個 Pod 會保持在 pending 的狀態，等待 Pod 更新或者叢集資源發生變化進行重新排程，但是 K8s 排程器依然存在一個搶佔功能，可以使得高優先順序 Pod 在排程失敗時，擠走某個節點上的部分低優先順序 Pod 以保證高優先順序 Pod 的正常執行，迄今為止我們並沒有使用排程器的搶佔能力，即使我們透過以上多種策略來加強排程的準確性，但依然無法避免部分場景下由於業務帶來的不均衡情況，這種非正常場景中，重排程的能力就有了用武之地，也許重排程將會成為日後針對異常場景的一種自動修復方式。
作者介紹：
呂亞霖，作業幫基礎架構 - 架構研發團隊負責人。2019 年加入作業幫，負責技術中臺和基礎架構工作。在作業幫期間主導了雲原生架構演進、推動實施容器化改造、服務治理、GO 微服務框架、DevOps 的落地實踐。
