黃志成

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

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

1 相關(guān)工作

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

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

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

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

2.2 資源模型

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

2.3 調(diào)度算法

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

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

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

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

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

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

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

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

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

3 實(shí)驗(yàn)分析

3.1 實(shí)驗(yàn)設(shè)計(jì)

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

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

整體實(shí)驗(yàn)分為以下幾個(gè)步驟：

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

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

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

3.2 實(shí)驗(yàn)結(jié)果與分析

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

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

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

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