這篇文章將為大家詳細(xì)講解有關(guān)基于Kubernetes的GPU類型調(diào)度實(shí)現(xiàn)是怎樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

十載專注成都網(wǎng)站制作，成都企業(yè)網(wǎng)站定制，個(gè)人網(wǎng)站制作服務(wù)，為大家分享網(wǎng)站制作知識(shí)、方案，網(wǎng)站設(shè)計(jì)流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù),專注于成都企業(yè)網(wǎng)站定制,高端網(wǎng)頁制作,對(duì)成都辦公空間設(shè)計(jì)等多個(gè)行業(yè)，擁有豐富的網(wǎng)站制作經(jīng)驗(yàn)。

行業(yè)背景

現(xiàn)如今，隨著企業(yè)紛紛在機(jī)器學(xué)習(xí)和深度學(xué)習(xí)上加大投入，他們開始發(fā)現(xiàn)從頭構(gòu)建一個(gè) AI 系統(tǒng)并非易事。

以深度學(xué)習(xí)為例。對(duì)于深度學(xué)習(xí)來說，算力是一切的根本。為了用海量數(shù)據(jù)訓(xùn)練性能更好的模型、加速整個(gè)流程，企業(yè)的 IT 系統(tǒng)需要具備快速、高效調(diào)用管理大規(guī)模 GPU 資源的能力。同時(shí)，由于算力資源十分昂貴，出于成本控制，企業(yè)也需要通過分布式訓(xùn)練等方式最大化 GPU 資源利用率。

面對(duì)這類新要求，基于 Kubernetes 的云原生技術(shù)為人工智能提供了一種新的工作模式。憑借其特性，Kubernetes 可以無縫將模型訓(xùn)練、inference 和部署擴(kuò)展到多云 GPU 集群，允許數(shù)據(jù)科學(xué)家跨集群節(jié)點(diǎn)自動(dòng)化多個(gè) GPU 加速應(yīng)用程序容器的部署、維護(hù)、調(diào)度和操作。

在 1.6 版本和 1.9 版本中，Kubernetes 先后提供了對(duì) NVIDIA GPU、AMD GPU 容器集群管理調(diào)度的支持，進(jìn)一步提高了對(duì) GPU 等擴(kuò)展資源進(jìn)行統(tǒng)一管理和調(diào)度的能力。

但是，Kubernetes 作為新一代 AI 開發(fā)基礎(chǔ)也存在缺陷。為訓(xùn)練任務(wù)分配算力資源時(shí)，它通常是隨機(jī)分配容器所在節(jié)點(diǎn)的 GPU，而不能指定使用某類 GPU 類型。

雖然這對(duì)大部分深度學(xué)習(xí)模型訓(xùn)練場(chǎng)景來說已經(jīng)足夠了，但如果數(shù)據(jù)科學(xué)家希望能更靈活地使用更高性能的或某一類型的 GPU，Kubernetes 的能力就有些捉襟見肘了。

如何基于 Kubernetes 靈活實(shí)現(xiàn) GPU 類型的調(diào)度。

社區(qū)方案

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

假設(shè)集群中有兩個(gè)節(jié)點(diǎn)有 GPU：節(jié)點(diǎn) A 上有兩個(gè) Tesla K80，節(jié)點(diǎn) B 上有兩個(gè) Tesla P100。Kubernetes 可以通過 Node Label 和 Node Selector，把 Pod 調(diào)度到合適的節(jié)點(diǎn)上，具體如下。

先給 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

此時(shí)節(jié)點(diǎn) 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
......

當(dāng) Pod 想使用 NVIDIA Tesla K80 GPU 時(shí)，可以通過下面的方式：

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

上述做法貌似解決了問題，但它其實(shí)治標(biāo)不治本。

試想一下，如果用戶集群在同一個(gè)節(jié)點(diǎn)上掛載了多種 GPU，我們?cè)撊绾螌?shí)現(xiàn)篩選？如果用戶在同一個(gè)節(jié)點(diǎn)掛載了多個(gè)顯存不同的 NVIDIA Tesla K80，而且想使用大于 10GiB 顯存的 GPU，我們又該怎么辦？

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

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

• 新增 ResourceClass API，用來匹配集群中的擴(kuò)展資源，具體用法見下文介紹；

• 修改 Node API，在 NodeStatus 中增加字段描述擴(kuò)展資源：

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
}

擴(kuò)展資源通過 Device Plugin API 向 Kubelet 組件注冊(cè)其信息，隨后 Kubelet 組件可以通過接收到的擴(kuò)展資源信息更新節(jié)點(diǎn)狀態(tài)，即上一步中的 ComputeResources 字段；

調(diào)度器根據(jù) ResourceClass 的定義過濾選擇合適的節(jié)點(diǎn)。調(diào)度器監(jiān)聽 NodeStatus.ComputeResources 的變化并緩存節(jié)點(diǎn)上 ComputeResource 的分配信息，以便 ResourceClass 匹配合適的節(jié)點(diǎn)。

相比 Node Label 和 Node Selector，社區(qū)的方案更成熟。但不難看出，這個(gè)方案雖然可以修改 Kubernetes 核心代碼和核心 API，但作為一個(gè)倍受關(guān)注的技術(shù)問題的解決方案，它的進(jìn)度非常緩慢，一直沒有得出更進(jìn)一步的結(jié)論。

才云科技：GPU 類型調(diào)度實(shí)現(xiàn)

為了盡快實(shí)現(xiàn)在 Pod 使用指定類型的 GPU，并把它集成到 Caicloud Compass 中，我們?cè)谏嫌紊鐓^(qū)方案的基礎(chǔ)上提出了一種全新方案。

它充分利用了 Kubernetes 的擴(kuò)展性和插件機(jī)制，并遵循最小侵入和方便移植的設(shè)計(jì)原則。但是，出于簡(jiǎn)化用戶使用和降低開發(fā)維護(hù)難度等原因，它還是修改了 Kubelet 和 Scheduler 組件。

同時(shí)，由于我們采用了多調(diào)度器的實(shí)現(xiàn)方式，所以方案中對(duì)于 Scheduler 組件的修改不影響現(xiàn)有集群和之后的版本升級(jí)，而 Kubelet 組件采用了向后兼容式修改，不影響已經(jīng)在集群中運(yùn)行的應(yīng)用。

該方案不僅支持 GPU 資源，還支持包括 Infiniband、FPGAs 等擴(kuò)展資源，它依賴以下現(xiàn)有 Kubernetes 工作機(jī)制：

• Scheduler Extender 機(jī)制

• Device Plugin 機(jī)制

• API Server 擴(kuò)展機(jī)制（CRD）

• Admission 擴(kuò)展機(jī)制（ResourceQuota）

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

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

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

下面是才云方案的基本架構(gòu)圖：

核心模塊一：Scheduler Extender。Scheduler Extender 利用 Scheduler 組件的擴(kuò)展性，負(fù)責(zé)調(diào)度容器中使用了 ResourceClass 資源對(duì)象的 Pod。它通過查詢 ResourceClass 對(duì)象的定義過濾選擇節(jié)點(diǎn)上的 ExtendedResource 資源，從而找到合適的節(jié)點(diǎn)并綁定，并將合適的 ExtendedResource 寫到 Pod Annotation 中，供 Kubelet 組件使用。由于 Scheduler Extender 的擴(kuò)展機(jī)制是通過 HTTP 的方式實(shí)現(xiàn)的，為了不影響集群的默認(rèn)調(diào)度器性能，通過多調(diào)度器的方式為僅需要使用擴(kuò)展資源的 Pod 提供調(diào)度，并且這種方式具有可移植性。

核心模塊二：Nvidia Device Plugin。此組件僅針對(duì) NVIDIA GPU 擴(kuò)展資源，除了負(fù)責(zé)與 Kubelet 組件通信，它還負(fù)責(zé)創(chuàng)建和維護(hù) ExtendedResource 資源對(duì)象。

那么，當(dāng)同一節(jié)點(diǎn)上有多種不同類型的 GPU 時(shí)，這個(gè)方案是如何解決類型指定的呢？

我們假設(shè)有節(jié)點(diǎn) A 上有兩張 GPU，一張是 NVIDIA Tesla K80，另一張是 NVIDIA Tesla P100。那么這個(gè)節(jié)點(diǎn)上的 NVIDIA Device Plugin 會(huì)創(chuàng)建兩個(gè) ExtendedResource 資源對(duì)象，分別描述這兩張卡的基本屬性，如型號(hào)、顯存、頻率等。同時(shí)，它也會(huì)向 Kubelet 注冊(cè)，把 A 節(jié)點(diǎn)上有兩張 GPU 告知節(jié)點(diǎn)上的 Kubelet。

這時(shí)，如果用戶想創(chuàng)建一個(gè)使用 K80 這張 GPU 的應(yīng)用，他只需要?jiǎng)?chuàng)建一個(gè) ResourceClass 資源，在 ResourceClass 中聲明使用型號(hào)為 NVIDIA Tesla K80 的 GPU（比如通過 Selector 的方式聲明），然后在容器中使用這個(gè) 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 默認(rèn)調(diào)度器在經(jīng)過一系列篩選過濾后，會(huì)調(diào)用 Scheduler Extender 的 Filter 方法，并將需要調(diào)度的 Pod 和過濾后的 NodeList 傳遞給 Filter，實(shí)現(xiàn) ResourceClass 查找滿足需求的 ExtendedResource，從而找到合適的節(jié)點(diǎn)；

• 當(dāng)調(diào)度器找到合適的節(jié)點(diǎn)后，調(diào)用 Scheduler Extender 的 Bind 方法，將 Pod 和 Node 綁定，并將合適的 ExtendedResource 資源對(duì)象寫到 Pod Annotation 中，供 Kubelet 組件使用。

當(dāng) Pod 和 Node 綁定后，節(jié)點(diǎn)上的 Kubelet 組件則開始創(chuàng)建容器，并通過 Pod Annotation 獲取容器需要使用哪塊 GPU 的信息，然后通過 Device Plugin API 調(diào)用 NVIDIA Device Plugin 的 Allocate 方法。

Allocate 方法參數(shù)是容器使用的 GPU DeviceID，它通過 DeviceID 查詢 GPU 的信息作為環(huán)境變量，返回給 Kubelet 用以真正創(chuàng)建 Pod。

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

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

更進(jìn)一步，我們可以通過實(shí)現(xiàn)一個(gè) Controller 監(jiān)聽集群中的 ExtendedResource 資源，自動(dòng)為一種類型的 ExtendedResource 創(chuàng)建一個(gè) ResourceClass 對(duì)象，為用戶提供一些默認(rèn)規(guī)則的 ResourceClass 資源對(duì)象。

在實(shí)際生產(chǎn)集群環(huán)境中，我們不僅需要滿足不同應(yīng)用對(duì)資源的使用，更是要做到不同應(yīng)用對(duì)資源使用的限制，以及對(duì)不同的 namespace 分配不同的資源。而在 Kubernetes 中，我們一般會(huì)通過 ResourceQuota 資源對(duì)象來限制不同 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。

那么，我們?cè)撊绾螌?shí)現(xiàn)對(duì) GPU 類型的限制呢？

首先，GPU 這類擴(kuò)展資源使用是標(biāo)量，所以我們對(duì)標(biāo)量資源的限制只能做到整數(shù)個(gè)數(shù)的限制。

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

這樣理解之后，問題就很簡(jiǎn)單明了了。下面直接給出相應(yīng)的 ResourceQuota：

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

除了 GPU 類型調(diào)度，這個(gè)方案其實(shí)也可以解決 GPU 共享問題。這同樣是上游社區(qū)的一個(gè)熱門討論話題。

ExtendedResource 資源中包含著 GPU 的頻率、顯存等信息，當(dāng)多個(gè)容器想使用同一塊 GPU 時(shí)，我們可以定義一個(gè) ResourceClass 資源對(duì)象，在 ResourceClass 中聲明使用多少顯存（這里共享的是顯存）。這樣，應(yīng)用部署時(shí)，我們只要在容器中聲明使用該 ResourceClass 資源即可，之后 Scheduler Extender 會(huì)過濾符合條件的 ExtendedResource 對(duì)象，綁定到合適的節(jié)點(diǎn)上。

如果要實(shí)現(xiàn)資源共享，我們可能需要在 ExtendedResource 中記錄顯存的用量情況，供調(diào)度參考。當(dāng)然，這里沒有考慮到資源的隔離和限制的問題，這需要單獨(dú)實(shí)現(xiàn)和更進(jìn)一步的討論。

關(guān)于基于Kubernetes的GPU類型調(diào)度實(shí)現(xiàn)是怎樣的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

文章名稱：基于Kubernetes的GPU類型調(diào)度實(shí)現(xiàn)是怎樣的
轉(zhuǎn)載來于：http://chinadenli.net/article8/gideop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、動(dòng)態(tài)網(wǎng)站、網(wǎng)站策劃、服務(wù)器托管、全網(wǎng)營(yíng)銷推廣、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)