羅永安,包梓群,趙恪振,余隆勇
(浙江理工大學(xué) 信息學(xué)院,浙江杭州 310018)
Google 開源的Kubernetes 是一個(gè)大規(guī)模容器集群管理系統(tǒng),它對(duì)容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、負(fù)載均衡、自動(dòng)擴(kuò)容等一系列功能,已成為云平臺(tái)的主流。Pod 是Kubernetes 集群上的最基本單元,用于存放一組容器及這些容器的共享資源。Kubernetes 的默認(rèn)資源調(diào)度是按照各工作節(jié)點(diǎn)的資源使用情況和Pod 創(chuàng)建時(shí)請(qǐng)求的資源量進(jìn)行。當(dāng)一個(gè)Pod 被kubernetes 調(diào)度器調(diào)度至合適的工作節(jié)點(diǎn)上,Pod 都不會(huì)在其生命周期結(jié)束前發(fā)生遷移。但是隨著時(shí)間的推進(jìn)和工作節(jié)點(diǎn)上資源的變化,在Pod 創(chuàng)建時(shí)的調(diào)度選擇可能不再適用,集群出現(xiàn)負(fù)載不均衡、資源利用率低等問(wèn)題。
在資源調(diào)度領(lǐng)域,已經(jīng)有諸多學(xué)者做了大量研究工作。Chang 等提出一種基于資源利用率和應(yīng)用QoS 度量指標(biāo)的Kubernetes 資源調(diào)度算法,從靜態(tài)資源的角度提高了調(diào)度有效率;楊鵬飛將ARIMA 模型和神經(jīng)網(wǎng)絡(luò)模型組合預(yù)測(cè)系統(tǒng)資源使用量,并基于此設(shè)計(jì)一種資源借貸的動(dòng)態(tài)調(diào)度算法,減少系統(tǒng)資源碎片化,但對(duì)集群負(fù)載均衡方面考慮較少;唐瑞提出基于Pod 重啟策略確定優(yōu)先級(jí)的動(dòng)態(tài)負(fù)載均衡策略,沒(méi)有考慮Pod 遷移時(shí)對(duì)集群資源的消耗;平凡等提出基于重新調(diào)度Pod 實(shí)現(xiàn)集群系統(tǒng)負(fù)載均衡的調(diào)度模型,其對(duì)于有狀態(tài)服務(wù)的資源動(dòng)態(tài)調(diào)度難以實(shí)現(xiàn)。
針對(duì)以上問(wèn)題,本文提出基于Kubernetes 的資源動(dòng)態(tài)調(diào)度方法,解決Kubernetes 集群各工作節(jié)點(diǎn)長(zhǎng)時(shí)間運(yùn)行情況下集群負(fù)載不均衡的問(wèn)題。使用層次分析法(Analytic Hierarchy Process,AHP)從多維度對(duì)各節(jié)點(diǎn)打分,并以此建立高負(fù)載隊(duì)列。通過(guò)滑動(dòng)窗口從高負(fù)載工作節(jié)點(diǎn)篩選出待遷移Pod 集合并根據(jù)低負(fù)載原則為其選取目標(biāo)工作節(jié)點(diǎn),達(dá)到通過(guò)減少遷移Pod 數(shù)量降低系統(tǒng)消耗的目的。考慮到對(duì)有狀態(tài)服務(wù)的支持,最后通過(guò)技術(shù)遷移(Checkpoint∕Restore In Userspace,CRIU)Pod 實(shí)現(xiàn)資源調(diào)度。
Kubernetes 集群是Master-Slave 模型,是由一個(gè)Master節(jié)點(diǎn)和多個(gè)Node 節(jié)點(diǎn)構(gòu)成。Master 節(jié)點(diǎn)是Kubernetes 的控制節(jié)點(diǎn),通過(guò)API Server 實(shí)現(xiàn)對(duì)集群的調(diào)度和管理。Node是Kubernetes 的工作節(jié)點(diǎn),主要任務(wù)是運(yùn)行Pod 應(yīng)用,通過(guò)kublet 管理和控制Pod。資源動(dòng)態(tài)調(diào)度由監(jiān)控模塊、資源動(dòng)態(tài)調(diào)度算法、遷移模塊組成。監(jiān)控模塊負(fù)責(zé)監(jiān)控Node 工作節(jié)點(diǎn)和Pod 應(yīng)用的資源信息,資源動(dòng)態(tài)調(diào)度算法負(fù)責(zé)選取需要重新調(diào)度的Pod 應(yīng)用以及運(yùn)行待調(diào)度Pod 應(yīng)用的工作節(jié)點(diǎn),遷移模塊基于CRIU 技術(shù)并通過(guò)API Server 控制集群上Pod 應(yīng)用的遷移。本文基于Kubernetes 資源動(dòng)態(tài)調(diào)度機(jī)制設(shè)計(jì)如圖1 所示。
Fig.1 Dynamic resource scheduling mechanism based on Kubernetes圖1 基于Kubernetes 動(dòng)態(tài)資源調(diào)度機(jī)制
Kubernetes 資源動(dòng)態(tài)調(diào)度機(jī)制的工作流程為:通過(guò)Master 節(jié)點(diǎn)上的監(jiān)控模塊監(jiān)控各Node 工作節(jié)點(diǎn)的Kubelet,從中獲取各工作節(jié)點(diǎn)和Pod 應(yīng)用的資源使用狀況。資源動(dòng)態(tài)調(diào)度算法首先會(huì)根據(jù)監(jiān)控得到的各類資源使用情況對(duì)各Node 工作節(jié)點(diǎn)進(jìn)行負(fù)載評(píng)估,應(yīng)用遷移算法,根據(jù)負(fù)載評(píng)估得到的結(jié)果建立高負(fù)載工作節(jié)點(diǎn)隊(duì)列,從高負(fù)載隊(duì)列中選取待遷移Pod 集合,并為其選擇合適的目標(biāo)工作節(jié)點(diǎn),將Pod 應(yīng)用遷移至目標(biāo)工作節(jié)點(diǎn),將集群信息更新至Etcd存儲(chǔ)器中。
為了評(píng)估和比較各工作節(jié)點(diǎn)和Pod 應(yīng)用的負(fù)載狀況,使用數(shù)學(xué)表達(dá)式表示工作節(jié)點(diǎn)和Pod 應(yīng)用的資源使用情況。選取CPU 利用率、內(nèi)存利用率、帶寬使用率、磁盤利用率作為工作節(jié)點(diǎn)的負(fù)載因子,從多維度評(píng)估工作節(jié)點(diǎn)的負(fù)載狀況,并通過(guò)AHP(Analytic Hierarchy Process,層次分析法)建立模型。構(gòu)造一個(gè)判斷矩陣,該判斷矩陣用來(lái)表示選取的4個(gè)負(fù)載因子的相對(duì)優(yōu)越程度。采用1~9 將4個(gè)負(fù)載因子的相對(duì)優(yōu)越程度進(jìn)行量化,構(gòu)造出一個(gè)兩兩比較的判斷矩陣,其形式如下:
a
表示負(fù)載因子,a
表示CPU 利用率,a
表示內(nèi)存利用率,a
表示帶寬利用率,a
表示磁盤利用率。a
表示a
對(duì)a
的相對(duì)重要程度,通常采用1、3、5、7、9 及其倒數(shù),2、4、6、8 表示第i
個(gè)因素相對(duì)于第j
個(gè)因素的影響介于上述兩個(gè)相鄰的等級(jí)之間。通過(guò)合法求解矩陣的排序向量得到各負(fù)載因子的權(quán)重。其步驟如下:
(1)將矩陣A
的列向量歸一化:A
按行得到:W
歸一化,得到:A
的最大特征值。CI
指標(biāo)衡量矩陣的一致性程度。CI
的值越大,其判斷矩陣的一致性越差,若CI
=0,則該判斷矩陣具有完全一致性。為了衡量CI
的大小,又引入隨機(jī)一致性指標(biāo)RI
,本文選取4個(gè)負(fù)載因子,RI
=0.90。其判斷矩陣的一致性比率為:CR
<0.1 時(shí),認(rèn)為A
的不一致程度在容許范圍內(nèi),可以通過(guò)一致性檢驗(yàn),可用其歸一化特征向量作為權(quán)向量,否則要重新構(gòu)造成判斷矩陣A
,對(duì)a
加以調(diào)整。本文將判斷矩陣構(gòu)造如下:W
=(0.523 7,0.270 8,0.135 3,0.070 2)。其矩陣的最大特征根λ
=4.0019,從而得到CI
和RI
。由上可知,該判斷矩陣滿足一致性。
在經(jīng)計(jì)算得到選取的4個(gè)負(fù)載因子的相對(duì)權(quán)重基礎(chǔ)上,通過(guò)監(jiān)控得到的性能指標(biāo)向量為a=(a
,a
,a
,a
)。得到節(jié)點(diǎn)和Pod 的負(fù)載評(píng)價(jià)度量值R
如下:R
越大代表該負(fù)載越重,反之代表其負(fù)載較小,R
的最大值是100。R
大于觸發(fā)閾值,說(shuō)明該工作節(jié)點(diǎn)的資源使用將達(dá)到臨界狀態(tài),其觸發(fā)閾值的公式如下:R
表示各工作節(jié)點(diǎn)的負(fù)載評(píng)價(jià)度量值,i
∈{1,2,…,i
,…,n
},α
為均衡系數(shù)決定系統(tǒng)觸發(fā)閾值大小。為了避免Pod 不停遷移而出現(xiàn)系統(tǒng)抖動(dòng),以多次觸發(fā)閾值為依據(jù)建立高負(fù)載工作節(jié)點(diǎn)隊(duì)列,然后基于滑動(dòng)窗口設(shè)計(jì)選取遷移Pod算法,從高負(fù)載工作節(jié)點(diǎn)中挑選出待遷移Pod 集合,通過(guò)預(yù)選和優(yōu)選選擇出合適的工作節(jié)點(diǎn),應(yīng)用遷移算法總體框架如圖2 所示。具體算法流程描述如下:
Step1:輸入計(jì)算得到的各工作節(jié)點(diǎn)的負(fù)載評(píng)價(jià)度量值R
Step2:判斷各工作節(jié)點(diǎn)的負(fù)載評(píng)價(jià)度量值是否大于其觸發(fā)閾值T
,如果是則繼續(xù)進(jìn)行Step3,如果不是將不會(huì)對(duì)該工作節(jié)點(diǎn)上的Pod 進(jìn)行遷移。Step3:分析Step2 中的工作節(jié)點(diǎn)的歷史負(fù)載數(shù)據(jù),如果其負(fù)載值連續(xù)3 次都大于觸發(fā)閾值T
,則認(rèn)為它是過(guò)載的工作節(jié)點(diǎn),將其放入高負(fù)載工作節(jié)點(diǎn)隊(duì)列中。Step4:如果高負(fù)載工作節(jié)點(diǎn)隊(duì)列不為空,取出隊(duì)列的頭節(jié)點(diǎn),對(duì)其Pod 進(jìn)行遷移。如果高負(fù)載工作節(jié)點(diǎn)隊(duì)列為空,則結(jié)束這次動(dòng)態(tài)資源調(diào)度,等待下一個(gè)時(shí)間周期的動(dòng)態(tài)資源調(diào)度。
Step5:在Step4 中取出的高負(fù)載工作節(jié)點(diǎn)選取待遷移的Pod 集合。
Step6:對(duì)Step5 中選取的Pod 集合選取合適的目標(biāo)工作節(jié)點(diǎn)。如果找到,則對(duì)該P(yáng)od 進(jìn)行遷移;如果未找到,不遷移該P(yáng)od 等待下一次資源動(dòng)態(tài)調(diào)度。直到將Pod 集合全部處理完,則該工作節(jié)點(diǎn)處理完畢。繼續(xù)進(jìn)行Step4,處理剩下的高負(fù)載工作節(jié)點(diǎn)。
Fig.2 Application migration algorithm overall framework圖2 應(yīng)用遷移算法總體框架
2.2.1 遷移Pod 選取
每一個(gè)Pod 遷移都需要消耗集群系統(tǒng)資源,因此需要盡可能選取少量的Pod 進(jìn)行遷移。每個(gè)Pod 的負(fù)載均衡度量值按照式(7)計(jì)算得到R
。當(dāng)選取的Pod 的R
過(guò)大,可能會(huì)找不到合適的工作節(jié)點(diǎn)運(yùn)行該P(yáng)od;當(dāng)選取的Pod 的R
過(guò)小,要遷移多個(gè)Pod 才可實(shí)現(xiàn)負(fù)載均衡,降低了集群系統(tǒng)效率。通過(guò)將高負(fù)載工作節(jié)點(diǎn)的負(fù)載評(píng)價(jià)度量值和集群節(jié)點(diǎn)的平均負(fù)載度量值差值作為滑動(dòng)窗口大小值,在其窗口內(nèi)選擇遷移數(shù)量最少的Pod 進(jìn)行遷移。通過(guò)滑動(dòng)窗口選取遷移Pod 的算法如下:輸入:觸發(fā)遷移Pod 工作節(jié)點(diǎn)上的Pod 集合
輸出:待遷移的Pod 集合
Step1:將Pod 集合數(shù)組按照負(fù)載評(píng)價(jià)度量值R
從小到大進(jìn)行排序。Step2:初始化兩個(gè)指針i
、j
指向排序后Pod 集合數(shù)組的第一個(gè)元素;初始化num 存放符合條件的Pod 最小個(gè)數(shù),其初值為Pod 的個(gè)數(shù);
初始化兩個(gè)指針p
、q
分別存放符合條件的i
、j
指針位置,其初值為空指針;初始化一個(gè)sum 存放可能遷移Pod 負(fù)載評(píng)價(jià)度量值總值,初值為第一個(gè)元素的負(fù)載評(píng)價(jià)度量值;
初始化一個(gè)window 存放應(yīng)該遷移的Pod 的負(fù)載評(píng)價(jià)度量總值,其初值為該工作節(jié)點(diǎn)的負(fù)載評(píng)價(jià)度量值減去集群節(jié)點(diǎn)的平均負(fù)載度量值。
Step3:當(dāng)指 針i
指 向的Pod 和指 針j
指向的Pod 為同一個(gè)Pod 或者i<j
時(shí)進(jìn)入Step4 循環(huán),否則進(jìn)入Step5。Step4:sum 值小于0.9window,則指針j
指向下一Pod,sum 加上該P(yáng)od 的負(fù)載評(píng)價(jià)度量值;sum 值在0.9window~1.1window 之間,更新num 值,其取值為當(dāng)前num 值和指針i
、j
之間Pod個(gè)數(shù)的最小值。若num的值改變,并將p
、q
指針指向當(dāng)前i
、j
指針。指針j
指向下一個(gè)Pod,sum 加上該P(yáng)od 的負(fù)載評(píng)價(jià)度量值;sum 值大于1.1sh,則指針i
指向下一個(gè)Pod。sum 減去該P(yáng)od 的負(fù)載評(píng)價(jià)度量值;Step5:p
、q
指針指向及其之間的Pod 即為待遷移的Pod集合。2.2.2 目標(biāo)工作節(jié)點(diǎn)選取
為待遷移的Pod 選取新的工作節(jié)點(diǎn)要通過(guò)預(yù)選和優(yōu)選兩個(gè)階段。在預(yù)選階段對(duì)各工作節(jié)點(diǎn)進(jìn)行檢查,按照待遷移Pod 端口是否被工作節(jié)點(diǎn)占用、工作節(jié)點(diǎn)是否有足夠資源運(yùn)行待遷移Pod、工作節(jié)點(diǎn)是否存在儲(chǔ)存卷沖突的篩選策略,過(guò)濾掉不符合條件的工作節(jié)點(diǎn),篩選出可以運(yùn)行遷移Pod 的工作節(jié)點(diǎn)。優(yōu)選階段會(huì)對(duì)預(yù)選出的工作節(jié)點(diǎn)按照式(7)進(jìn)行負(fù)載評(píng)估得到負(fù)載評(píng)價(jià)度量值,按照負(fù)載評(píng)價(jià)度量值進(jìn)行優(yōu)先級(jí)排序,負(fù)載評(píng)價(jià)度量值越大優(yōu)先級(jí)越小,反之優(yōu)先級(jí)越大,選出最合適Pod 對(duì)象的工作節(jié)點(diǎn)。
目標(biāo)工作節(jié)點(diǎn)選取算法如下:
輸入:待遷移的Pod 集合資源描述文件,所有工作節(jié)點(diǎn)資源描述文件
輸出:目標(biāo)工作節(jié)點(diǎn)
Step1:按照待遷移Pod 的負(fù)載評(píng)價(jià)度量值R
將Pod 應(yīng)用從大到小排成隊(duì)列,依次為隊(duì)列中Pod 應(yīng)用選取目標(biāo)工作節(jié)點(diǎn)。Step2:將所有工作節(jié)點(diǎn)按照預(yù)選階段篩選策略過(guò)濾得到候選工作節(jié)點(diǎn)隊(duì)列,如果候選工作節(jié)點(diǎn)隊(duì)列為空,選取待遷移Pod 隊(duì)列中的下一個(gè)Pod,重新進(jìn)行Step2;不為空,進(jìn)行下一步。
Step3:將Step2 中得到的候選工作節(jié)點(diǎn)隊(duì)列按照負(fù)載評(píng)價(jià)度量值R
將候選工作節(jié)點(diǎn)從小到大排成隊(duì)列。Step4:選取Step3 中負(fù)載評(píng)價(jià)度量值R
最小的工作節(jié)點(diǎn)作為目標(biāo)節(jié)點(diǎn),并且更新該目標(biāo)工作節(jié)點(diǎn)的資源狀況。選取待遷移Pod 隊(duì)列中的下一個(gè)Pod,重新進(jìn)行Step2。3.1.1 實(shí)驗(yàn)環(huán)境
為了驗(yàn)證動(dòng)態(tài)調(diào)度資源的有效性和可行性,搭建了一個(gè)Kubernetes集群,其中K8s使用1.16版本,Docker使用18.09.06版本。實(shí)驗(yàn)在4臺(tái)不同規(guī)格系數(shù)的服務(wù)器節(jié)點(diǎn)上完成。其中,1臺(tái)作為Master 節(jié)點(diǎn),3臺(tái)作為Node 節(jié)點(diǎn)。其每個(gè)虛擬機(jī)的具體配置如表1 所示。
Table 1 Test virtual machine configuration表1 測(cè)試虛擬機(jī)配置
Pod 應(yīng)用選取服務(wù)器上常見(jiàn)的JavaWeb 應(yīng)用,其主要需要的程序?yàn)門omcat 和Mysql 數(shù)據(jù)庫(kù),為有狀態(tài)服務(wù)。在Tomcat 上運(yùn)行Java 程序,并且該程序可以向Mysql 寫入數(shù)據(jù),并可修改和刪除數(shù)據(jù),同時(shí)可以統(tǒng)計(jì)Mysql 中的數(shù)據(jù)。將Tomcat 和Mysql 兩個(gè)Docker 放入一個(gè)Pod 中,該應(yīng)用充分利用了服務(wù)器的CPU、內(nèi)存、磁盤以及網(wǎng)絡(luò)寬帶資源。
3.1.2 實(shí)驗(yàn)設(shè)計(jì)分析
除Kubernetes 默認(rèn)采用的資源調(diào)度策略,基于優(yōu)先級(jí)的資源調(diào)度也是常見(jiàn)資源調(diào)度策略,將待調(diào)度隊(duì)列按照一定優(yōu)先級(jí)排序,將優(yōu)先級(jí)高的先調(diào)度,優(yōu)先級(jí)低的后調(diào)度,其調(diào)度策略可以較好地維持系統(tǒng)負(fù)載均衡并提升系統(tǒng)性能。文獻(xiàn)[6]中基于Pod 的重啟策略確定優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度策略被廣泛應(yīng)用,本文在其基礎(chǔ)上進(jìn)一步增加了基于優(yōu)先級(jí)的資源調(diào)度在負(fù)載評(píng)估和遷移消耗方面的深入調(diào)度策略研究。
為了驗(yàn)證本文所設(shè)計(jì)的資源調(diào)度算法的有效性,在集群上分別運(yùn)行Kubernetes 默認(rèn)資源調(diào)度,將文獻(xiàn)[6]中基于優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度與本文設(shè)計(jì)的資源動(dòng)態(tài)調(diào)度進(jìn)行對(duì)比實(shí)驗(yàn)。在集群中每隔5min 為集群發(fā)布20個(gè)Pod 應(yīng)用,共發(fā)布100個(gè)Pod。使用JMeter 對(duì)Kubernetes 集群中的Pod應(yīng)用發(fā)送HTTP 請(qǐng)求,請(qǐng)求數(shù)量和請(qǐng)求端口都是隨機(jī)生成。每次發(fā)布應(yīng)用后,記錄集群的負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差,集群運(yùn)行4.5min 后再記錄一次負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差,同時(shí)記錄每次資源動(dòng)態(tài)調(diào)度時(shí)的Pod 遷移數(shù)量。
通常衡量資源動(dòng)態(tài)調(diào)度性能,主要從負(fù)載均衡度和資源消耗兩方面考慮。本文通過(guò)負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差和Pod 遷移數(shù)量對(duì)其進(jìn)行評(píng)價(jià)。
(1)負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差。用Std 標(biāo)準(zhǔn)差衡量集群中所有節(jié)點(diǎn)的負(fù)載差異:
average
為集群的系統(tǒng)平均分,計(jì)算公式如下:std 用來(lái)衡量集群中所有節(jié)點(diǎn)的負(fù)載差異,得分標(biāo)準(zhǔn)差越大,各節(jié)點(diǎn)負(fù)載差別越大,反之系統(tǒng)更加均衡。
(2)Pod 遷移數(shù)量。本文采取CRIU 技術(shù)實(shí)現(xiàn)Pod 遷移,在內(nèi)存復(fù)制過(guò)程中會(huì)在源服務(wù)器和目標(biāo)服務(wù)器上消耗額外的CPU 資源,還會(huì)消耗額外的網(wǎng)絡(luò)帶寬,都會(huì)影響集群的資源利用率。Pod 遷移數(shù)量越少,集群在資源動(dòng)態(tài)調(diào)度時(shí)所消耗的資源越少。
3 種運(yùn)行不同資源調(diào)度集群的負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差變化比較如圖3 所示。默認(rèn)的資源動(dòng)態(tài)調(diào)度在3、5、7、9 次記錄時(shí)因調(diào)度器集群負(fù)載均衡度較好,在第2、4、6、8、10 次采集時(shí),因JMeter 不斷請(qǐng)求,節(jié)點(diǎn)資源狀況發(fā)生變化,負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差大。本文設(shè)計(jì)的資源動(dòng)態(tài)調(diào)度和基于優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度在前兩次采集時(shí)因Pod 數(shù)量較少,JMeter 的請(qǐng)求可能集中在某個(gè)工作節(jié)點(diǎn)上而又未能達(dá)到動(dòng)態(tài)調(diào)度的觸發(fā)閾值,負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差較大,隨著Pod 數(shù)量的增多,觸發(fā)動(dòng)態(tài)資源調(diào)度,在之后的時(shí)間里集群負(fù)載均衡度較好。系統(tǒng)整體負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差比基于優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度低17%,負(fù)載均衡度更好,原因是從多維度評(píng)估系統(tǒng)負(fù)載狀況,在資源動(dòng)態(tài)調(diào)度時(shí),可以更加精準(zhǔn)地實(shí)現(xiàn)集群負(fù)載均衡。
Fig.3 Comparison of changes in load evaluation standard deviation圖3 負(fù)載評(píng)價(jià)標(biāo)準(zhǔn)差變化比較
在Pod 遷移數(shù)量方面,Kubernetes 默認(rèn)資源調(diào)度Pod 一旦運(yùn)行就不會(huì)發(fā)生遷移,采用基于優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度和本文設(shè)計(jì)的動(dòng)態(tài)資源調(diào)度在實(shí)驗(yàn)期間觸發(fā)了4 次Pod 遷移,其Pod 遷移數(shù)量如圖4 所示??梢钥闯?,本文設(shè)計(jì)的動(dòng)態(tài)資源調(diào)度遷移Pod 數(shù)量相對(duì)于優(yōu)先級(jí)資源動(dòng)態(tài)調(diào)度平均減少88.3%,降低了系統(tǒng)資源調(diào)度時(shí)的消耗。由于本文采用滑動(dòng)窗口根據(jù)Pod 的負(fù)載狀況篩選遷移Pod 集合,在能夠?qū)崿F(xiàn)集群負(fù)載均衡的條件下控制Pod 遷移數(shù)量。
Fig.4 Comparison of changes in the number of Pod migrations圖4 Pod 遷移數(shù)量變化比較
本文在Kubernetes 集群系統(tǒng)上設(shè)計(jì)了基于Pod 遷移的資源動(dòng)態(tài)調(diào)度,實(shí)現(xiàn)集群負(fù)載均衡。通過(guò)監(jiān)控模塊采集各工作節(jié)點(diǎn)和Pod 應(yīng)用的資源信息,使用層次分析法將其轉(zhuǎn)化為比較客觀、準(zhǔn)確的綜合評(píng)價(jià)結(jié)果,在高負(fù)載隊(duì)列中使用滑動(dòng)窗口篩選出Pod 遷移集合,達(dá)到遷移少量Pod 實(shí)現(xiàn)資源動(dòng)態(tài)調(diào)動(dòng)的目的。從實(shí)驗(yàn)結(jié)果可以看出,本文的動(dòng)態(tài)資源調(diào)度算法相比與Kubernetes 的默認(rèn)調(diào)度算法更能維護(hù)集群的穩(wěn)定性,相比于基于優(yōu)先級(jí)的資源動(dòng)態(tài)調(diào)度所消耗的系統(tǒng)資源更少。考慮到集群上可能運(yùn)行不同類型的Pod應(yīng)用,本文將在現(xiàn)有研究基礎(chǔ)上,進(jìn)一步結(jié)合資源類型進(jìn)行深入研究。