![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/9b9dafd37c6a4c21987654d93991da05.png)

作者 | 王慶璨（阿里雲技術專家）、張凱（阿里雲高階技術專家）

**導讀：**阿里雲容器服務團隊結合多年 Kubernetes 產品與客戶支援經驗，對 Kube-scheduler 進行了大量最佳化和擴充套件，逐步使其在不同場景下依然能穩定、高效地排程各種型別的複雜工作負載。《進擊的 Kubernetes 排程系統》系列文章將把我們的經驗、技術思考和實現細節全面地展現給 Kubernetes 使用者和開發者，期望幫助大家更好地瞭解 Kubernetes 排程系統的強大能力和未來發展方向。

# 前言

Kubernetes 已經成為目前事實標準上的容器叢集管理平臺。它為容器化應用提供了自動化部署、運維、資源排程等全生命週期管理功能。經過 3 年多的快速發展，Kubernetes 在穩定性、擴充套件性和規模化方面都有了長足進步。尤其是 Kubernetes 控制平面的核心元件日臻成熟。而作為決定容器能否在叢集中執行的排程器 Kube-scheduler，更是由於長久以來表現穩定，且已能滿足大部分 Pod 排程場景，逐漸不被開發人員特別關注。

伴隨著 Kubernetes 在公有云以及企業內部 IT 系統中廣泛應用，越來越多的開發人員嘗試使用 Kubernetes 執行和管理 Web 應用和微服務以外的工作負載。典型場景包括機器學習和深度學習訓練任務，高效能運算作業，基因計算工作流，甚至是傳統的大資料處理任務。**此外，Kubernetes 叢集所管理的資源型別也愈加豐富，不僅有 GPU，TPU 和 FPGA，RDMA 高效能網路，還有針對領域任務的各種定製加速器，比如各種 AI 晶片，NPU，影片編解碼器等。開發人員希望在 Kubernetes 叢集中能像使用 CPU 記憶體那樣簡單地宣告和使用各種異構裝置。**

總的來說，圍繞 Kubernetes 構建一個容器服務平臺，統一管理各種新算力資源，彈性執行多種型別應用，最終把服務按需交付到各種執行環境（包括公共雲、資料中心、邊緣節點，甚至是終端裝置），已然成為雲原生技術的發展趨勢。

## 早期方案

首先，讓我們來了解一下 Kubernetes 社群都有過哪些提升排程器擴充套件能力的方案。

要統一管理和排程異構資源與更多複雜工作負載型別，首先面對挑戰的就是 Kube-scheduler。在 Kubernetes 社群裡關於提升排程器擴充套件能力的討論一直不斷。sig-scheduling 給出的判斷是，越多功能加入，使得排程器程式碼量龐大，邏輯複雜，導致維護的難度越來越大，很多 bug 難以發現、處理。而對於使用了自定義排程的使用者來說，跟上每一次排程器功能更新，都充滿挑戰。

在阿里雲，我們的使用者遇到了同樣的挑戰。Kubernetes 原生排程器迴圈處理單個 Pod 容器的固定排程邏輯，無法及時的支援不同使用者在不同場景的需求。所以針對特定的場景，我們會基於原生的 Kube-scheduler 擴充套件自己場景的排程策略。

最初對於 Kube-scheduler 進行擴充套件的方式主要有兩種，一種是排程器擴充套件（Scheduler Extender）， 另外一種是多排程器（Multiple schedulers）。接下來我們對這兩種方式分別進行介紹和對比。

### 1）Scheduler Extender

社群最初提供的方案是透過 Extender 的形式來擴充套件 scheduler。Extender 是外部服務，支援 Filter、Preempt、Prioritize 和 Bind 的擴充套件，scheduler 執行到相應階段時，透過呼叫 Extender 註冊的 webhook 來執行擴充套件的邏輯，影響排程流程中各階段的決策結果。

以 Filter 階段舉例，執行過程會經過 2 個階段:

1. scheduler 會先執行內建的Filter策略，如果執行失敗的話，會直接標識 Pod 排程失敗；
2. 如何內建的 Filter 策略執行成功的話，scheduler 透過 Http 呼叫 Extender 註冊的 webhook, 將排程所需要的 Pod 和 Node 的資訊傳送到 Extender，根據返回 filter 結果，作為最終結果。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/5179aad825894c66b69d36d4d4d15dce.jpg)

我們可以發現 Extender 存在以下問題:

1. 呼叫 Extender 的介面是 HTTP 請求，受到網路環境的影響，效能遠低於本地的函式呼叫。同時每次呼叫都需要將 Pod 和 Node 的資訊進行 marshaling 和 unmarshalling 的操作，會進一步降低效能；
2. 使用者可以擴充套件的點比較有限，位置比較固定，無法支援靈活的擴充套件，例如只能在執行完預設的 Filter 策略後才能呼叫。

基於以上介紹，Extender 的方式在叢集規模較小，排程效率要求不高的情況下，是一個靈活可用的擴充套件方案，但是在正常生產環境的大型叢集中，Extender 無法支援高吞吐量，效能較差。

### 2）Multiple schedulers

Scheduler 在 Kubernetes 叢集中其實類似於一個特殊的 Controller，透過監聽 Pod 和 Node 的資訊，給 Pod 挑選最佳的節點，更新 Pod 的 spec.NodeName 的資訊來將排程結果同步到節點。所以對於部分有特殊的排程需求的使用者，有些開發者透過自研 Custom Scheduler 來完成以上的流程，然後透過和 default scheduler 同時部署的方式，來支援自己特殊的排程需求。

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/2d863601b0974e738ebf784d6f31a632.jpg)

Custom Scheduler 會存在一下問題：

1. 如果與 default scheduler 同時部署，因為每個排程器所看到的資源檢視都是全域性的，所以在排程決策中可能會在同一時刻在同一個節點資源上排程不同的 Pod，導致節點資源衝突的問題；
2. 有些使用者將排程器所能排程的資源透過 Label 劃分不同的池子，可以避免資源衝突的現象出現。但是這樣又會導致整體叢集資源利用率的下降；
3. 有些使用者選擇透過完全自研的方式來替換 default scheduler，這種會帶來比較高的研發成本，以及 Kubernetes 版本升級後可能存在的相容性問題。

Scheduler Extender 的效能較差可是維護成本較小，Custom Scheduler 的研發和維護的成本特別高但是效能較好，這種情況是開發者面臨這種兩難處境。這時候 Kubernetes Scheduling Framework V2 橫空出世，給我們帶來魚和熊掌可以兼得的方案。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/1b314ec8ffa94db6aa097ccb60324fd6.png)

# 新一代排程框架 Scheduling Framework 之解析

社群也逐漸的發現開發者所面臨的困境，為了解決如上問題，使 Kube-scheduler 擴充套件性更好、程式碼更簡潔，社群從 Kubernetes 1.16 版本開始, 構建了一種新的排程框架 Kubernetes Scheduling Framework 的機制。

Scheduling Framework 在原有的排程流程中, 定義了豐富擴充套件點介面，開發者可以透過實現擴充套件點所定義的介面來實現外掛，將外掛註冊到擴充套件點。Scheduling Framework 在執行排程流程時，執行到相應的擴充套件點時，會呼叫使用者註冊的外掛，影響排程決策的結果。透過這種方式來將使用者的排程邏輯整合到 Scheduling Framework 中。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/fa5d2985b7654fa4afe5624457225c22.jpg)

Framework 的排程流程是分為兩個階段 scheduling cycle 和 binding cycle。

- scheduling cycle 是同步執行的，同一個時間只有一個 scheduling cycle，是執行緒安全的；
- binding cycle 是非同步執行的，同一個時間中可能會有多個 binding cycle在執行，是執行緒不安全的。

## 1. scheduling cycle

scheduling cycle 是排程的核心流程，主要的工作是進行排程決策，挑選出唯一的節點。

### 1）Queue sort

```
// QueueSortPlugin is an interface that must be implemented by "QueueSort" plugins.
// These plugins are used to sort pods in the scheduling queue. Only one queue sort
// plugin may be enabled at a time.
type QueueSortPlugin interface {
    Plugin
    // Less are used to sort pods in the scheduling queue.
    Less(*PodInfo, *PodInfo) bool
}
```

Scheduler 中的優先順序佇列是透過 heap 實現的，我們可以在 QueueSortPlugin 中定義 heap 的比較函式來決定的排序結構。但是需要注意的是 heap 的比較函式在同一時刻只有一個，所以 QueueSort 外掛只能 Enable 一個，如果使用者 Enable 了 2 個則排程器啟動時會報錯退出。下面是預設的比較函式，可供參考。

```
// Less is the function used by the activeQ heap algorithm to sort pods.
// It sorts pods based on their priority. When priorities are equal, it uses
// PodQueueInfo.timestamp.
func (pl *PrioritySort) Less(pInfo1, pInfo2 *framework.QueuedPodInfo) bool {
    p1 := pod.GetPodPriority(pInfo1.Pod)
    p2 := pod.GetPodPriority(pInfo2.Pod)
    return (p1 > p2) || (p1 == p2 && pInfo1.Timestamp.Before(pInfo2.Timestamp))
}
```

### 2）PreFilter

PreFilter 在 scheduling cycle 開始時就被呼叫，只有當所有的 PreFilter 外掛都返回 success 時，才能進入下一個階段，否則 Pod 將會被拒絕掉，標識此次排程流程失敗。PreFilter 類似於排程流程啟動之前的預處理，可以對 Pod 的資訊進行加工。同時 PreFilter 也可以進行一些預置條件的檢查，去檢查一些叢集維度的條件，判斷否滿足 pod 的要求。

### 3）Filter

Filter 外掛是 scheduler v1 版本中的 Predicate 的邏輯，用來過濾掉不滿足 Pod 排程要求的節點。為了提升效率，Filter 的執行順序可以被配置，這樣使用者就可以將可以過濾掉大量節點的 Filter 策略放到前邊執行，從而減少後邊 Filter 策略執行的次數，例如我們可以把 NodeSelector 的 Filter 放到第一個，從而過濾掉大量的節點。Node 節點執行 Filter 策略是併發執行的，所以在同一排程週期中多次呼叫過濾器。

### 4）PostFilter

新的 PostFilter 的介面定義在 1.19 的版本會發布，主要是用於處理當 Pod 在 Filter 階段失敗後的操作，例如搶佔，Autoscale 觸發等行為。

### 5）PreScore

PreScore 在之前版本稱為 PostFilter，現在修改為 PreScore，主要用於在 Score 之前進行一些資訊生成。此處會獲取到透過 Filter 階段的節點列表，我們也可以在此處進行一些資訊預處理或者生成一些日誌或者監控資訊。

### 6）Scoring

Scoring 擴充套件點是 scheduler v1 版本中 Priority 的邏輯，目的是為了基於 Filter 過濾後的剩餘節點，根據 Scoring 擴充套件點定義的策略挑選出最優的節點。Scoring 擴充套件點分為兩個階段：

- 打分：打分階段會對 Filter 後的節點進行打分，scheduler 會呼叫所配置的打分策略
- 歸一化: 對打分之後的結構在 0-100 之間進行歸一化處理

### 7）Reserve

Reserve 擴充套件點是 scheduler v1 版本的 assume 的操作，此處會對排程結果進行快取，如果在後邊的階段發生了錯誤或者失敗的情況，會直接進入 Unreserve 階段，進行資料回滾。

### 8）Permit

Permit 擴充套件點是 framework v2 版本引入的新功能，當 Pod 在 Reserve 階段完成資源預留之後，Bind 操作之前，開發者可以定義自己的策略在 Permit 節點進行攔截，根據條件對經過此階段的 Pod 進行 allow、reject 和 wait 的 3 種操作。allow 表示 pod 允許透過 Permit 階段。reject 表示 pod 被 Permit 階段拒絕，則 Pod 排程失敗。wait 表示將 Pod 處於等待狀態，開發者可以設定超時時間。

## 2. binding cycle

binding cycle 需要呼叫 apiserver 的介面，耗時較長，為了提高排程的效率，需要非同步執行，所以此階段執行緒不安全。

### 1）Bind

Bind 擴充套件點是 scheduler v1 版本中的 Bind 操作，會呼叫 apiserver 提供的介面，將 pod 繫結到對應的節點上。

### 2）PreBind 和 PostBind

開發者可以在 PreBind 和 PostBind 分別在 Bind 操作前後執行，這兩個階段可以進行一些資料資訊的獲取和更新。

### 3）UnReserve

UnReserve 擴充套件點的功能是用於清理到 Reserve 階段的的快取，回滾到初始的狀態。當前版本 UnReserve 與 Reserve 是分開定義的，未來會將 UnReserve 與 Reserve 統一到一起，即要求開發者在實現 Reserve 同時需要定義 UnReserve，保證資料能夠有效的清理，避免留下髒資料。

# 實現自己的排程外掛

## scheduler-plugins

Kubernetes 負責 Kube-scheduler 的小組 sig-scheduling 為了更好的管理排程相關的 Plugin，新建了專案 scheduler-plugins 來方便使用者管理不同的外掛，使用者可以直接基於這個專案來定義自己的外掛。接下來我們以其中的 Qos 的外掛來為例，演示是如何開發自己的外掛。

Qos 的外掛主要基於 Pod 的 QoS(Quality of Service) class 來實現的，目的是為了實現排程過程中如果 Pod 的優先順序相同時，根據 Pod 的 Qos 來決定排程順序，排程順序是: 1. Guaranteed (requests == limits) 2. Burstable (requests < limits) 3. BestEffort (requests and limits not set)

### 1）外掛構造

首先外掛要定義外掛的物件和建構函式：

```
// QoSSort is a plugin that implements QoS class based sorting.
type Sort struct{}
// New initializes a new plugin and returns it.
func New(_ *runtime.Unknown, _ framework.FrameworkHandle) (framework.Plugin, error) {
    return &Sort{}, nil
}
```

然後，根據我們外掛要對應的 extention point 來實現對應的介面，Qos 是作用於 QueueSort 的部分，所以我們要實現 QueueSort 介面的函式。如下所示，QueueSortPlugin 介面只定義了一個函式 Less，所以我們實現這個函式即可。

```
// QueueSortPlugin is an interface that must be implemented by "QueueSort" plugins.
// These plugins are used to sort pods in the scheduling queue. Only one queue sort
// plugin may be enabled at a time.
type QueueSortPlugin interface {
    Plugin
    // Less are used to sort pods in the scheduling queue.
    Less(*PodInfo, *PodInfo) bool
}
```

實現的函式如下。預設的 default QueueSort 在比較的時候，首先比較優先順序，然後再比較 pod 的 timestamp。我們重新定義了 Less 函式，在優先順序相同的情況下，透過比較 Qos 來決定優先順序。

```
// Less is the function used by the activeQ heap algorithm to sort pods.
// It sorts pods based on their priority. When priorities are equal, it uses
// PodInfo.timestamp.
func (*Sort) Less(pInfo1, pInfo2 *framework.PodInfo) bool {
    p1 := pod.GetPodPriority(pInfo1.Pod)
    p2 := pod.GetPodPriority(pInfo2.Pod)
    return (p1 > p2) || (p1 == p2 && compQOS(pInfo1.Pod, pInfo2.Pod))
}
func compQOS(p1, p2 *v1.Pod) bool {
    p1QOS, p2QOS := v1qos.GetPodQOS(p1), v1qos.GetPodQOS(p2)
    if p1QOS == v1.PodQOSGuaranteed {
        return true
    } else if p1QOS == v1.PodQOSBurstable {
        return p2QOS != v1.PodQOSGuaranteed
    } else {
        return p2QOS == v1.PodQOSBestEffort
    }
}
```

### 2）外掛註冊

我們在啟動的 main 函式中註冊自己定義的外掛和相應的建構函式：

```
// cmd/main.go
func main() {
    rand.Seed(time.Now().UnixNano())
    command := app.NewSchedulerCommand(
        app.WithPlugin(qos.Name, qos.New),
    )
    if err := command.Execute(); err != nil {
        os.Exit(1)
    }
}
```

### 3）程式碼編譯

```
$ make
```

### 4）Scheduler 啟動

kube-scheduler 啟動時，配置 ./manifests/qos/scheduler-config.yaml 中 kubeconfig 的路徑，啟動時傳入叢集的 kubeconfig 檔案以及外掛的配置檔案即可。

```
$ bin/kube-scheduler --kubeconfig=scheduler.conf --config=./manifests/qos/scheduler-config.yaml
```

至此，相信大家已經透過我們的介紹和示例瞭解了 Kubernetes Scheduling Framework 的架構和開發方法。

# 後續工作

Kubernetes Scheduling Framework 作為排程器的新架構方向，在可擴充套件性和定製化方面進步很大。基於此 Kubernetes 可以逐步承載更多型別的應用負載了, 一個平臺一套 IT 架構和技術堆疊的願景向前演進。同時為了更好的支援資料計算型別的任務遷移到 Kubernetes 平臺中，我們也在努力將資料計算型別中常用Coscheduling／Gang Scheduling、Capacity Scheduling、Dominant Resource Fairness 和多佇列管理等特性，透過 Scheduling Framework 的外掛機制來融入到原生的 Kube-scheduler 中。接下來，本系列文章將圍繞 AI、大資料處理和高規格計算資源叢集等場景，介紹我們是如何開發相應排程器外掛的。敬請期待！

## 體驗有禮：5 分鐘極速上手 Serverless

“Serverless” 近年來非常火爆。人人都熱衷於探討它出現的意義，但對於如何上手使用或在生產環境落地，卻談之甚少。我們設計了體驗場景，手把手帶你 5 分鐘上手 Serverless，還送 2000 個阿里雲“第一行程式碼”鎏金限量馬克杯！

**點選檢視詳情**：[https://developer.aliyun.com/adc/series/fc/](https://developer.aliyun.com/adc/series/fc/)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491754&idx=2&sn=d99ac17dbec045a6333aad258e561ed2&chksm=fae6eb65cd9162735a6b175a0d53a0858bf3c74f134579e21581cde0faf0bbb5d48432a4424f&token=513817799&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

進擊的 Kubernetes 排程系統（一）：Kubernetes scheduling framework

相關文章