Kubernetes資源調(diào)度算法的改進(jìn)與實(shí)現(xiàn)①

常旭征,焦文彬

1(中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

2(中國(guó)科學(xué)院大學(xué),北京 100149)

1 引言

云計(jì)算經(jīng)過(guò)十幾年的發(fā)展,其底層的虛擬化技術(shù)已逐漸成熟,而Docker虛擬化技術(shù)由于啟動(dòng)速度快、靈活、輕便等諸多優(yōu)點(diǎn)逐漸成為云計(jì)算領(lǐng)域的熱點(diǎn)[1].各大云計(jì)算廠商也紛紛建立了自己的Docker技術(shù)平臺(tái)[2],與此同時(shí)以Kubernetes[3]為代表的容器編排工具逐漸成為云原生的事實(shí)標(biāo)準(zhǔn),越來(lái)越多的微服務(wù)使用Kubernetes進(jìn)行部署和管理.

Kubernetes 最早來(lái)源于Google的Borg論文,理論基礎(chǔ)較為完善豐富,同時(shí)擴(kuò)展性強(qiáng)、自動(dòng)化程度高,其主要設(shè)計(jì)目標(biāo)是使部署和管理復(fù)雜的分布式系統(tǒng)變得容易[3],它為每個(gè)容器分配IP,并且可以在集群中的任意位置進(jìn)行訪問(wèn),從而提供了一種分布式的環(huán)境[4].

Kubernetes 由一個(gè)master節(jié)點(diǎn)和若干worker節(jié)點(diǎn)組成,master是整個(gè)Kubernetes集群中的控制節(jié)點(diǎn),包括api server、kube-scheduler、controller-manager 三個(gè)組件,其中api server負(fù)責(zé)接收客戶端請(qǐng)求,kubescheduler負(fù)責(zé)對(duì)Kubernetes 中的原子調(diào)度單元pod進(jìn)行調(diào)度,controller-manager 對(duì)Kubernetes 中的控制器進(jìn)行管理,worker節(jié)點(diǎn)是工作節(jié)點(diǎn),用來(lái)運(yùn)行具體的pod.Kubernetes負(fù)責(zé)將用戶的應(yīng)用打包為的異構(gòu)的分布式應(yīng)用程序,從而使其在一組虛擬機(jī)上可用,因此,在這種情況下要解決的一個(gè)重要的問(wèn)題就是調(diào)度或放置這些容器化應(yīng)用程序到一組主機(jī)上.在提交部署應(yīng)用程序時(shí),編排系統(tǒng)需要考慮應(yīng)用程序的特定約束,盡可能充分的利用各種計(jì)算資源,提高集群的負(fù)載均衡,從而降低企業(yè)的成本[5].

Kubernetes的資源調(diào)度算法由于擴(kuò)展性較好,逐漸成為國(guó)內(nèi)外學(xué)者研究的熱點(diǎn).以往的資源調(diào)度算法僅僅關(guān)注優(yōu)選過(guò)程,對(duì)預(yù)選過(guò)程關(guān)注較少,且優(yōu)選過(guò)程未考慮網(wǎng)絡(luò)利用率資源指標(biāo),不能很好的提高集群的負(fù)載均衡效率,且資源利用率的計(jì)算方法也較為復(fù)雜.本文對(duì)Kubernetes資源調(diào)度算法中的預(yù)選和優(yōu)選過(guò)程都進(jìn)行了改進(jìn),且在優(yōu)選過(guò)程中使用了新的資源利用率計(jì)算方式,并且加入了網(wǎng)絡(luò)利用率這一新的指標(biāo),以最大程度的提高整個(gè)集群的負(fù)載均衡效率.

2 Kubernetes 默認(rèn)的資源調(diào)度算法[6]

Kube-scheduler是Kubernetes的集群調(diào)度器,它根據(jù)用戶創(chuàng)建的pod 請(qǐng)求為pod 找到一個(gè)合適的節(jié)點(diǎn)運(yùn)行在其上面[7],這就是調(diào)度pod的過(guò)程.Kubernetes的調(diào)度過(guò)程分為兩部分,分別是預(yù)選和優(yōu)選過(guò)程.

預(yù)選過(guò)程是根據(jù)用戶提交的yaml 文件,遍歷所有node,過(guò)濾掉不符合用戶定義要求的節(jié)點(diǎn),例如用戶定義的pod標(biāo)簽要求使用帶有SSD 硬盤的節(jié)點(diǎn),那么顯然kube-scheduler就不會(huì)把該pod調(diào)度到非SSD節(jié)點(diǎn)上.通過(guò)分析Kubernetes 源碼可知,其內(nèi)置的部分預(yù)選函數(shù)有:Check Node Condition,即檢查節(jié)點(diǎn)是否正常,NoDisk Conflict,即檢測(cè)磁盤不能沖突,Pod Tolerates Node Taints,即檢查pod是否可以容忍節(jié)點(diǎn)上的污點(diǎn)等等.

優(yōu)選過(guò)程則是為預(yù)選過(guò)程選擇出的每個(gè)節(jié)點(diǎn)打分,本文基于Least Requested Priority和Balanced Resource Allocation 兩種原始的算法進(jìn)行,這兩種算法得分為[0,10]中的整數(shù),并且每種算法都有一個(gè)權(quán)重,默認(rèn)為1[8].其中Least Requested Priority的設(shè)計(jì)思想為:node上的CPU和memory 空閑比例的和越大,則當(dāng)前節(jié)點(diǎn)得分越高,這不難理解,因?yàn)镃PU和內(nèi)存空閑比例越大代表當(dāng)前節(jié)點(diǎn)可以容納更多pod,不會(huì)擠占資源占用率高的節(jié)點(diǎn),有利于提高整個(gè)集群的資源利用率和負(fù)載均衡,其計(jì)算公式為:

而B(niǎo)alanced Resource Allocation 設(shè)計(jì)思想為計(jì)算CPU和內(nèi)存利用率之間的差值,差值越小,說(shuō)明CPU和內(nèi)存使用越均衡,從而得分越高,其計(jì)算公式為:

其中,Rcpu代表節(jié)點(diǎn)上已申請(qǐng)的CPU 使用量與當(dāng)前pod申請(qǐng)的CPU容量之和,Rmem代表節(jié)點(diǎn)上已申請(qǐng)的內(nèi)存使用量與當(dāng)前pod申請(qǐng)的內(nèi)存容量之和,Ccpu和Cmem分別代表節(jié)點(diǎn)總的CPU容量和內(nèi)存容量.

3 改進(jìn)的資源調(diào)度算法

從以上分析可以看出,Kubernetes 默認(rèn)的算法的預(yù)選過(guò)程要遍歷所有節(jié)點(diǎn),當(dāng)節(jié)點(diǎn)過(guò)多會(huì)導(dǎo)致預(yù)選耗時(shí)嚴(yán)重,因此可以在預(yù)選過(guò)程中只選出滿足條件的節(jié)點(diǎn)個(gè)數(shù)即可,而無(wú)需輪詢所有節(jié)點(diǎn),因?yàn)楣?jié)點(diǎn)的資源利用率是隨時(shí)變化的,我們關(guān)注的是集群的最終均衡效率,而不是中間的某一個(gè)狀態(tài),輪詢所有節(jié)點(diǎn)后再打分并不代表最終結(jié)果最優(yōu).同時(shí)優(yōu)選過(guò)程只考慮了CPU個(gè)和內(nèi)存利用率,而未關(guān)注節(jié)點(diǎn)本身的網(wǎng)絡(luò)利用率,磁盤利用率等指標(biāo),而當(dāng)今的互聯(lián)網(wǎng)應(yīng)用紛繁復(fù)雜,僅靠CPU和內(nèi)存指標(biāo)顯然無(wú)法反應(yīng)出集群的整體情況.下文將對(duì)優(yōu)選過(guò)程進(jìn)行改進(jìn),對(duì)節(jié)點(diǎn)的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等指標(biāo)綜合考量,以改進(jìn)現(xiàn)有的優(yōu)選過(guò)程算法模型.

3.1 算法設(shè)計(jì)

針對(duì)優(yōu)選過(guò)程,改進(jìn)的資源調(diào)度算法整體思想是合理調(diào)度pod 以提高整個(gè)集群的負(fù)載均衡效率,而對(duì)于負(fù)載均衡效率的計(jì)算,張玉芳等學(xué)者[9]在考慮節(jié)點(diǎn)本身性能的前提下,提出了基于負(fù)載權(quán)值的計(jì)算方法,使用該文獻(xiàn)的方法進(jìn)行負(fù)載的計(jì)算.同時(shí)譚莉等[8]提出的考慮節(jié)點(diǎn)的性能的算法雖然加上了節(jié)點(diǎn)性能的考慮,但對(duì)于互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō),網(wǎng)絡(luò)利用率也是不可忽略的因素,因此本文在原有的負(fù)載均衡計(jì)算上加入網(wǎng)絡(luò)利用率指標(biāo),把CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤IO 四個(gè)維度數(shù)據(jù)綜合考量計(jì)算最終得分.計(jì)算公式為:

其中,L(i)表示節(jié)點(diǎn)負(fù)載,S(i)表示節(jié)點(diǎn)性能.

L(i)的計(jì)算公式為:

其中,L(c)表示CPU 利用率,L(m)表示內(nèi)存利用率,L(n)表示網(wǎng)絡(luò)利用率,L(d)表示磁盤利用率.

S(i)的計(jì)算公式為:

其中,n為CPU核數(shù),S(c)表示CPU 頻率,S(m)表示內(nèi)存容量,S(n)表示網(wǎng)絡(luò)速率,S(d)表示磁盤IO 速率.

3.2 算法流程

3.2.1 獲取節(jié)點(diǎn)資源指標(biāo)

在本實(shí)驗(yàn)中,使用兩個(gè)腳本computeL.sh和computeS.sh分別統(tǒng)計(jì)worker節(jié)點(diǎn)的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤利用率和CPU核數(shù)、內(nèi)存容量、網(wǎng)絡(luò)速率、磁盤讀寫(xiě)速率,分別表示資源利用率和節(jié)點(diǎn)性能.

3.2.2 實(shí)現(xiàn)Kubernetes自定義調(diào)度器

在Kubernetes 官方文檔中,給出了3種實(shí)現(xiàn)自定義調(diào)度器的方法[10]:(1)修改原有的scheduler模塊并重新編譯;(2)重新實(shí)現(xiàn)自己的調(diào)度器模塊;(3)實(shí)現(xiàn)一個(gè)稱為“scheduler extender”的調(diào)度接口,供調(diào)度器調(diào)用決策.本文使用第2種方式并根據(jù)官方例子實(shí)現(xiàn)一個(gè)簡(jiǎn)易的調(diào)度器,這里假設(shè)只有兩個(gè)節(jié)點(diǎn),多個(gè)節(jié)點(diǎn)同理,其流程如圖1所示.

圖1 自定義調(diào)度器執(zhí)行流程

自定義調(diào)度器的運(yùn)行邏輯為一個(gè)輪詢過(guò)程:首先獲取所有標(biāo)簽為my-scheduler 并且尚未綁定節(jié)點(diǎn)的pod,其次在所有worker節(jié)點(diǎn)上分別運(yùn)行computeL.sh和computeS.sh 兩個(gè)腳本獲取資源利用率和節(jié)點(diǎn)性能,然后計(jì)算得到每個(gè)worker節(jié)點(diǎn)得分,最后將當(dāng)前調(diào)度的pod與得分最高的worker節(jié)點(diǎn)進(jìn)行綁定,這個(gè)綁定過(guò)程通過(guò)向api server發(fā)送post 請(qǐng)求完成,從而完成最終的調(diào)度.其偽代碼如下:

Input:各個(gè)節(jié)點(diǎn)的CPU、內(nèi)存、IO、網(wǎng)絡(luò)利用率及CPU核數(shù)和頻率、內(nèi)存容量、網(wǎng)絡(luò)帶寬和磁盤容量.

其中偽代碼第4行和第5行的兩個(gè)函數(shù)computeL()和computeS()分別為根據(jù)Linux 命令獲取節(jié)點(diǎn)性能指標(biāo)的兩個(gè)shell函數(shù).

4 實(shí)驗(yàn)對(duì)比與分析

本實(shí)驗(yàn)采用Kubernetes 1.11版本,通過(guò)虛擬機(jī)的方式部署在臺(tái)式機(jī)上,集群中共有1個(gè)master和3個(gè)worker 共4個(gè)節(jié)點(diǎn),配置如表1所示.

4.1 實(shí)驗(yàn)過(guò)程

1)用默認(rèn)的調(diào)度器搭建完集群后,在集群中起35個(gè)pod,分別執(zhí)行不同的任務(wù),然后使用文獻(xiàn)[9]中的方法計(jì)算集群的均衡負(fù)載;2)刪除原來(lái)的pod,使用文獻(xiàn)[8]的資源調(diào)度算法,重新起與之前一樣的35個(gè)pod,重新計(jì)算集群的負(fù)載均衡效率;3)刪除原來(lái)的pod,使用自定義調(diào)度器,重新起與之前一樣的35個(gè)pod,重新計(jì)算集群的負(fù)載均衡效率;4)對(duì)比3次的實(shí)驗(yàn)結(jié)果找出差異.其中,集群負(fù)載均衡效率計(jì)算方法為:

其中,L(avg)代表節(jié)點(diǎn)的平均負(fù)載,S(avg)代表節(jié)點(diǎn)節(jié)點(diǎn)平均性能,H(i)越大,說(shuō)明集群負(fù)載均衡越好,從而資源調(diào)度算法也就越好.

表1 實(shí)驗(yàn)環(huán)境

4.2 實(shí)驗(yàn)結(jié)果

根據(jù)式(6)分別計(jì)算使用默認(rèn)調(diào)度器、文獻(xiàn)[8]的調(diào)度器(記為調(diào)度器1)和本文實(shí)現(xiàn)的自定義調(diào)度器(記為調(diào)度器2)后集群總體的性能差異,得到對(duì)比結(jié)果如表2所示.

表2 實(shí)驗(yàn)結(jié)果(單位:%)

圖2為使用默認(rèn)調(diào)度器、調(diào)度器1和調(diào)度器2的情況下集群負(fù)載均衡效率柱狀圖對(duì)比,從實(shí)驗(yàn)結(jié)果來(lái)看,3個(gè)worker節(jié)點(diǎn)的集群負(fù)載均衡效率對(duì)比默認(rèn)調(diào)度器和調(diào)度器1 均有不同程度的提升,從而驗(yàn)證了資源調(diào)度策略的有效性.

圖2 實(shí)驗(yàn)結(jié)果

5 結(jié)束語(yǔ)

Kubernetes作為微服務(wù)架構(gòu)最核心的編排工具,其默認(rèn)資源調(diào)度算法的預(yù)選過(guò)程由于要遍歷所有節(jié)點(diǎn),節(jié)點(diǎn)數(shù)量較多時(shí)比較耗時(shí),改進(jìn)的資源調(diào)度算法對(duì)預(yù)選過(guò)程做了優(yōu)化,提出關(guān)注集群最終的資源利用率,而不關(guān)注中間狀態(tài),因此無(wú)需遍歷所有節(jié)點(diǎn)進(jìn)而提升資源調(diào)度效率.同時(shí)針對(duì)優(yōu)選過(guò)程僅僅考慮了CPU和內(nèi)存兩個(gè)指標(biāo),且只是pod申請(qǐng)的CPU和內(nèi)存,并未考慮節(jié)點(diǎn)本身的性能指標(biāo)的問(wèn)題,本文在現(xiàn)有的資源調(diào)度算法研究基礎(chǔ)上,加入了除CPU、內(nèi)存和磁盤外的網(wǎng)絡(luò)利用率和速率,并實(shí)現(xiàn)了自定義調(diào)度器來(lái)應(yīng)用改進(jìn)的資源調(diào)度算法,以期提升集群的整體負(fù)載均衡效率.最后通過(guò)實(shí)驗(yàn)對(duì)比分析驗(yàn)證了算法的有效性.