劉志彬，黃秋蘭，胡慶寶，程耀東，4，胡譽(yù)，田浩來，3

（1.中國(guó)科學(xué)院高能物理研究所，北京 100049；2.中國(guó)科學(xué)院大學(xué)，北京 100049；3.散裂中子源科學(xué)中心，廣東 東莞 523803；4.中國(guó)科學(xué)院高能物理研究所 天府宇宙線研究中心，成都 610041）

0 概述

在復(fù)雜的計(jì)算環(huán)境中，云計(jì)算技術(shù)可以顯著提高計(jì)算資源的利用率［1］。隨著容器化技術(shù)［2］的快速發(fā)展，海量的服務(wù)正在從虛擬機(jī)的單體架構(gòu)遷移到基于容器的云原生架構(gòu)［3］。谷歌的開源容器編排工具Kubernetes［4］已經(jīng)成為在云環(huán)境中部署容器化應(yīng)用的事實(shí)標(biāo)準(zhǔn)。因此，需要合理的資源調(diào)度技術(shù)來提高資源利用率以及服務(wù)質(zhì)量［5-6］。

Kubernetes 的資源調(diào)度流程是將用戶申請(qǐng)的pod 調(diào)度到合適的節(jié)點(diǎn)上［7］。調(diào)度器通過硬件廠商提供的設(shè)備插件掌握拓展的異構(gòu)資源，并利用拓展資源進(jìn)行異構(gòu)資源的調(diào)度［8］，但是目前Kubernetes 僅支持卡級(jí)別的調(diào)度，即用戶pod 可以申請(qǐng)獨(dú)占一塊或者多塊GPU卡［9］，而調(diào)度器無法判斷單個(gè)硬件資源是否滿足細(xì)粒度的需求［10-12］。在CPU 和內(nèi)存的調(diào)度方面，學(xué)者們開展了一系列研究工作并取得了一定的成果。文獻(xiàn)［13］提出一種基于遺傳算法的Kubernetes 資源調(diào)度算法，保證了集群的負(fù)載均衡。文獻(xiàn)［14］結(jié)合蟻群算法和粒子群優(yōu)化算法對(duì)調(diào)度器進(jìn)行改進(jìn)，降低了節(jié)點(diǎn)最大負(fù)載并使任務(wù)分配更加均衡。文獻(xiàn)［15］設(shè)計(jì)一種綜合的監(jiān)控機(jī)制，將系統(tǒng)資源利用率和應(yīng)用指標(biāo)提交給調(diào)度算法以指定更好的調(diào)度策略。文獻(xiàn)［16］在CPU 和內(nèi)存的基礎(chǔ)上添加了I/O 和網(wǎng)絡(luò)指標(biāo)，提高了集群的負(fù)載均衡效率。文獻(xiàn)［17］提出一種干擾-拓?fù)涓兄纳疃葘W(xué)習(xí)并行化方法，該方法有效提高了GPU 資源利用率。文獻(xiàn)［18］考慮了GPU 和CPU 異構(gòu)資源調(diào)度，使用機(jī)器學(xué)習(xí)方法提取pod 任務(wù)特征，并且按照任務(wù)類型將pod 調(diào)度到合適節(jié)點(diǎn)。

本文針對(duì)交互式計(jì)算中pod 異構(gòu)資源需求依賴于用戶申請(qǐng)的情況，提出一種異構(gòu)計(jì)算資源混合調(diào)度策略，拓展GPU 資源信息以滿足細(xì)粒度的資源需求，并且通過優(yōu)化默認(rèn)調(diào)度器的過濾和打分策略，實(shí)現(xiàn)異構(gòu)資源混合部署情況下的資源調(diào)度，以避免資源競(jìng)爭(zhēng)導(dǎo)致不合理的資源分配，并提高集群資源的利用率。

1 Kubernetes 默認(rèn)調(diào)度策略及其對(duì)GPU 的支持

1.1 Kubernetes 調(diào)度流程

在Kubernetes 集群中，Kube-scheduler 組件的任務(wù)是將pod 調(diào)度到集群［19-20］中特定的節(jié)點(diǎn)，該組件默認(rèn)的行為是根據(jù)pod 期望的資源（例如CPU、memory等）來過濾節(jié)點(diǎn)，然后對(duì)可用的節(jié)點(diǎn)進(jìn)行打分，最終選擇一個(gè)分?jǐn)?shù)最高的節(jié)點(diǎn)完成與待調(diào)度pod 的綁定。

Kube-scheduler 提供了一個(gè)調(diào)度框架，可根據(jù)多種內(nèi)置算法進(jìn)行過濾和打分，并且支持開發(fā)者拓展自定義的調(diào)度算法。目前，Kube-scheduler framework 調(diào)度流程分為兩個(gè)階段：過濾階段和打分階段。過濾階段的主要目標(biāo)是過濾不滿足需求的節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都會(huì)檢查自己的空閑資源是否滿足pod 的請(qǐng)求，如果滿足則將節(jié)點(diǎn)加入可用節(jié)點(diǎn)列表。默認(rèn)的過濾節(jié)點(diǎn)策略包括PodFitsResources、NoDiskConflict等。打分階段的主要目標(biāo)是從可用節(jié)點(diǎn)列表中選擇一個(gè)分?jǐn)?shù)最高的節(jié)點(diǎn)與待調(diào)度的pod 進(jìn)行綁定。默認(rèn)的優(yōu)選節(jié)點(diǎn)策略包括LeastRequestedPriority、ImageLocalityPriority等。

除了基于節(jié)點(diǎn)可用資源調(diào)度以外，調(diào)度器還基于以下方法或特性進(jìn)行調(diào)度：1）NodeSelector，是一種基于標(biāo)簽的調(diào)度方法，管理員為某些節(jié)點(diǎn)打上特定標(biāo)簽，用戶在創(chuàng)建pod 時(shí)手動(dòng)指定NodeSelector 標(biāo)簽；2）節(jié)點(diǎn)親和性，使用邏輯運(yùn)算符控制節(jié)點(diǎn)關(guān)聯(lián)約束的嚴(yán)格程度來調(diào)度pod，比NodeSelector 更加靈活；3）pod 親和性，根據(jù)pod 和其他pod 之間的關(guān)系來調(diào)度，通常相互依賴的pod 運(yùn)行在同一節(jié)點(diǎn)上。

1.2 GPU 支持

在一些高級(jí)調(diào)度場(chǎng)景中，例如深度學(xué)習(xí)任務(wù)，需要高性能的GPU 來運(yùn)行訓(xùn)練任務(wù)［21-23］。在異構(gòu)資源混合部署場(chǎng)景中，Kubernetes 集群管理員期望根據(jù)約束將pod 正確調(diào)度到具有專有計(jì)算資源的節(jié)點(diǎn)上。

Kubernetes 提供了設(shè)備插件機(jī)制用于支持GPU［24-25］等異構(gòu)資源。NVIDIA device plugin具備GPU 加速功能，具體步驟為：1）通過監(jiān)控節(jié)點(diǎn)上的GPU 信息將資源上報(bào)到節(jié)點(diǎn)上的Extended Resource處；2）當(dāng)節(jié)點(diǎn)部署容器時(shí)為容器分配GPU 資源。當(dāng)用戶申請(qǐng)GPU 資源時(shí)，在Spec 字段處添加字段"nvidia.com/gpu：2"表示申請(qǐng)兩塊GPU卡，Kubernetes默認(rèn)調(diào)度器在過濾階段會(huì)檢查Extended Resource，完成對(duì)GPU 節(jié)點(diǎn)的過濾。NVIDIA device plugin 雖然滿足了用戶使用GPU 的需求，但是也存在以下問題：1）沒有提供GPU 調(diào)度策略，在異構(gòu)資源混合部署時(shí)容易造成資源競(jìng)爭(zhēng)；2）資源上報(bào)粒度較粗，僅能滿足GPU 卡數(shù)量的需求，已分配的GPU 在顯存大小、核心數(shù)量等方面可能無法滿足用戶計(jì)算需求。

2 改進(jìn)的Kubernetes 異構(gòu)資源調(diào)度策略

本文提出一種細(xì)粒度的異構(gòu)資源調(diào)度策略。在集群中，不同類型的應(yīng)用對(duì)計(jì)算資源的需求不一樣，不同的節(jié)點(diǎn)提供的計(jì)算資源類型也不同。在異構(gòu)資源混合部署的情況下，對(duì)提供計(jì)算資源的節(jié)點(diǎn)與申請(qǐng)計(jì)算資源的pod 進(jìn)行類型劃分：根據(jù)是否提供GPU 將節(jié)點(diǎn)劃分為CPU 節(jié)點(diǎn)和GPU 節(jié)點(diǎn)；根據(jù)是否申請(qǐng)GPU 將pod 劃分為CPU 型pod 和GPU 型pod。

2.1 GPU 資源的拓展

針對(duì)GPU 調(diào)度資源上報(bào)粒度較粗的問題，首先拓展Kubernetes api 對(duì)GPU 資源的支持，創(chuàng)建GPU自定義資源，包含GPU 卡數(shù)、每張卡的顯存大小、每張卡的核心數(shù)量等狀態(tài)信息，將該自定義資源在Kubernetes ETCD 數(shù)據(jù)庫(kù)中進(jìn)行注冊(cè)并持久化保存，以便調(diào)度器從全局視角獲取各個(gè)節(jié)點(diǎn)的GPU 狀態(tài)信息，然后設(shè)計(jì)一個(gè)控制器定時(shí)檢查節(jié)點(diǎn)上的GPU信息，并上報(bào)給apiserver 更新GPU 自定義資源。

用戶在申請(qǐng)資源時(shí)添加自定義注解進(jìn)行細(xì)粒度資源申請(qǐng)，例如在annotation 中添加字段"oks/gpunumber：2"表示申請(qǐng)兩塊GPU卡，"oks/gpu-core：2000"表示每塊卡有2 000 個(gè)核心，"oks/gpu-memory：32000"表示每塊卡有32 000 MB 顯存。在用戶pod調(diào)度階段，自定義調(diào)度器通過向apiserver 查詢最新的GPU 狀態(tài)信息，為下一步調(diào)度決策提供細(xì)粒度資源信息。

2.2 GPU 過濾算法的改進(jìn)

在調(diào)度器過濾階段，除了原有的CPU、memory等過濾以外，本文算法還會(huì)檢查自定義注解對(duì)GPU細(xì)粒度資源的申請(qǐng)，通過對(duì)比pod 申請(qǐng)的資源與GPU 拓展中節(jié)點(diǎn)當(dāng)前可用資源進(jìn)行節(jié)點(diǎn)過濾，將滿足用戶需求的節(jié)點(diǎn)加入可調(diào)度列表。在GPU/CPU混合部署調(diào)度策略下，本文改進(jìn)的過濾算法流程如圖1 所示，具體步驟如下：

圖1 改進(jìn)的過濾算法流程Fig.1 Procedure of improved filtering algorithm

1）根據(jù)pod 的自定義注解判斷pod 是GPU 型還是CPU型，如果是CPU 型應(yīng)用則跳轉(zhuǎn)到步驟2，如果是GPU 型pod 則跳轉(zhuǎn)到步驟3。

2）使用默認(rèn)的過濾策略NodeResourceFit，檢查節(jié)點(diǎn)的空閑資源是否滿足pod 的要求，如果滿足則跳轉(zhuǎn)到步驟4。

3）使用改進(jìn)的過濾策略，在NodeResourceFit 的基礎(chǔ)上，根據(jù)pod 的注解獲取申請(qǐng)的GPU 詳細(xì)信息，包括GPU 卡數(shù)、每塊卡的顯存大小、每塊卡的核心數(shù)量等，檢查GPU 拓展中節(jié)點(diǎn)上空閑GPU 資源是否滿足pod GPU 請(qǐng)求，如果滿足則跳轉(zhuǎn)到步驟4，如果不滿足則跳轉(zhuǎn)到步驟5。

4）節(jié)點(diǎn)滿足pod 請(qǐng)求，將當(dāng)前節(jié)點(diǎn)添加到可用列表，退出。

5）節(jié)點(diǎn)不滿足pod 請(qǐng)求，忽略當(dāng)前節(jié)點(diǎn)，退出。

2.3 混合部署下的調(diào)度策略設(shè)計(jì)與實(shí)現(xiàn)

為了根據(jù)pod 所需的計(jì)算資源類型選出最合適的節(jié)點(diǎn)，調(diào)度器將完成過濾階段的滿足需求的節(jié)點(diǎn)進(jìn)行打分，選擇分?jǐn)?shù)最高的節(jié)點(diǎn)和pod 進(jìn)行綁定。由于GPU 資源比較缺乏，因此在混合計(jì)算資源部署情況下進(jìn)行調(diào)度，本文打分策略的主要思想是為異構(gòu)資源的節(jié)點(diǎn)設(shè)置優(yōu)先級(jí)，優(yōu)先保證CPU 型pod 調(diào)度到CPU 節(jié)點(diǎn)：當(dāng)CPU 節(jié)點(diǎn)資源不足時(shí)，可以調(diào)度到GPU 節(jié)點(diǎn)空閑的CPU上，以提高集群資源利用率；當(dāng)CPU 節(jié)點(diǎn)資源充足時(shí)，如果CPU 應(yīng)用調(diào)度到GPU 節(jié)點(diǎn)，可能會(huì)造成GPU 節(jié)點(diǎn)因?yàn)镃PU 不足而無法被調(diào)度，從而造成GPU 資源浪費(fèi)。

針對(duì)CPU 節(jié)點(diǎn)，使用默認(rèn)調(diào)度器提供的leastRequestedScore，其表示當(dāng)前節(jié)點(diǎn)對(duì)于CPU 型pod 的分?jǐn)?shù)，該算法計(jì)算公式如式（1）所示：

其中：N=｛1，2｝表示CPU 和memory 兩種資源；c表示節(jié)點(diǎn)上資源最大容量；r表示節(jié)點(diǎn)上已請(qǐng)求的資源數(shù)量；w表示資源的權(quán)重，默認(rèn)為0.5；M表示節(jié)點(diǎn)分?jǐn)?shù)的最大值，節(jié)點(diǎn)分?jǐn)?shù)的取值范圍為［0，M］。

在調(diào)度GPU 應(yīng)用時(shí)，根據(jù)GPU 型pod 的需求對(duì)GPU 節(jié)點(diǎn)進(jìn)行打分，將GPU 卡的算力、帶寬和核心3 個(gè)維度的數(shù)據(jù)綜合度量并計(jì)算最終得分。定義Scard為節(jié)點(diǎn)上GPU 卡的性能分?jǐn)?shù)，計(jì)算公式如式（2）所示：

其中：cc代表歸一化后的GPU 算力；bw代表歸一化后的帶寬；cl代表歸一化后的時(shí)鐘；w1、w2、w3默認(rèn)為1/3。

Scard值越高，代表GPU 卡的性能越好，該值使得當(dāng)前打分算法偏好性能更好的GPU。

定義Ssimilarity為當(dāng)前節(jié)點(diǎn)空閑資源向量與pod 申請(qǐng)資源向量的相似度。每個(gè)節(jié)點(diǎn)上空閑的GPU 卡數(shù)為CCard_free，每塊卡的顯存大小為CCard_mem，每塊卡的核心數(shù)量為CCard_core，空閑CPU 的核心數(shù)量為CCPU_free，空閑內(nèi)存大小為CMem_free，則節(jié)點(diǎn)空閑資源向量N可以表示為N=（CCard_free，CCard_mem，CCard_core，CCPU_free，CMem_free）。pod 申請(qǐng)的GPU 卡數(shù)為RCard_num，每塊卡的顯存大小為RCard_mem，每塊卡的核心數(shù)量為RCard_core，pod 申請(qǐng)CPU 核心數(shù)量為RCPU_num，pod 申請(qǐng)內(nèi)存大小為RMem_num，則pod 申請(qǐng)資源向量R可以表示為R=（RCard_num，RCard_mem，RCard_core，RCPU_num，RMem_num）。相似度計(jì)算公式如式（3）所示：

對(duì)于過濾階段得到的候選節(jié)點(diǎn)，空閑資源向量均大于pod 申請(qǐng)資源向量，相似度Ssimilarity使得當(dāng)前打分算法傾向于剩余資源最小的節(jié)點(diǎn)，因?yàn)镚PU 獨(dú)占使用，所以節(jié)點(diǎn)GPU 負(fù)載高不會(huì)互相影響，并且有利于大需求應(yīng)用的調(diào)度。

GPU 節(jié)點(diǎn)打分公式如式（4）所示：

其中：Scard表示GPU 卡自身屬性；Ssimilarity代表節(jié)點(diǎn)資源與pod 申請(qǐng)資源的需求契合程度。

在調(diào)度CPU 應(yīng)用時(shí)，GPU 節(jié)點(diǎn)和CPU 節(jié)點(diǎn)可能同時(shí)滿足pod 需求，本文提出一個(gè)主導(dǎo)資源優(yōu)先級(jí)的算法PriorityScore，保證CPU 節(jié)點(diǎn)資源充足的情況下CPU 節(jié)點(diǎn)的優(yōu)先級(jí)大于GPU 節(jié)點(diǎn)，即CPU 節(jié)點(diǎn)分?jǐn)?shù)一定大于GPU 節(jié)點(diǎn)分?jǐn)?shù)。定義SCPU為節(jié)點(diǎn)針對(duì)CPU 型pod 的分?jǐn)?shù)，計(jì)算公式如式（5）所示：

其中：a是GPU 節(jié)點(diǎn)數(shù)量與集群中節(jié)點(diǎn)總數(shù)的比值。如果SCPU是CPU 節(jié)點(diǎn)，則節(jié)點(diǎn)分?jǐn)?shù)取值范圍為［100×a，100］；如果SCPU是GPU 節(jié)點(diǎn)，節(jié)點(diǎn)分?jǐn)?shù)取值范圍為［0，100×a）。SCPU保證CPU 節(jié)點(diǎn)的分?jǐn)?shù)高于GPU 節(jié)點(diǎn)的分?jǐn)?shù)，只有在CPU 節(jié)點(diǎn)資源不足的情況下，才會(huì)將CPU 應(yīng)用調(diào)度到GPU 節(jié)點(diǎn)。

算法1混合調(diào)度打分算法

3 實(shí)驗(yàn)結(jié)果與分析

實(shí)驗(yàn)采用Kubernetes1.19.5 版本，部署在5 個(gè)物理節(jié)點(diǎn)上，集群中共有1 個(gè)master 節(jié)點(diǎn)、4 個(gè)worker節(jié)點(diǎn)，master 節(jié)點(diǎn)不進(jìn)行應(yīng)用調(diào)度，worker 節(jié)點(diǎn)中2 個(gè)節(jié)點(diǎn)有CPU、2 個(gè)節(jié)點(diǎn)有GPU。實(shí)驗(yàn)環(huán)境配置如表1 所示。

表1 實(shí)驗(yàn)環(huán)境配置 Table 1 Experimental environment configuration

3.1 混合調(diào)度結(jié)果

在集群搭建完成后進(jìn)行混合部署下的實(shí)驗(yàn)驗(yàn)證。測(cè)試pod 的資源請(qǐng)求量如表2 所示，由于每個(gè)節(jié)點(diǎn)上都有Kubernetes 代理組件以及監(jiān)控組件，實(shí)際空閑CPU核心數(shù)量小于表1 中的數(shù)量，因此每個(gè)節(jié)點(diǎn)最多運(yùn)行5個(gè)pod。然后對(duì)集群進(jìn)行壓力測(cè)試，創(chuàng)建20個(gè)測(cè)試pod，其中16 個(gè)為CPU 型pod、4 個(gè)為GPU 型pod，具體步驟為：1）使用默認(rèn)調(diào)度器創(chuàng)建20 個(gè)測(cè)試pod；2）刪除所有測(cè)試pod，使用Kuberentes LabelSelector 將節(jié)點(diǎn)按照資源劃分為CPU 集群和GPU 集群，使用默認(rèn)調(diào)度器分別調(diào)度16 個(gè)CPU 型pod 到CPU 集群、4 個(gè)GPU 型pod 到GPU 集群；3）刪除所有測(cè)試pod，使用本文實(shí)現(xiàn)的自定義調(diào)度器創(chuàng)建與步驟1 相同的20 個(gè)pod。

表2 pod 資源請(qǐng)求量 Table 2 pod resource requests

為了對(duì)比異構(gòu)計(jì)算資源混合部署下使用默認(rèn)調(diào)度器和自定義調(diào)度器的實(shí)驗(yàn)結(jié)果，實(shí)驗(yàn)中只考慮了對(duì)調(diào)度結(jié)果影響最大的CPU 和GPU 兩種計(jì)算資源。通過統(tǒng)計(jì)各個(gè)節(jié)點(diǎn)pod 的類型和數(shù)量，得到節(jié)點(diǎn)上pod 的數(shù)量如圖2 所示。由圖2 可以看出，默認(rèn)調(diào)度器均衡地將CPU 應(yīng)用調(diào)度到各個(gè)節(jié)點(diǎn)。對(duì)于4 個(gè)GPU 型pod，2 個(gè)分別調(diào)度到GPU-node0 和GPUnode1節(jié)點(diǎn)，剩余2 個(gè)因?yàn)镚PU 節(jié)點(diǎn)的CPU 資源不足而處于pending 狀態(tài)。

圖2 CPU/GPU 混合部署下默認(rèn)調(diào)度器實(shí)驗(yàn)結(jié)果Fig.2 Default scheduler experimental results under CPU/GPU hybrid deployment

圖3 為CPU/GPU 獨(dú)立部署下默認(rèn)調(diào)度器的實(shí)驗(yàn)結(jié)果，該部署方式避免了CPU 應(yīng)用占用GPU 節(jié)點(diǎn)的CPU 資源，但是也降低了GPU 節(jié)點(diǎn)的利用率。由圖3 可以看出，分開調(diào)度可以正確調(diào)度同一種資源的應(yīng)用到對(duì)應(yīng)的節(jié)點(diǎn)。雖然GPU 應(yīng)用全部被正確調(diào)度，但是GPU 節(jié)點(diǎn)的CPU 資源沒有被充分利用，因此有部分CPU 型pod 處于pending 狀態(tài)，從而造成CPU 資源的浪費(fèi)。

圖3 CPU/GPU 獨(dú)立部署下默認(rèn)調(diào)度器實(shí)驗(yàn)結(jié)果Fig.3 Default scheduler experimental results under CPU/GPU independent deployment

圖4 為CPU/GPU 混合部署下自定義調(diào)度器的實(shí)驗(yàn)結(jié)果，可以看出GPU 應(yīng)用可以正確調(diào)度到GPU節(jié)點(diǎn)，而CPU 應(yīng)用可以在CPU 節(jié)點(diǎn)資源不足的情況下被調(diào)度到GPU 節(jié)點(diǎn)，充分利用GPU 節(jié)點(diǎn)空閑的CPU 資源，沒有pod 處于pending狀態(tài)。

圖4 CPU/GPU 混合部署下自定義調(diào)度器實(shí)驗(yàn)結(jié)果Fig.4 Custom scheduler experimental results under CPU/GPU hybrid deployment

在GPU 型pod 調(diào)度方面，對(duì)比圖2 和圖4，默認(rèn)調(diào)度器將過多CPU 應(yīng)用調(diào)度到GPU 節(jié)點(diǎn)，從而導(dǎo)致部分GPU 應(yīng)用因?yàn)橘Y源不足而處于pending 狀態(tài)，而本文的自定義調(diào)度器可以感知GPU 應(yīng)用和GPU 節(jié)點(diǎn)，從而充分利用GPU 資源，正確調(diào)度GPU 應(yīng)用到合適的節(jié)點(diǎn)。在CPU型pod調(diào)度方面，對(duì)比圖3和圖4，在CPU和GPU節(jié)點(diǎn)分開部署的情況下，雖然GPU 應(yīng)用得到了正確的調(diào)度，但是GPU 節(jié)點(diǎn)的CPU 資源沒有被充分利用，導(dǎo)致部分的CPU 型pod 處于pending 狀態(tài)，本文的自定義調(diào)度器可以充分利用GPU 節(jié)點(diǎn)上的空閑CPU 資源，從而提高集群資源的利用率。

3.2 細(xì)粒度調(diào)度結(jié)果

對(duì)于GPU 細(xì)粒度調(diào)度測(cè)試，準(zhǔn)備測(cè)試應(yīng)用test1、test2、test3、test4，測(cè)試GPU 型pod 的資源請(qǐng)求量如表3 所示，具體步驟為：1）使用默認(rèn)調(diào)度器按順序創(chuàng)建4 個(gè)pod 運(yùn)行在Kubernetes 集群中；2）刪除測(cè)試的pod，使用自定義調(diào)度器按照同樣的順序啟動(dòng)4 個(gè)測(cè)試pod，記錄各個(gè)節(jié)點(diǎn)pod 的調(diào)度情況。

表3 GPU 型pod 資源請(qǐng)求量 Table 3 GPU-type pod resource requests

表4 為默認(rèn)調(diào)度器調(diào)度細(xì)粒度GPU 型pod 的結(jié)果，其中√表示pod 調(diào)度到對(duì)應(yīng)的節(jié)點(diǎn)。由表4 可以看出，默認(rèn)調(diào)度器由于沒有GPU 顯存指標(biāo)，因此無法根據(jù)顯存大小進(jìn)行細(xì)粒度調(diào)度，只能按照空閑卡數(shù)調(diào)度應(yīng)用到對(duì)應(yīng)的GPU 節(jié)點(diǎn)，導(dǎo)致部分節(jié)點(diǎn)GPU需要的顯存大小與實(shí)際顯存大小不匹配，當(dāng)需要的顯存容量大于實(shí)際顯存容量時(shí)可能會(huì)出現(xiàn)計(jì)算任務(wù)失敗的情況。

表4 默認(rèn)調(diào)度器GPU 型pod 調(diào)度結(jié)果 Table 4 GPU-type pod scheduling results through the default scheduler

利用本文的自定義調(diào)度器可以綜合考慮GPU數(shù)量和顯存大小進(jìn)行調(diào)度，最終得到調(diào)度結(jié)果如表5所示，可以看出集群使用了本文改進(jìn)的自定義調(diào)度器后，GPU 應(yīng)用可以根據(jù)顯存正確地調(diào)度到對(duì)應(yīng)的節(jié)點(diǎn)，從而驗(yàn)證了GPU 細(xì)粒度調(diào)度策略的有效性。

表5 自定義調(diào)度器GPU 型pod 調(diào)度結(jié)果 Table 5 GPU-type pod scheduling results through the custom scheduler

4 結(jié)束語

在異構(gòu)資源混合部署的環(huán)境中，針對(duì)異構(gòu)資源利用不均衡導(dǎo)致集群資源利用率降低的問題，本文提出一種基于Kubernetes 的異構(gòu)資源混合調(diào)度策略。利用異構(gòu)資源調(diào)度策略將CPU 型pod 和GPU 型pod 調(diào)度到合適的節(jié)點(diǎn)，并且在CPU 節(jié)點(diǎn)資源不足的情況下能夠使用GPU 節(jié)點(diǎn)上的CPU 資源，提升集群資源利用率。通過與默認(rèn)調(diào)度算法以及隔離CPU/GPU 集群的方法進(jìn)行對(duì)比，結(jié)果表明本文改進(jìn)的策略可以提升集群CPU 資源利用率，并將GPU 資源調(diào)度到合適的節(jié)點(diǎn)，滿足用戶對(duì)GPU 細(xì)粒度的需求。后續(xù)將研究基于用戶歷史數(shù)據(jù)的資源分配策略，進(jìn)一步提升評(píng)估節(jié)點(diǎn)的實(shí)際使用率。