黃志成

關(guān)鍵詞： Kubernetes; 資源調(diào)度; 負(fù)載均衡; 容器技術(shù); 資源監(jiān)控

當(dāng)前Kubernetes調(diào)度策略是一個比較熱門的研究方向，我們的應(yīng)用向Kubernetes請求資源之后，Kuber?netes會進行容器調(diào)度，現(xiàn)有的Kubernetes調(diào)度器是根據(jù)用戶請求的資源去分配節(jié)點的，沒有考慮到用戶可能申請了很多資源但是實際使用資源很少的情況，這時Kubernetes不會去做資源的重新分配，會造成很大的資源浪費[1]。另外調(diào)度器在選擇節(jié)點的時候是根據(jù)用戶請求的CPU和內(nèi)存數(shù)量去分配節(jié)點的，沒有考慮節(jié)點自身的負(fù)載情況，將Pod調(diào)度到本身已經(jīng)高負(fù)載的節(jié)點上會造成集群中某些節(jié)點資源利用率很高，出現(xiàn)性能不穩(wěn)定的情況[2]。針對Kubernetes默認(rèn)調(diào)度器的不足，對其進行優(yōu)化是本文的研究方向。

1 相關(guān)工作

國內(nèi)外學(xué)者對于資源調(diào)度也有非常多的研究，Menouer等人[3]提出了一種新的Kubernetes容器調(diào)度策略，簡稱為KCSS。這個策略考慮了六個關(guān)鍵因素，分別是每個節(jié)點CPU利用率、每個節(jié)點的內(nèi)存利用率、每個節(jié)點的磁盤利用率、每個節(jié)點的功耗、每個節(jié)點中運行的容器數(shù)以及用戶傳輸鏡像到容器的時間。然后通過TOPSIS 算法選擇排名最高的節(jié)點來運行Pod。Mao等人[4]提出了一種推測性容器調(diào)度器，通過將速度緩慢節(jié)點上的資源遷移到其它節(jié)點上來提升系統(tǒng)性能，主要包含以下三個步驟，確定速度緩慢的節(jié)點、選擇合適的新節(jié)點、遷移重新平衡節(jié)點。浙江大學(xué)的楊鵬飛[5]基于ARIMA和神經(jīng)網(wǎng)絡(luò)兩種模型組合的方案，提出一種資源動態(tài)調(diào)度算法，每一輪調(diào)度都由一個動態(tài)資源管理器去計算所有的節(jié)點實例，然后根據(jù)用戶的資源請求數(shù)量去分配一個節(jié)點。該方法沒有考慮集群節(jié)點本身的負(fù)載情況，每一輪調(diào)度都要遍歷所有節(jié)點去計算資源情況，時間復(fù)雜度過大。華南理工大學(xué)的魏飴[6]提出一種基于節(jié)點CPU和磁盤I/O 均衡的動態(tài)調(diào)度算法，該方法通過監(jiān)控節(jié)點的CPU和磁盤IO使用情況為節(jié)點進行打分，能夠解決默認(rèn)調(diào)度器只考慮用戶請求的CPU和資源情況。但是該方法沒有考慮內(nèi)存影響的因素，并且使用Sched?uler Extender實現(xiàn)的調(diào)度方法會有性能問題。電子科技大學(xué)的唐瑞[7]提出了一種基于Pod優(yōu)先級的搶占策略，在集群資源不足的情況下，選擇將一部分低優(yōu)先級的Pod資源回收。但是該特性在v1.14版本的Ku?bernetes中就已經(jīng)支持了。

2 基于集群負(fù)載均衡的Kubernetes資源調(diào)度算法

2.1 資源監(jiān)控設(shè)計

為了改進Kubernetes的默認(rèn)資源調(diào)度算法，本文需要額外采集CPU、內(nèi)存和磁盤的歷史負(fù)載情況，用于調(diào)度策略的優(yōu)化，本文采用Node-exporter + Pro?metheus + Grafana的技術(shù)對指標(biāo)進行采集、存儲與展示。如圖1 所示，主要實現(xiàn)兩個組件，分別是Pro?metheus 和Scheduler Job。在Prometheus 中實現(xiàn)一個自定義指標(biāo)采集策略，對歷史負(fù)載情況進行采集和存儲。具體實現(xiàn)方式為在配置規(guī)則文件中編寫采集指標(biāo)的PromQL語句，然后通過Node-exporter 定期采集期望獲得的數(shù)據(jù)并進行存儲。在Scheduler Job中周期性地拉取各個節(jié)點的負(fù)載數(shù)據(jù)，計算其歷史負(fù)載情況，并以注解的方式標(biāo)注在節(jié)點上。在后續(xù)的資源調(diào)度算法需要獲取節(jié)點自定義負(fù)載數(shù)據(jù)時，調(diào)度器無需請求Metrics Server API，只需要直接查詢節(jié)點上的注解信息，就能獲取到節(jié)點最近的負(fù)載情況，這樣可以減少HTTP請求所花費的時間，極大提高調(diào)度器的調(diào)度性能。

2.2 資源模型

本文提出一種基于集群節(jié)點負(fù)載均衡的調(diào)度方法，通過監(jiān)控節(jié)點近期CPU、內(nèi)存、磁盤的情況，周期性的將這些指標(biāo)以注解的方式標(biāo)注在節(jié)點中，在調(diào)度器的預(yù)選和優(yōu)選階段根據(jù)監(jiān)控到的指標(biāo)數(shù)據(jù)對節(jié)點進行過濾和打分。本方法主要關(guān)注以下指標(biāo)：1） CPU最近5分鐘的平均利用率。2） CPU最近1小時的最大利用率。3） 內(nèi)存最近5分鐘的平均利用率。4） 內(nèi)存最近1小時的最大利用率。5） 磁盤最近5分鐘的平均利用率。6） 磁盤最近1小時的最大利用率。

2.3 調(diào)度算法

本文通過Scheduler Framework 實現(xiàn)一個自定義的調(diào)度器，在Filter 和Score 這兩個擴展點進行擴展實現(xiàn)，同時保持其余擴展點的Kubernetes 默認(rèn)策略不變。

在調(diào)度的Filter 階段，從候選節(jié)點的注解中讀取歷史負(fù)載數(shù)據(jù)，并根據(jù)這些數(shù)據(jù)對負(fù)載較高的節(jié)點進行過濾。如圖2所示，步驟如下：

1） 判斷需要調(diào)度的Pod類型，如果是Daemonset類型，說明所有的節(jié)點都需要運行這個Pod，不過濾該節(jié)點，直接結(jié)束流程。如果不是Daemonset類型，將繼續(xù)進行第2步。

2） 遍歷該節(jié)點上的所有注解。每一個注解都代表一項自定義指標(biāo)數(shù)據(jù)。

3） 對于每個注解，將其與配置文件中初始定義的閾值進行比較。只要有一項指標(biāo)的實際利用率超過其對應(yīng)的閾值，那么這個節(jié)點將被過濾，代表該Pod無法調(diào)度到該節(jié)點上，結(jié)束流程。如果所有指標(biāo)的實際利用率都小于或等于設(shè)定的閾值，那么這個節(jié)點在預(yù)選階段篩選通過，不過濾該節(jié)點，結(jié)束流程。

在調(diào)度的Score階段，基于節(jié)點注解上的指標(biāo)數(shù)據(jù)進行打分，最終得分是這些指標(biāo)值的加權(quán)和。如圖3所示，步驟如下：

1） 遍歷節(jié)點上的注解，得到歷史負(fù)載指標(biāo)數(shù)據(jù)。

2） 計算節(jié)點的加權(quán)得分。假設(shè)節(jié)點中的資源負(fù)載指標(biāo)集合為Usage = {U1，U2，U3， ... ，Un }，資源負(fù)載指標(biāo)對應(yīng)的權(quán)重集合為Weight = {W1，W2，W3， ... ，Wn }。根據(jù)式（1）計算節(jié)點的分?jǐn)?shù)。

3） 每一個節(jié)點計算完成之后，最終得分返回給調(diào)度器，由調(diào)度器挑選得分最高的節(jié)點部署Pod。

3 實驗分析

3.1 實驗設(shè)計

本實驗在4臺安裝了Centos7.9的虛擬機上部署Kubernetes集群，其中Master節(jié)點1臺，Node節(jié)點3臺，其中Master節(jié)點和兩個Node節(jié)點CPU為2核，內(nèi)存為2G，另一個Node節(jié)點CPU為4核，內(nèi)存為4G，安裝的Kubernetes版本號為v1.23.10。

本次實驗分為兩組，分別為實驗組與對照組，實驗組使用本文實現(xiàn)的調(diào)度器，對照組使用Kubernetes默認(rèn)的調(diào)度器，各種指標(biāo)的采集頻率、閾值與權(quán)重如表1所示。

整體實驗分為以下幾個步驟：

1） 先使用Kubernetes默認(rèn)調(diào)度器，使用kubectl客戶端向Master節(jié)點的API Server發(fā)起創(chuàng)建Pod的命令，每次創(chuàng)建10個Pod，每隔6小時創(chuàng)建一次，一共創(chuàng)建50個Pod。

2） 記錄各節(jié)點資源使用情況，在初始時記錄一次，然后在每次創(chuàng)建完P(guān)od后30分鐘記錄一次，頻率也為6小時一次。

3） 所有Pod創(chuàng)建完成之后，計算集群的負(fù)載均衡度stdScore，計算公式如式（2） ～式（4），Scorei 代表第i個節(jié)點的得分，Ucpu 代表當(dāng)前節(jié)點的CPU利用率，Umem代表當(dāng)前節(jié)點的內(nèi)存利用率，Udisk 代表當(dāng)前節(jié)點的磁盤利用率。Wcpu、Wmem、Wdisk 分別為各指標(biāo)的權(quán)重，本實驗設(shè)置為50、40、10。

3.2 實驗結(jié)果與分析

整體實驗過程中Pod分布情況如表2所示，從測試結(jié)果可以看出，在剛開始的時候，兩次實驗每個節(jié)點上分布的Pod數(shù)量基本一致，由于剛開始每個節(jié)點的負(fù)載都較小，調(diào)度器會平均分配Pod對象。在實驗中后期，實驗組會傾向于把Pod分配給node3節(jié)點，因為此節(jié)點的CPU和內(nèi)存更大，這樣可以盡可能的保證集群之間的負(fù)載均衡。相比之下，默認(rèn)的調(diào)度算法只考慮了節(jié)點當(dāng)前的CPU和內(nèi)存的利用率情況，沒有考慮歷史的負(fù)載情況以及磁盤利用率情況。

各個階段Pod部署完成之后集群的負(fù)載均衡度如圖4所示，可以看出實驗組的負(fù)載均衡度要低于對照組的負(fù)載均衡度，因此使用本文所提出的資源調(diào)度方法后，Kubernetes集群整體的負(fù)載情況要優(yōu)于使用默認(rèn)的調(diào)度方法。

4 結(jié)束語

本文設(shè)計了一種資源監(jiān)控的架構(gòu)，該架構(gòu)借助開源框架Prometheus將集群中節(jié)點的負(fù)載情況記錄下來。并提出了一種基于集群負(fù)載均衡的資源調(diào)度方法，該方法考慮節(jié)點自身的負(fù)載情況，并使用最新的Scheduler Framework技術(shù)實現(xiàn)了該方法，從而實現(xiàn)集群之間的負(fù)載均衡。最后搭建實驗環(huán)境，設(shè)計實驗步驟并進行實驗，對本文提出的資源調(diào)度方法與Kuber?netes默認(rèn)資源調(diào)度進行了對比和分析，通過分析可以得出本文所提出的基于集群負(fù)載均衡的資源調(diào)度方法相比默認(rèn)調(diào)度方法更有優(yōu)勢。但是本文的資源調(diào)度算法只考慮了CPU、內(nèi)存、磁盤的利用率情況，后續(xù)還可以考慮網(wǎng)絡(luò)I/O、磁盤I/O的影響。另外由于成本問題，本文的測試集群只有四臺主機，測試用例也比較有限，在條件允許的情況下，后期可將資源調(diào)度算法在大規(guī)模集群上進行測試。