基於Kubernetes的GPU類型調度實現

• 2019 年 12 月 4 日
• 筆記

3 月 27 日，ACM 宣布深度學習的三位締造者——Yoshua Bengio、Yann LeCun 及 Geoffrey Hinton 獲得了 2018 年度的圖靈獎。與學術界相對應的，在工業界，人工智慧大潮也正洶湧奔來。除了衝擊人們的衣食住行醫，人工智慧也將成為企業轉型的顛覆性力量，是企業抓住下一輪創新發展的重要機遇。

發布 | 才雲 Caicloud

作者 | angao

1行業背景

現如今，隨著企業紛紛在機器學習和深度學習上加大投入，他們開始發現從頭構建一個 AI 系統並非易事。

以深度學習為例。對於深度學習來說，算力是一切的根本。為了用海量數據訓練性能更好的模型、加速整個流程，企業的 IT 系統需要具備快速、高效調用管理大規模 GPU 資源的能力。同時，由於算力資源十分昂貴，出於成本控制，企業也需要通過分散式訓練等方式最大化 GPU 資源利用率。

面對這類新要求，基於 Kubernetes 的雲原生技術為人工智慧提供了一種新的工作模式。憑藉其特性，Kubernetes 可以無縫將模型訓練、inference 和部署擴展到多雲 GPU 集群，允許數據科學家跨集群節點自動化多個 GPU 加速應用程式容器的部署、維護、調度和操作。

在 1.6 版本和 1.9 版本中，Kubernetes 先後提供了對 NVIDIA GPU、AMD GPU 容器集群管理調度的支援，進一步提高了對 GPU 等擴展資源進行統一管理和調度的能力。

但是，Kubernetes 作為新一代 AI 開發基礎也存在缺陷。為訓練任務分配算力資源時，它通常是隨機分配容器所在節點的 GPU，而不能指定使用某類 GPU 類型。

雖然這對大部分深度學習模型訓練場景來說已經足夠了，但如果數據科學家希望能更靈活地使用更高性能的或某一類型的 GPU，Kubernetes 的能力就有些捉襟見肘了。

因此，在這篇文章中，我將介紹才雲科技在這一點上的經驗，談一談我們如何基於 Kubernetes 靈活實現 GPU 類型的調度。

2社區方案

問題：原生 Kubernetes 如何讓 Pod 使用指定類型的 GPU？

假設集群中有兩個節點有 GPU：節點 A 上有兩個 Tesla K80，節點 B 上有兩個 Tesla P100。Kubernetes 可以通過 Node Label 和 Node Selector，把 Pod 調度到合適的節點上，具體如下。

先給 Node 打上特定的 Label：

# Label your nodes with the accelerator type they have.  $ kubectl label nodes node-a accelerator=nvidia-tesla-k80  $ kubectl label nodes node-b accelerator=nvidia-tesla-p100  

此時節點 A 如下：

$ kubectl describe node node-a  Name:         node-a  Roles:        <none>  Labels:       ...                beta.kubernetes.io/arch=amd64                beta.kubernetes.io/os=linux                kubernetes.io/hostname=node-a                accelerator=nvidia-tesla-k80  Annotations:  kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock  ......  

當 Pod 想使用 NVIDIA Tesla K80 GPU 時，可以通過下面的方式：

apiVersion: v1  kind: Pod  metadata:   name: cuda-vector-add  spec:   containers:     - name: cuda-vector-add       image: "k8s.gcr.io/cuda-vector-add:v0.1"       resources:         limits:           nvidia.com/gpu: 1   nodeSelector:     accelerator: nvidia-tesla-k80

上述做法貌似解決了問題，但它其實治標不治本。

試想一下，如果用戶集群在同一個節點上掛載了多種 GPU，我們該如何實現篩選？如果用戶在同一個節點掛載了多個顯示記憶體不同的 NVIDIA Tesla K80，而且想使用大於 10GiB 顯示記憶體的 GPU，我們又該怎麼辦？

Kubernetes 的 Node Label 和 Node Selector 是沒法解決這些問題的。

在上游社區，很多開發者也經常圍繞此類問題展開討論，但一直沒有實際可用的方案落地。儘管如此，社區還是提供了不少精彩見解，比如下面就是社區中討論最多的一個方案，我們的方案也借鑒了其中的部分設計。

• 新增 ResourceClass API，用來匹配集群中的擴展資源，具體用法見下文介紹；
• 修改 Node API，在 NodeStatus 中增加欄位描述擴展資源：

type NodeStatus struct {      …      ComputeResources []ComputeResource  }  type ComputeResource struct {      // unique and deterministically generated. 「resourceName-propertyHash」 naming convention,      // where propertyHash is generated by calculating a hash over all resource properties      Name string      // raw resource name. E.g.: nvidia.com/nvidia-gpu      ResourceName string      // resource metadata received from device plugin.      // e.g., gpuType: k80, zone: us-west1-b      Properties map[string]string      // list of deviceIds received from device plugin.      // e.g., ["nvidia0", "nvidia1"]      Devices []string      // similar to the above but only contains allocatable devices.      AllocatableDevices []string  }

• 擴展資源通過 Device Plugin API 向 Kubelet 組件註冊其資訊，隨後 Kubelet 組件可以通過接收到的擴展資源資訊更新節點狀態，即上一步中的 ComputeResources 欄位；
• 調度器根據 ResourceClass 的定義過濾選擇合適的節點。調度器監聽 NodeStatus.ComputeResources 的變化並快取節點上 ComputeResource 的分配資訊，以便 ResourceClass 匹配合適的節點。

相比 Node Label 和 Node Selector，社區的方案更成熟。但不難看出，這個方案雖然可以修改 Kubernetes 核心程式碼和核心 API，但作為一個倍受關注的技術問題的解決方案，它的進度非常緩慢，一直沒有得出更進一步的結論。

3才雲科技：GPU 類型調度實現

為了儘快實現在 Pod 使用指定類型的 GPU，並把它集成到 Caicloud Compass 中，我們在上游社區方案的基礎上提出了一種全新方案。

它充分利用了 Kubernetes 的擴展性和插件機制，並遵循最小侵入和方便移植的設計原則。但是，出於簡化用戶使用和降低開發維護難度等原因，它還是修改了 Kubelet 和 Scheduler 組件。

同時，由於我們採用了多調度器的實現方式，所以方案中對於 Scheduler 組件的修改不影響現有集群和之後的版本升級，而 Kubelet 組件採用了向後兼容式修改，不影響已經在集群中運行的應用。

該方案不僅支援 GPU 資源，還支援包括 Infiniband、FPGAs 等擴展資源，它依賴以下現有 Kubernetes 工作機制：

• Scheduler Extender 機制
• Device Plugin 機制
• API Server 擴展機制（CRD）
• Admission 擴展機制（ResourceQuota）

在 1.6 版本中，Kubernetes 可以通過 ThirdPartyResource(TPR) 創建自定義資源，但在 1.7 版本中，它推出了 TPR 的替代方法： CustomResourceDefinition(CRD)。

CRD 允許自定義一個資源類型，因此開發人員不再需要修改 Kubernetes 核心 API 或通過 API server aggregation 增加新資源，開發和維護難度大大降低。

在我們的方案中，我們通過 CRD 定義了兩種資源：ExtendedResource 和 ResourceClass。ExtendedResource 描述了一種擴展資源，比如 NVIDIA GPU；ResourceClass 則定義了容器選擇哪種擴展資源，它的使用方式和 Kubernetes 中的 Extended Resource（詳見參考文獻）類似，用戶可以直接在容器中指定，就像使用 CPU 和 Memory 一樣。

下面是才雲方案的基本架構圖：

核心模組一：Scheduler Extender。Scheduler Extender 利用 Scheduler 組件的擴展性，負責調度容器中使用了 ResourceClass 資源對象的 Pod。它通過查詢 ResourceClass 對象的定義過濾選擇節點上的 ExtendedResource 資源，從而找到合適的節點並綁定，並將合適的 ExtendedResource 寫到 Pod Annotation 中，供 Kubelet 組件使用。由於 Scheduler Extender 的擴展機制是通過 HTTP 的方式實現的，為了不影響集群的默認調度器性能，通過多調度器的方式為僅需要使用擴展資源的 Pod 提供調度，並且這種方式具有可移植性。

核心模組二：Nvidia Device Plugin。此組件僅針對 NVIDIA GPU 擴展資源，除了負責與 Kubelet 組件通訊，它還負責創建和維護 ExtendedResource 資源對象。

那麼，當同一節點上有多種不同類型的 GPU 時，這個方案是如何解決類型指定的呢？

我們假設有節點 A 上有兩張 GPU，一張是 NVIDIA Tesla K80，另一張是 NVIDIA Tesla P100。那麼這個節點上的 NVIDIA Device Plugin 會創建兩個 ExtendedResource 資源對象，分別描述這兩張卡的基本屬性，如型號、顯示記憶體、頻率等。同時，它也會向 Kubelet 註冊，把 A 節點上有兩張 GPU 告知節點上的 Kubelet。

這時，如果用戶想創建一個使用 K80 這張 GPU 的應用，他只需要創建一個 ResourceClass 資源，在 ResourceClass 中聲明使用型號為 NVIDIA Tesla K80 的 GPU（比如通過 Selector 的方式聲明），然後在容器中使用這個 ResourceClass 資源。

kind: ResourceClass  metadata:   name: nvidia.tesla.k80  spec:   selector:     matchLabels:       model: "NVIDIA Tesla K80"    kind: Pod  metadata:   name: example-pod  spec:   containers:   - name: example-container     resources:       limits:         nvidia.tesla.k80: 1

• Kubernetes 默認調度器在經過一系列篩選過濾後，會調用 Scheduler Extender 的 Filter 方法，並將需要調度的 Pod 和過濾後的 NodeList 傳遞給 Filter，實現 ResourceClass 查找滿足需求的 ExtendedResource，從而找到合適的節點；
• 當調度器找到合適的節點後，調用 Scheduler Extender 的 Bind 方法，將 Pod 和 Node 綁定，並將合適的 ExtendedResource 資源對象寫到 Pod Annotation 中，供 Kubelet 組件使用。

當 Pod 和 Node 綁定後，節點上的 Kubelet 組件則開始創建容器，並通過 Pod Annotation 獲取容器需要使用哪塊 GPU 的資訊，然後通過 Device Plugin API 調用 NVIDIA Device Plugin 的 Allocate 方法。

Allocate 方法參數是容器使用的 GPU DeviceID，它通過 DeviceID 查詢 GPU 的資訊作為環境變數，返回給 Kubelet 用以真正創建 Pod。

從上述流程中可以看出，當我們想使用特定類型的 GPU 或者某一類 GPU 時，我們只需聲明該類型的 ResourceClass 資源對象，比如：

kind: ResourceClass  metadata:   name: nvidia.high.mem  spec:   selector:   - matchExpressions:     - key: "memory"       operator: "Gt"       values:         - "10GiB"

更進一步，我們可以通過實現一個 Controller 監聽集群中的 ExtendedResource 資源，自動為一種類型的 ExtendedResource 創建一個 ResourceClass 對象，為用戶提供一些默認規則的 ResourceClass 資源對象。

在實際生產集群環境中，我們不僅需要滿足不同應用對資源的使用，更是要做到不同應用對資源使用的限制，以及對不同的 namespace 分配不同的資源。而在 Kubernetes 中，我們一般會通過 ResourceQuota 資源對象來限制不同 namespace 的資源，例如：

kind: ResourceQuota  metadata:   name: example-quota   namespace: system  spec:   hard:     cpu: "10"     memory: 20Gi     nvidia.com/gpu: "5" 

從上面的 ResourceQuota 定義里，我們可以看到 default 命名空間可以使用 5 塊 NVIDIA GPU，但它並不限制具體該使用哪種類型的 GPU。

那麼，我們該如何實現對 GPU 類型的限制呢？

首先，GPU 這類擴展資源使用是標量，所以我們對標量資源的限制只能做到整數個數的限制。

其次，從上述方案中，我們知道一種 ResourceClass 代表了一種類型的擴展資源，因此對擴展資源的限制其實就是對 ResourceClass 的限制。

這樣理解之後，問題就很簡單明了了。下面直接給出相應的 ResourceQuota：

kind: ResourceQuota  metadata:   name: example-quota   namespace: system  spec:   hard:     cpu: "10"     memory: 20Gi     nvidia.tesla.k80: "5"

4展望未來

除了 GPU 類型調度，這個方案其實也可以解決 GPU 共享問題。這同樣是上游社區的一個熱門討論話題。

ExtendedResource 資源中包含著 GPU 的頻率、顯示記憶體等資訊，當多個容器想使用同一塊 GPU 時，我們可以定義一個 ResourceClass 資源對象，在 ResourceClass 中聲明使用多少顯示記憶體（這裡共享的是顯示記憶體）。這樣，應用部署時，我們只要在容器中聲明使用該 ResourceClass 資源即可，之後 Scheduler Extender 會過濾符合條件的 ExtendedResource 對象，綁定到合適的節點上。

如果要實現資源共享，我們可能需要在 ExtendedResource 中記錄顯示記憶體的用量情況，供調度參考。當然，這裡沒有考慮到資源的隔離和限制的問題，這需要單獨實現和更進一步的討論。

以上就是我們在探索如何讓 Pod 使用指定類型的 GPU 上得出的解決方案。如果你對這個主題感興趣，或有新想法，歡迎留言一起討論。

你也可以關注我們公司的公眾號（Caicloud2015），之後我們還會分享一系列內部技術和開源軟體，敬請期待！

參考文獻

1.Extended Resource：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#extended-resources

2.CustomResourceDefinition: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions

3.Multiple Schedulers: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/

4.Resource Quotas: https://kubernetes.io/docs/concepts/policy/resource-quotas/

5.New Resource API: https://github.com/vikaschoudhary16/community/blob/55ecd0aa37acd748c19493b82956dfed5191c0d9/keps/sig-node/00014-resource-api.md