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

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

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

# 前言

什麼是 Coscheduling 和 Gang scheduling。Wikipedia 對 [Coscheduling](https://en.wikipedia.org/wiki/Coscheduling) 的定義是“在併發系統中將多個相關聯的程式排程到不同處理器上同時執行的策略”。在 Coscheduling 的場景中，最主要的原則是保證所有相關聯的程式能夠同時啟動。防止部分程式的異常，導致整個關聯程式組的阻塞。這種導致阻塞的部分異常程式，稱之為“碎片（fragement）”。

在 Coscheduling 的具體實現過程中，根據是否允許“碎片”存在，可以細分為 Explicit Coscheduling，Local Coscheduling 和 Implicit Coscheduling。 其中 Explicit Coscheduling 就是大家常聽到的 [Gang Scheduling](https://en.wikipedia.org/wiki/Gang_scheduling)。Gang Scheduling 要求完全不允許有“碎片”存在， 也就是“All or Nothing”。

我們將上述定義的概念對應到 Kubernetes 中，就可以理解 Kubernetes 排程系統支援批任務 Coscheduling 的含義了。 一個批任務（關聯程式組）包括了 N 個 Pod（程式），Kubernetes 排程器負責將這 N 個 Pod 排程到 M 個節點（處理器）上同時執行。如果這個批任務需要部分 Pod 同時啟動即可執行，我們稱需啟動 Pod 的最小數量為 min-available。特別地，當 min-available=N 時，批任務要求滿足 Gang Scheduling。

# 為什麼 Kubernetes 排程系統需要 Coscheduling？

Kubernetes 目前已經廣泛的應用於線上服務編排，為了提升叢集的的利用率和執行效率，我們希望將 Kubernetes 作為一個統一的管理平臺來管理線上服務和離線作業。預設的排程器是以 Pod 為排程單元進行依次排程，不會考慮 Pod 之間的相互關係。但是很多資料計算類的離線作業具有組合排程的特點，即要求所有的子任務都能夠成功建立後，整個作業才能正常執行。如果只有部分子任務啟動的話，啟動的子任務將持續等待剩餘的子任務被排程。這正是 Gang Scheduling 的場景。

如下圖所示，JobA 需要 4 個 Pod 同時啟動，才能正常執行。Kube-scheduler 依次排程 3 個 Pod 並建立成功。到第 4 個 Pod 時，叢集資源不足，則 JobA 的 3 個 Pod 處於空等的狀態。但是它們已經佔用了部分資源，如果第 4 個 Pod 不能及時啟動的話，整個 JobA 無法成功執行，更糟糕的是導致叢集資源浪費。

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

如果出現更壞的情況的話，如下圖所示，叢集其他的資源剛好被 JobB 的 3 個 Pod 所佔用，同時在等待 JobB 的第 4 個 Pod 建立，此時整個叢集就出現了死鎖。

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

# 社群相關的方案

社群目前有 Kube-batch 以及基於 Kube-batch 衍生的 Volcano 2 個專案來解決上文中提到的痛點。實現的方式是透過開發新的排程器將 Scheduler 中的排程單元從 Pod 修改為 PodGroup，以組的形式進行排程。使用方式是如果需要 Coscheduling 功能的 Pod 走新的排程器，其他的例如線上服務的 Pod 走 Kube-scheduler 進行排程。

這些方案雖然能夠解決 Coscheduling 的問題，但是同樣引入了新的問題。如大家所知，對於同一叢集資源，排程器需要中心化。但如果同時存在兩個排程器的話，有可能會出現決策衝突，例如分別將同一塊資源分配給兩個不同的 Pod，導致某個 Pod 排程到節點後因為資源不足，導致無法建立的問題。解決的方式只能是透過標籤的形式將節點強行的劃分開來，或者部署多個叢集。這種方式透過同一個 Kubernetes 叢集來同時執行線上服務和離線作業，勢必會導致整體叢集資源的浪費以及運維成本的增加。再者，Volcano 執行需要啟動定製的 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。這些 Webhooks 本身存在單點風險，一旦出現故障，將影響叢集內所有 pod 的建立。另外，多執行一套排程器，本身也會帶來維護上的複雜性，以及與上游 Kube-scheduler 介面相容上的不確定性。

# 基於 Scheduling Framework 的方案

《[進擊的 Kubernetes 排程系統 （一）：Scheduling Framework ](https://mp.weixin.qq.com/s/UkVXuZU0E0LT3LaDdZG4Xg)》介紹了 Kubernetes Scheduling Framework 的架構原理和開發方法。在此基礎上，我們擴充套件實現了 Coscheduling 排程外掛，幫助 Kubernetes 原生排程器支援批作業排程，同時避免上述方案存在的問題。Scheduling framework 的內容在前一篇文章詳細介紹，歡迎大家翻閱。

Kubernetes 負責 Kube-scheduler 的小組 sig-scheduler 為了更好的管理排程相關的 Plugin，新建了專案 [scheduler-plugins](https://github.com/kubernetes-sigs/scheduler-plugins) 管理不同場景的 Plugin。我們基於 scheduling framework 實現的 Coscheduling Plugin 成為該專案的第一個官方外掛，下面我將詳細的介紹 Coscheduling Plugin 的實現和使用方式。

## 技術方案

### 總體架構

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

#### PodGroup

我們透過 label 的形式來定義 PodGroup 的概念，擁有同樣 label 的 Pod 同屬於一個 PodGroup。min-available 是用來標識該 PodGroup 的作業能夠正式執行時所需要的最小副本數。

```
labels:
     pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
     pod-group.scheduling.sigs.k8s.io/min-available: "2"
```

備註: 要求屬於同一個 PodGroup 的 Pod 必須保持相同的優先順序

#### Permit

Framework 的 Permit 外掛提供了延遲繫結的功能，即 Pod 進入到 Permit 階段時，使用者可以自定義條件來允許 Pod 透過、拒絕 Pod 透過以及讓 Pod 等待狀態 (可設定超時時間)。Permit 的延遲繫結的功能，剛好可以讓屬於同一個 PodGruop 的 Pod 排程到這個節點時，進行等待，等待積累的 Pod 數目滿足足夠的數目時，再統一執行同一個 PodGruop 的所有 Pod 進行繫結並建立。

舉個實際的例子，當 JobA 排程時，需要 4 個 Pod 同時啟動，才能正常執行。但此時叢集僅能滿足 3 個 Pod 建立，此時與 Default Scheduler 不同的是，並不是直接將 3 個 Pod 排程並建立。而是透過 Framework 的 Permit 機制進行等待。

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

此時當叢集中有空閒資源被釋放後，JobA 的中 Pod 所需要的資源均可以滿足。

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

則 JobA 的 4 個 Pod 被一起排程建立出來，正常執行任務。

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

#### QueueSort

由於 Default Scheduler 的佇列並不能感知 PodGroup 的資訊，所以 Pod 在出隊時處於無序性 (針對 PodGroup 而言)。如下圖所示，a 和 b 表示兩個不同的 PodGroup，兩個 PodGroup 的 Pod 在進入佇列時，由於建立的時間交錯導致在佇列中以交錯的順序排列。

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

當一個新的 Pod 建立後，入隊後，無法跟與其相同的 PodGroup 的 Pod 排列在一起，只能繼續以混亂的形式交錯排列。

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

這種無序性就會導致如果 PodGroupA 在 Permit 階段處於等待狀態，此時 PodGroupB 的 Pod 排程完成後也處於等待狀態，相互佔有資源使得 PodGroupA 和 PodGroupB 均無法正常排程。這種情況即是把死鎖現象出現的位置從 Node 節點移動到 Permit 階段，無法解決前文提到的問題。

針對如上所示的問題，我們透過實現 QueueSort 外掛， 保證在佇列中屬於同一個 PodGroup 的 Pod 能夠排列在一起。我們透過定義 QueueSort 所用的 Less 方法，作用於 Pod 在入隊後排隊的順序：

```
func  Less(podA *PodInfo, podB *PodInfo) bool
```

首先，繼承了預設的基於優先順序的比較方式，高優先順序的 Pod 會排在低優先順序的 Pod 之前。

然後，如果兩個 Pod 的優先順序相同，我們定義了新的排隊邏輯來支援 PodGroup 的排序。

- 如果兩個 Pod 都是 regularPod(普通的 Pod)，則誰先建立誰在佇列裡邊排在前邊；
- 如果兩個 Pod 一個是 regularPod，另一個是 pgPod(屬於某個 PodGroup 的 Pod), 我們比較的是 regularPod 的建立時間和 pgPod 所屬 PodGroup 的建立時間，則誰先建立誰在佇列裡邊排在前邊；
- 如果兩個 Pod 都是 pgPod，我們比較兩個 PodGroup 的建立時間，則誰先建立誰在佇列裡邊排在前邊。同時有可能兩個 PodGroup 的建立時間相同，我們引入了自增 Id，使得 PodGroup 的 Id 誰小誰排在前邊 (此處的目的是為了區分不同的 PodGroup)。

透過如上的排隊策略，我們實現屬於同一個 PodGroup 的 Pod 能夠同一個 PodGroup 的 Pod 能夠排列在一起。

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/7ae5d29c76814ce583b2dfe32ac2ee8e.jpg)

當一個新的 Pod 建立後，入隊後，會跟與其相同的 PodGroup 的 Pod 排列在一起。

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/31b50c8abfed4d1a9f5855f0b15a54b5.jpg)

#### Prefilter

為了減少無效的排程操作，提升排程的效能，我們在 Prefilter 階段增加一個過濾條件，當一個 Pod 排程時，會計算該 Pod 所屬 PodGroup 的 Pod 的 Sum(包括 Running 狀態的)，如果 Sum 小於 min-available 時，則肯定無法滿足 min-available 的要求，則直接在 Prefilter 階段拒絕掉，不再進入排程的主流程。

#### UnReserve

如果某個 Pod 在 Permit 階段等待超時了，則會進入到 UnReserve 階段，我們會直接拒絕掉所有跟 Pod 屬於同一個 PodGroup 的 Pod，避免剩餘的 Pod 進行長時間的無效等待。

# Coscheduling 試用

## 安裝部署

使用者既可以在自己搭建的 Kubernetes 叢集中，也可以在任一個公有云提供的標準 Kubernetes 服務中來試用 Coscheduling。需要注意的是叢集版本 1.16+， 以及擁有更新叢集 master 的許可權。

本文將使用 [阿里雲容器服務 ACK](https://www.aliyun.com/product/kubernetes) 提供的 Kubernetes 叢集來進行測試。

### 前提條件

- 支援 Kubernetes 1.16 以上版本
- 選擇建立 [ACK](https://www.aliyun.com/product/kubernetes) 提供的標準專有叢集（Dedicated cluster）
- 保證叢集節點可以訪問公網
- helm v3：ACK 在 master 節點上預設安裝 helm，請確認版本是否為 helm v3，如果是 helm v2 請升級值 helm v3，安裝 helm v3 請參考 [helm v3 安裝](https://helm.sh/docs/intro/install/)。

### 部署 Coscheduling

我們已經將 Coscheduling 外掛和原生排程器程式碼統一構建成新的容器映象。並提供了一個 helm chart 包 ack-coscheduling 來自動安裝。它會啟動一個任務，自動用 Coscheduling scheduler 替換叢集預設安裝的原生 scheduler，並且會修改 scheduler 的相關 Config 檔案，使 scheduling framework 正確地載入 Coscheduling 外掛。完成試用後，使用者可透過下文提示的解除安裝功能恢復叢集預設 scheduler 及相關配置。

下載 helm chart 包，執行命令安裝：

```
$  wget http://kubeflow.oss-cn-beijing.aliyuncs.com/ack-coscheduling.tar.gz
$  tar zxvf ack-coscheduling.tar.gz
$  helm install ack-coscheduling -n kube-system ./ack-coscheduling
NAME: ack-coscheduling
LAST DEPLOYED: Mon Apr 13 16:03:57 2020
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
```

### 驗證 Coscheduling

在 Master 節點上，使用 helm 命令驗證是否安裝成功。

```
$ helm get manifest ack-coscheduling -n kube-system | kubectl get -n kube-system -f -
NAME                           COMPLETIONS   DURATION   AGE
scheduler-update-clusterrole   1/1           8s         35s
scheduler-update               3/1 of 3      8s         35s
```

### 解除安裝 Coscheduling

透過 helm 解除安裝，將 kube-scheduler 的版本及配置回滾到叢集預設的狀態。

```
$ helm uninstall ack-coscheduling -n kube-system
```

## 使用方式

使用 Coscheduling 時，只需要在建立任務的 yaml 描述中配置 pod-group.scheduling.sigs.k8s.io/name 和 pod-group.scheduling.sigs.k8s.io/min-available 這兩個 label 即可。

```
labels:
    pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
    pod-group.scheduling.sigs.k8s.io/min-available: "3"
```

- pod-group.scheduling.sigs.k8s.io/name：用於表示 PodGroup 的 Name；
- pod-group.scheduling.sigs.k8s.io/min-available: 用於表示當前叢集資源至少滿足 min-available 個 pod 啟動時，才能整體排程該任務。

備註: 屬於同一個 PodGroup 的 Pod 必須保持相同的優先順序。

### Demo 展示

接下來我們透過執行 Tensorflow 的分散式訓練作業來演示 Coscheduling 的效果。當前測試叢集有 4 個 GPU 卡

- 透過 Kubeflow 的 [Arena](https://github.com/kubeflow/arena) 工具在已有 Kubernetes 叢集中部署 Tensorflow 作業執行環境。

> Arena 是基於 Kubernetes 的機器學習系統開源社群 [Kubeflow](https://github.com/kubeflow) 中的子專案之一。Arena 用命令列和 SDK 的形式支援了機器學習任務的主要生命週期管理（包括環境安裝，資料準備，到模型開發，模型訓練，模型預測等），有效提升了資料科學家工作效率。

```
git clone https://github.com/kubeflow/arena.git
kubectl create ns arena-system
kubectl create -f arena/kubernetes-artifacts/jobmon/jobmon-role.yaml
kubectl create -f arena/kubernetes-artifacts/tf-operator/tf-crd.yaml
kubectl create -f arena/kubernetes-artifacts/tf-operator/tf-operator.yaml
```

檢查是否部署成功：

```
$ kubectl  get pods -n arena-system
NAME                                READY   STATUS    RESTARTS   AGE
tf-job-dashboard-56cf48874f-gwlhv   1/1     Running   0          54s
tf-job-operator-66494d88fd-snm9m    1/1     Running   0          54s
```

- 使用者向叢集中提交 Tensorflow 作業 (TFJob)，如下示例，包含 1 個 Parameter Server pod 和 4 個 Worker pod，每個 Worker 需要 2 個 GPU。配置了 pod group，需要至少 5 個 pod 啟動後才能執行。

```
apiVersion: "kubeflow.org/v1"
kind: "TFJob"
metadata:
name: "tf-smoke-gpu"
spec:
tfReplicaSpecs:
PS:
replicas: 1
template:
metadata:
creationTimestamp: null
labels:
pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
pod-group.scheduling.sigs.k8s.io/min-available: "5"
spec:
containers:
- args:
- python
- tf_cnn_benchmarks.py
- --batch_size=32
- --model=resnet50
- --variable_update=parameter_server
- --flush_stdout=true
- --num_gpus=1
- --local_parameter_device=cpu
- --device=cpu
- --data_format=NHWC
image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
name: tensorflow
ports:
- containerPort: 2222
name: tfjob-port
resources:
limits:
cpu: '1'
workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
restartPolicy: OnFailure
Worker:
replicas: 4
template:
metadata:
creationTimestamp: null
labels:
pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
pod-group.scheduling.sigs.k8s.io/min-available: "5"
spec:
containers:
- args:
- python
- tf_cnn_benchmarks.py
- --batch_size=32
- --model=resnet50
- --variable_update=parameter_server
- --flush_stdout=true
- --num_gpus=1
- --local_parameter_device=cpu
- --device=gpu
- --data_format=NHWC
image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-gpu:v20171202-bdab599-dirty-284af3
name: tensorflow
ports:
- containerPort: 2222
name: tfjob-port
resources:
limits:
nvidia.com/gpu: 2
workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
restartPolicy: OnFailure
```

- 當使用者不使用 Coscheduling 功能時

刪除上述 TFJob yaml 中的 pod-group.scheduling.sigs.k8s.io/name 和 pod-group.scheduling.sigs.k8s.io/min-available 標籤，表示該任務不使用 Coscheduling。建立任務後，叢集資源只能滿足 2 個 Worker 啟動，剩餘兩個處於 Pending 狀態。

```
$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
tf-smoke-gpu-ps-0       1/1     Running   0          6m43s
tf-smoke-gpu-worker-0   1/1     Running   0          6m43s
tf-smoke-gpu-worker-1   1/1     Running   0          6m43s
tf-smoke-gpu-worker-2   0/1     Pending   0          6m43s
tf-smoke-gpu-worker-3   0/1     Pending   0          6m43s
```

檢視其中正在執行的 Worker 的日誌，都處於等待剩餘那兩個 Worker 啟動的狀態。此時，4 個 GPU 都被佔用卻沒有實際執行任務。

```
$ kubectl logs -f tf-smoke-gpu-worker-0
INFO|2020-05-19T07:02:18|/opt/launcher.py|27| 2020-05-19 07:02:18.199696: I tensorflow/core/distributed_runtime/master.cc:221] CreateSession still waiting for response from worker: /job:worker/replica:0/task:3
INFO|2020-05-19T07:02:28|/opt/launcher.py|27| 2020-05-19 07:02:28.199798: I tensorflow/core/distributed_runtime/master.cc:221] CreateSession still waiting for response from worker: /job:worker/replica:0/task:2
```

- 當使用者使用 Coscheduling 功能時

新增 pod-group 相關標籤後建立任務，因為叢集的資源無法滿足使用者設定的 min-available 要求，則 PodGroup 無法正常排程，所有的 Pod 一直處於 Pending 狀態。

```
$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
tf-smoke-gpu-ps-0       0/1     Pending   0          43s
tf-smoke-gpu-worker-0   0/1     Pending   0          43s
tf-smoke-gpu-worker-1   0/1     Pending   0          43s
tf-smoke-gpu-worker-2   0/1     Pending   0          43s
tf-smoke-gpu-worker-3   0/1     Pending   0          43s
```

此時，如果透過叢集擴容，新增 4 個 GPU 卡，資源能滿足使用者設定的 min-available 要求，則 PodGroup 正常排程，4 個 Worker 開始執行。

```
$ kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
tf-smoke-gpu-ps-0       1/1     Running   0          3m16s
tf-smoke-gpu-worker-0   1/1     Running   0          3m16s
tf-smoke-gpu-worker-1   1/1     Running   0          3m16s
tf-smoke-gpu-worker-2   1/1     Running   0          3m16s
tf-smoke-gpu-worker-3   1/1     Running   0          3m16s
```

檢視其中一個 Worker 的日誌，顯示訓練任務已經開始：

```
$ kubectl logs -f tf-smoke-gpu-worker-0
INFO|2020-05-19T07:15:24|/opt/launcher.py|27| Running warm up
INFO|2020-05-19T07:21:04|/opt/launcher.py|27| Done warm up
INFO|2020-05-19T07:21:04|/opt/launcher.py|27| Step    Img/sec    loss
INFO|2020-05-19T07:21:05|/opt/launcher.py|27| 1    images/sec: 31.6 +/- 0.0 (jitter = 0.0)    8.318
INFO|2020-05-19T07:21:15|/opt/launcher.py|27| 10    images/sec: 31.1 +/- 0.4 (jitter = 0.7)    8.343
INFO|2020-05-19T07:21:25|/opt/launcher.py|27| 20    images/sec: 31.5 +/- 0.3 (jitter = 0.7)    8.142
```

# 後續工作

利用 Kubernetes Scheduling Framework 的機制實現了 Coscheduling，解決了 AI、資料計算類的批任務需要組合排程，同時減少資源浪費的問題。從而提升叢集整體資源利用率。

**作者介紹：**
王慶璨，阿里雲技術專家，專注於大規模叢集資源管理和排程。Kubernetes 社群成員，主要參與 Kube-scheduler 社群開發。目前負責[阿里雲容器服務 ACK ](https://www.aliyun.com/product/kubernetes)資源排程和雲原生 AI 相關工作。

張凱，阿里雲高階技術專家，從事[容器服務 ACK ](https://www.aliyun.com/product/kubernetes)和雲原生 AI 解決方案的研發和客戶支援，以及相關領域的開源建設。擁有 10 餘年大規模深度學習平臺，雲端計算，SOA 等領域經驗。

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

進擊的 Kubernetes 排程系統（二）：支援批任務的 Coscheduling/Gang scheduling

相關文章