Kubernetes 的資源動態(tài)調(diào)度設計研究

羅永安，包梓群，趙恪振，余隆勇

（浙江理工大學 信息學院，浙江杭州 310018）

0 引言

Google 開源的Kubernetes 是一個大規(guī)模容器集群管理系統(tǒng)，它對容器化的應用提供部署運行、資源調(diào)度、負載均衡、自動擴容等一系列功能，已成為云平臺的主流。Pod 是Kubernetes 集群上的最基本單元，用于存放一組容器及這些容器的共享資源。Kubernetes 的默認資源調(diào)度是按照各工作節(jié)點的資源使用情況和Pod 創(chuàng)建時請求的資源量進行。當一個Pod 被kubernetes 調(diào)度器調(diào)度至合適的工作節(jié)點上，Pod 都不會在其生命周期結束前發(fā)生遷移。但是隨著時間的推進和工作節(jié)點上資源的變化，在Pod 創(chuàng)建時的調(diào)度選擇可能不再適用，集群出現(xiàn)負載不均衡、資源利用率低等問題。

在資源調(diào)度領域，已經(jīng)有諸多學者做了大量研究工作。Chang 等提出一種基于資源利用率和應用QoS 度量指標的Kubernetes 資源調(diào)度算法，從靜態(tài)資源的角度提高了調(diào)度有效率；楊鵬飛將ARIMA 模型和神經(jīng)網(wǎng)絡模型組合預測系統(tǒng)資源使用量，并基于此設計一種資源借貸的動態(tài)調(diào)度算法，減少系統(tǒng)資源碎片化，但對集群負載均衡方面考慮較少；唐瑞提出基于Pod 重啟策略確定優(yōu)先級的動態(tài)負載均衡策略，沒有考慮Pod 遷移時對集群資源的消耗；平凡等提出基于重新調(diào)度Pod 實現(xiàn)集群系統(tǒng)負載均衡的調(diào)度模型，其對于有狀態(tài)服務的資源動態(tài)調(diào)度難以實現(xiàn)。

針對以上問題，本文提出基于Kubernetes 的資源動態(tài)調(diào)度方法，解決Kubernetes 集群各工作節(jié)點長時間運行情況下集群負載不均衡的問題。使用層次分析法（Analytic Hierarchy Process，AHP）從多維度對各節(jié)點打分，并以此建立高負載隊列。通過滑動窗口從高負載工作節(jié)點篩選出待遷移Pod 集合并根據(jù)低負載原則為其選取目標工作節(jié)點，達到通過減少遷移Pod 數(shù)量降低系統(tǒng)消耗的目的?？紤]到對有狀態(tài)服務的支持，最后通過技術遷移（Checkpoint∕Restore In Userspace，CRIU）Pod 實現(xiàn)資源調(diào)度。

1 資源動態(tài)調(diào)度機制設計

Kubernetes 集群是Master-Slave 模型，是由一個Master節(jié)點和多個Node 節(jié)點構成。Master 節(jié)點是Kubernetes 的控制節(jié)點，通過API Server 實現(xiàn)對集群的調(diào)度和管理。Node是Kubernetes 的工作節(jié)點，主要任務是運行Pod 應用，通過kublet 管理和控制Pod。資源動態(tài)調(diào)度由監(jiān)控模塊、資源動態(tài)調(diào)度算法、遷移模塊組成。監(jiān)控模塊負責監(jiān)控Node 工作節(jié)點和Pod 應用的資源信息，資源動態(tài)調(diào)度算法負責選取需要重新調(diào)度的Pod 應用以及運行待調(diào)度Pod 應用的工作節(jié)點，遷移模塊基于CRIU 技術并通過API Server 控制集群上Pod 應用的遷移。本文基于Kubernetes 資源動態(tài)調(diào)度機制設計如圖1 所示。

Fig.1 Dynamic resource scheduling mechanism based on Kubernetes圖1 基于Kubernetes 動態(tài)資源調(diào)度機制

Kubernetes 資源動態(tài)調(diào)度機制的工作流程為：通過Master 節(jié)點上的監(jiān)控模塊監(jiān)控各Node 工作節(jié)點的Kubelet，從中獲取各工作節(jié)點和Pod 應用的資源使用狀況。資源動態(tài)調(diào)度算法首先會根據(jù)監(jiān)控得到的各類資源使用情況對各Node 工作節(jié)點進行負載評估，應用遷移算法，根據(jù)負載評估得到的結果建立高負載工作節(jié)點隊列，從高負載隊列中選取待遷移Pod 集合，并為其選擇合適的目標工作節(jié)點，將Pod 應用遷移至目標工作節(jié)點，將集群信息更新至Etcd存儲器中。

2 資源動態(tài)調(diào)度算法設計

2.1 負載評估

為了評估和比較各工作節(jié)點和Pod 應用的負載狀況，使用數(shù)學表達式表示工作節(jié)點和Pod 應用的資源使用情況。選取CPU 利用率、內(nèi)存利用率、帶寬使用率、磁盤利用率作為工作節(jié)點的負載因子，從多維度評估工作節(jié)點的負載狀況，并通過AHP（Analytic Hierarchy Process，層次分析法）建立模型。構造一個判斷矩陣，該判斷矩陣用來表示選取的4個負載因子的相對優(yōu)越程度。采用1～9 將4個負載因子的相對優(yōu)越程度進行量化，構造出一個兩兩比較的判斷矩陣，其形式如下：

其中，

a

表示負載因子，

a

表示CPU 利用率，

a

表示內(nèi)存利用率，

a

表示帶寬利用率，

a

表示磁盤利用率。

a

表示

a

對

a

的相對重要程度，通常采用1、3、5、7、9 及其倒數(shù)，2、4、6、8 表示第

i

個因素相對于第

j

個因素的影響介于上述兩個相鄰的等級之間。

通過合法求解矩陣的排序向量得到各負載因子的權重。其步驟如下：

（1）將矩陣

A

的列向量歸一化：

（2）

A

按行得到：

（3）將

W

歸一化，得到：

（4）最后，得到判斷矩陣

A

的最大特征值。

為了避免因判斷矩陣不一致而影響其可行性，要對矩陣進行一致性檢驗。AHP 通過

CI

指標衡量矩陣的一致性程度。

其中，

CI

的值越大，其判斷矩陣的一致性越差，若

CI

=0，則該判斷矩陣具有完全一致性。為了衡量

CI

的大小，又引入隨機一致性指標

RI

，本文選取4個負載因子，

RI

=0.90。其判斷矩陣的一致性比率為：

若

CR

<0.1 時，認為

A

的不一致程度在容許范圍內(nèi)，可以通過一致性檢驗，可用其歸一化特征向量作為權向量，否則要重新構造成判斷矩陣

A

，對

a

加以調(diào)整。本文將判斷矩陣構造如下：

根據(jù)上述公式可得其相對權重向量

W

=(0.523 7,0.270 8,0.135 3,0.070 2)。其矩陣的最大特征根

λ

=4.0019，從而得到

CI

和

RI

。

由上可知，該判斷矩陣滿足一致性。

在經(jīng)計算得到選取的4個負載因子的相對權重基礎上，通過監(jiān)控得到的性能指標向量為a=(

a

,

a

,

a

,

a

)。得到節(jié)點和Pod 的負載評價度量值

R

如下：

其中，

R

越大代表該負載越重，反之代表其負載較小，

R

的最大值是100。

2.2 應用遷移

當某一工作節(jié)點的負載評價度量值

R

大于觸發(fā)閾值，說明該工作節(jié)點的資源使用將達到臨界狀態(tài)，其觸發(fā)閾值的公式如下：

其中，

R

表示各工作節(jié)點的負載評價度量值，

i

∈{1,2,…,

i

,…,

n

}，

α

為均衡系數(shù)決定系統(tǒng)觸發(fā)閾值大小。為了避免Pod 不停遷移而出現(xiàn)系統(tǒng)抖動，以多次觸發(fā)閾值為依據(jù)建立高負載工作節(jié)點隊列，然后基于滑動窗口設計選取遷移Pod算法，從高負載工作節(jié)點中挑選出待遷移Pod 集合，通過預選和優(yōu)選選擇出合適的工作節(jié)點，應用遷移算法總體框架如圖2 所示。

具體算法流程描述如下：

Step1：輸入計算得到的各工作節(jié)點的負載評價度量值R

Step2：判斷各工作節(jié)點的負載評價度量值是否大于其觸發(fā)閾值

T

，如果是則繼續(xù)進行Step3，如果不是將不會對該工作節(jié)點上的Pod 進行遷移。Step3：分析Step2 中的工作節(jié)點的歷史負載數(shù)據(jù)，如果其負載值連續(xù)3 次都大于觸發(fā)閾值

T

，則認為它是過載的工作節(jié)點，將其放入高負載工作節(jié)點隊列中。

Step4：如果高負載工作節(jié)點隊列不為空，取出隊列的頭節(jié)點，對其Pod 進行遷移。如果高負載工作節(jié)點隊列為空，則結束這次動態(tài)資源調(diào)度，等待下一個時間周期的動態(tài)資源調(diào)度。

Step5：在Step4 中取出的高負載工作節(jié)點選取待遷移的Pod 集合。

Step6：對Step5 中選取的Pod 集合選取合適的目標工作節(jié)點。如果找到，則對該Pod 進行遷移；如果未找到，不遷移該Pod 等待下一次資源動態(tài)調(diào)度。直到將Pod 集合全部處理完，則該工作節(jié)點處理完畢。繼續(xù)進行Step4，處理剩下的高負載工作節(jié)點。

Fig.2 Application migration algorithm overall framework圖2 應用遷移算法總體框架

2.2.1 遷移Pod 選取

每一個Pod 遷移都需要消耗集群系統(tǒng)資源，因此需要盡可能選取少量的Pod 進行遷移。每個Pod 的負載均衡度量值按照式（7）計算得到

R

。當選取的Pod 的

R

過大，可能會找不到合適的工作節(jié)點運行該Pod；當選取的Pod 的

R

過小，要遷移多個Pod 才可實現(xiàn)負載均衡，降低了集群系統(tǒng)效率。通過將高負載工作節(jié)點的負載評價度量值和集群節(jié)點的平均負載度量值差值作為滑動窗口大小值，在其窗口內(nèi)選擇遷移數(shù)量最少的Pod 進行遷移。通過滑動窗口選取遷移Pod 的算法如下：

輸入：觸發(fā)遷移Pod 工作節(jié)點上的Pod 集合

輸出：待遷移的Pod 集合

Step1：將Pod 集合數(shù)組按照負載評價度量值

R

從小到大進行排序。Step2：初始化兩個指針

i

、

j

指向排序后Pod 集合數(shù)組的第一個元素；

初始化num 存放符合條件的Pod 最小個數(shù)，其初值為Pod 的個數(shù)；

初始化兩個指針

p

、

q

分別存放符合條件的

i

、

j

指針位置，其初值為空指針；

初始化一個sum 存放可能遷移Pod 負載評價度量值總值，初值為第一個元素的負載評價度量值；

初始化一個window 存放應該遷移的Pod 的負載評價度量總值，其初值為該工作節(jié)點的負載評價度量值減去集群節(jié)點的平均負載度量值。

Step3：當指 針

i

指 向的Pod 和指 針

j

指向的Pod 為同一個Pod 或者

i＜j

時進入Step4 循環(huán)，否則進入Step5。Step4：sum 值小于0.9window，則指針

j

指向下一Pod，sum 加上該Pod 的負載評價度量值；sum 值在0.9window～1.1window 之間，更新num 值，其取值為當前num 值和指針

i

、

j

之間Pod個數(shù)的最小值。若num的值改變，并將

p

、

q

指針指向當前

i

、

j

指針。指針

j

指向下一個Pod，sum 加上該Pod 的負載評價度量值；sum 值大于1.1sh，則指針

i

指向下一個Pod。sum 減去該Pod 的負載評價度量值；Step5：

p

、

q

指針指向及其之間的Pod 即為待遷移的Pod集合。

2.2.2 目標工作節(jié)點選取

為待遷移的Pod 選取新的工作節(jié)點要通過預選和優(yōu)選兩個階段。在預選階段對各工作節(jié)點進行檢查，按照待遷移Pod 端口是否被工作節(jié)點占用、工作節(jié)點是否有足夠資源運行待遷移Pod、工作節(jié)點是否存在儲存卷沖突的篩選策略，過濾掉不符合條件的工作節(jié)點，篩選出可以運行遷移Pod 的工作節(jié)點。優(yōu)選階段會對預選出的工作節(jié)點按照式（7）進行負載評估得到負載評價度量值，按照負載評價度量值進行優(yōu)先級排序，負載評價度量值越大優(yōu)先級越小，反之優(yōu)先級越大，選出最合適Pod 對象的工作節(jié)點。

目標工作節(jié)點選取算法如下：

輸入：待遷移的Pod 集合資源描述文件，所有工作節(jié)點資源描述文件

輸出：目標工作節(jié)點

Step1：按照待遷移Pod 的負載評價度量值

R

將Pod 應用從大到小排成隊列，依次為隊列中Pod 應用選取目標工作節(jié)點。

Step2：將所有工作節(jié)點按照預選階段篩選策略過濾得到候選工作節(jié)點隊列，如果候選工作節(jié)點隊列為空，選取待遷移Pod 隊列中的下一個Pod，重新進行Step2；不為空，進行下一步。

Step3：將Step2 中得到的候選工作節(jié)點隊列按照負載評價度量值

R

將候選工作節(jié)點從小到大排成隊列。Step4：選取Step3 中負載評價度量值

R

最小的工作節(jié)點作為目標節(jié)點，并且更新該目標工作節(jié)點的資源狀況。選取待遷移Pod 隊列中的下一個Pod，重新進行Step2。

3 實驗設計與結果分析

3.1 實驗環(huán)境與實驗設計

3.1.1 實驗環(huán)境

為了驗證動態(tài)調(diào)度資源的有效性和可行性，搭建了一個Kubernetes集群，其中K8s使用1.16版本，Docker使用18.09.06版本。實驗在4臺不同規(guī)格系數(shù)的服務器節(jié)點上完成。其中，1臺作為Master 節(jié)點，3臺作為Node 節(jié)點。其每個虛擬機的具體配置如表1 所示。

Table 1 Test virtual machine configuration表1 測試虛擬機配置

Pod 應用選取服務器上常見的JavaWeb 應用，其主要需要的程序為Tomcat 和Mysql 數(shù)據(jù)庫，為有狀態(tài)服務。在Tomcat 上運行Java 程序，并且該程序可以向Mysql 寫入數(shù)據(jù)，并可修改和刪除數(shù)據(jù)，同時可以統(tǒng)計Mysql 中的數(shù)據(jù)。將Tomcat 和Mysql 兩個Docker 放入一個Pod 中，該應用充分利用了服務器的CPU、內(nèi)存、磁盤以及網(wǎng)絡寬帶資源。

3.1.2 實驗設計分析

除Kubernetes 默認采用的資源調(diào)度策略，基于優(yōu)先級的資源調(diào)度也是常見資源調(diào)度策略，將待調(diào)度隊列按照一定優(yōu)先級排序，將優(yōu)先級高的先調(diào)度，優(yōu)先級低的后調(diào)度，其調(diào)度策略可以較好地維持系統(tǒng)負載均衡并提升系統(tǒng)性能。文獻［6］中基于Pod 的重啟策略確定優(yōu)先級的資源動態(tài)調(diào)度策略被廣泛應用，本文在其基礎上進一步增加了基于優(yōu)先級的資源調(diào)度在負載評估和遷移消耗方面的深入調(diào)度策略研究。

為了驗證本文所設計的資源調(diào)度算法的有效性，在集群上分別運行Kubernetes 默認資源調(diào)度，將文獻［6］中基于優(yōu)先級的資源動態(tài)調(diào)度與本文設計的資源動態(tài)調(diào)度進行對比實驗。在集群中每隔5min 為集群發(fā)布20個Pod 應用，共發(fā)布100個Pod。使用JMeter 對Kubernetes 集群中的Pod應用發(fā)送HTTP 請求，請求數(shù)量和請求端口都是隨機生成。每次發(fā)布應用后，記錄集群的負載評價標準差，集群運行4.5min 后再記錄一次負載評價標準差，同時記錄每次資源動態(tài)調(diào)度時的Pod 遷移數(shù)量。

3.2 性能指標分析

通常衡量資源動態(tài)調(diào)度性能，主要從負載均衡度和資源消耗兩方面考慮。本文通過負載評價標準差和Pod 遷移數(shù)量對其進行評價。

（1）負載評價標準差。用Std 標準差衡量集群中所有節(jié)點的負載差異：

其中，

average

為集群的系統(tǒng)平均分，計算公式如下：

std 用來衡量集群中所有節(jié)點的負載差異，得分標準差越大，各節(jié)點負載差別越大，反之系統(tǒng)更加均衡。

（2）Pod 遷移數(shù)量。本文采取CRIU 技術實現(xiàn)Pod 遷移，在內(nèi)存復制過程中會在源服務器和目標服務器上消耗額外的CPU 資源，還會消耗額外的網(wǎng)絡帶寬，都會影響集群的資源利用率。Pod 遷移數(shù)量越少，集群在資源動態(tài)調(diào)度時所消耗的資源越少。

3.3 實驗結果分析

3 種運行不同資源調(diào)度集群的負載評價標準差變化比較如圖3 所示。默認的資源動態(tài)調(diào)度在3、5、7、9 次記錄時因調(diào)度器集群負載均衡度較好，在第2、4、6、8、10 次采集時，因JMeter 不斷請求，節(jié)點資源狀況發(fā)生變化，負載評價標準差大。本文設計的資源動態(tài)調(diào)度和基于優(yōu)先級的資源動態(tài)調(diào)度在前兩次采集時因Pod 數(shù)量較少，JMeter 的請求可能集中在某個工作節(jié)點上而又未能達到動態(tài)調(diào)度的觸發(fā)閾值，負載評價標準差較大，隨著Pod 數(shù)量的增多，觸發(fā)動態(tài)資源調(diào)度，在之后的時間里集群負載均衡度較好。系統(tǒng)整體負載評價標準差比基于優(yōu)先級的資源動態(tài)調(diào)度低17%，負載均衡度更好，原因是從多維度評估系統(tǒng)負載狀況，在資源動態(tài)調(diào)度時，可以更加精準地實現(xiàn)集群負載均衡。

Fig.3 Comparison of changes in load evaluation standard deviation圖3 負載評價標準差變化比較

在Pod 遷移數(shù)量方面，Kubernetes 默認資源調(diào)度Pod 一旦運行就不會發(fā)生遷移，采用基于優(yōu)先級的資源動態(tài)調(diào)度和本文設計的動態(tài)資源調(diào)度在實驗期間觸發(fā)了4 次Pod 遷移，其Pod 遷移數(shù)量如圖4 所示?？梢钥闯觯疚脑O計的動態(tài)資源調(diào)度遷移Pod 數(shù)量相對于優(yōu)先級資源動態(tài)調(diào)度平均減少88.3%，降低了系統(tǒng)資源調(diào)度時的消耗。由于本文采用滑動窗口根據(jù)Pod 的負載狀況篩選遷移Pod 集合，在能夠?qū)崿F(xiàn)集群負載均衡的條件下控制Pod 遷移數(shù)量。

Fig.4 Comparison of changes in the number of Pod migrations圖4 Pod 遷移數(shù)量變化比較

4 結語

本文在Kubernetes 集群系統(tǒng)上設計了基于Pod 遷移的資源動態(tài)調(diào)度，實現(xiàn)集群負載均衡。通過監(jiān)控模塊采集各工作節(jié)點和Pod 應用的資源信息，使用層次分析法將其轉(zhuǎn)化為比較客觀、準確的綜合評價結果，在高負載隊列中使用滑動窗口篩選出Pod 遷移集合，達到遷移少量Pod 實現(xiàn)資源動態(tài)調(diào)動的目的。從實驗結果可以看出，本文的動態(tài)資源調(diào)度算法相比與Kubernetes 的默認調(diào)度算法更能維護集群的穩(wěn)定性，相比于基于優(yōu)先級的資源動態(tài)調(diào)度所消耗的系統(tǒng)資源更少?？紤]到集群上可能運行不同類型的Pod應用，本文將在現(xiàn)有研究基礎上，進一步結合資源類型進行深入研究。