Kubernetes 的資源動態調度設計研究

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

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

0 引言

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

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

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

1 資源動態調度機制設計

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

Fig.1 Dynamic resource scheduling mechanism based on Kubernetes圖1 基于Kubernetes 動態資源調度機制

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

2 資源動態調度算法設計

2.1 負載評估

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

其中，

a

表示負載因子，

a

表示CPU 利用率，

a

表示內存利用率，

a

表示帶寬利用率，

a

表示磁盤利用率。

a

表示

a

對

a

的相對重要程度，通常采用1、3、5、7、9 及其倒數，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

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

A

，對

a

加以調整。本文將判斷矩陣構造如下：

根據上述公式可得其相對權重向量

W

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

λ

=4.0019，從而得到

CI

和

RI

。

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

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

a

,

a

,

a

,

a

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

R

如下：

其中，

R

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

R

的最大值是100。

2.2 應用遷移

當某一工作節點的負載評價度量值

R

大于觸發閾值，說明該工作節點的資源使用將達到臨界狀態，其觸發閾值的公式如下：

其中，

R

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

i

∈{1,2,…,

i

,…,

n

}，

α

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

具體算法流程描述如下：

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

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

T

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

T

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

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

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

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

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

2.2.1 遷移Pod 選取

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

R

。當選取的Pod 的

R

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

R

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

輸入：觸發遷移Pod 工作節點上的Pod 集合

輸出：待遷移的Pod 集合

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

R

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

i

、

j

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

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

初始化兩個指針

p

、

q

分別存放符合條件的

i

、

j

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

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

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

Step3：當指 針

i

指 向的Pod 和指 針

j

指向的Pod 為同一個Pod 或者

i＜j

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

j

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

i

、

j

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

p

、

q

指針指向當前

i

、

j

指針。指針

j

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

i

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

p

、

q

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

2.2.2 目標工作節點選取

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

目標工作節點選取算法如下：

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

輸出：目標工作節點

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

R

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

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

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

R

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

R

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

3 實驗設計與結果分析

3.1 實驗環境與實驗設計

3.1.1 實驗環境

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

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

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

3.1.2 實驗設計分析

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

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

3.2 性能指標分析

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

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

其中，

average

為集群的系統平均分，計算公式如下：

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

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

3.3 實驗結果分析

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

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

在Pod 遷移數量方面，Kubernetes 默認資源調度Pod 一旦運行就不會發生遷移，采用基于優先級的資源動態調度和本文設計的動態資源調度在實驗期間觸發了4 次Pod 遷移，其Pod 遷移數量如圖4 所示。可以看出，本文設計的動態資源調度遷移Pod 數量相對于優先級資源動態調度平均減少88.3%，降低了系統資源調度時的消耗。由于本文采用滑動窗口根據Pod 的負載狀況篩選遷移Pod 集合，在能夠實現集群負載均衡的條件下控制Pod 遷移數量。

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

4 結語

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