基于kubernetes的計(jì)算資源的搶占式調(diào)度

向曉婷

(貴陽(yáng)信息科技學(xué)院,貴陽(yáng) 550025)

0 引言

云計(jì)算用戶群體較為龐大,每個(gè)應(yīng)用資源的需求呈現(xiàn)動(dòng)態(tài)變化,要?jiǎng)討B(tài)調(diào)整其性能需求[1]。多種應(yīng)用具有共享資源特點(diǎn),應(yīng)按照需求供給,因此調(diào)度問題成為難點(diǎn),尤其是資源調(diào)度[2]。對(duì)于云數(shù)據(jù)中心來說,合理的資源分配對(duì)于提升系統(tǒng)性能及資源的利用率有著重要的作用。

容器作為物理資源的邏輯抽象,具有資源占用少、資源供給快的特點(diǎn)[3]。Docker是一個(gè)開源的應(yīng)用容器引擎,將應(yīng)用和依賴包打包到一個(gè)可移植的容器中,可便捷發(fā)布到任意一個(gè)主流的Linux機(jī)器上,實(shí)現(xiàn)虛擬化。其具有以下功能:①管理復(fù)雜的軟件開發(fā)環(huán)境。一個(gè)軟件無論是開發(fā)還是發(fā)布,環(huán)境配置問題都很重要,Docker能夠確保軟件從開發(fā)到發(fā)布環(huán)境的一致性。②構(gòu)建效率更高的云平臺(tái)。傳統(tǒng)的KVM虛擬機(jī)運(yùn)行需要整個(gè)操作系統(tǒng),會(huì)浪費(fèi)資源,而Docker直接提供軟件運(yùn)行所需環(huán)境,不提供客戶端操作系統(tǒng),可減少資源浪費(fèi)。③提供便捷的軟件管理。使用Docker可屏蔽操作系統(tǒng)和物理硬件之間的差異性,以Docker鏡像形式分發(fā)出去,確保軟件更加標(biāo)準(zhǔn)化和統(tǒng)一化,便于管理和維護(hù)。

云計(jì)算環(huán)境下的彈性調(diào)度是根據(jù)用戶需求自動(dòng)對(duì)計(jì)算資源實(shí)例進(jìn)行相應(yīng)的調(diào)整,需要自動(dòng)實(shí)現(xiàn)云資源按需使用,而不是人為操作,從而節(jié)約云平臺(tái)運(yùn)維成本。Kaur K[4]等處理了在服務(wù)交易前協(xié)商過程中出現(xiàn)的語(yǔ)義錯(cuò)誤,提出了基于負(fù)載感知和上下文語(yǔ)義的云計(jì)算任務(wù)調(diào)度算法。崔雪嬌[5]等提出一種貪心算法的資源調(diào)度策略,提高了云計(jì)算資源調(diào)度的任務(wù)完成效率和資源利用率。

目前的研究大多針對(duì)虛擬機(jī)放置問題采用不同方法進(jìn)行驗(yàn)證。容器相對(duì)于虛擬機(jī)來說有著明顯的優(yōu)勢(shì),啟停速度更快且更輕量級(jí),但針對(duì)調(diào)度問題卻缺少根據(jù)負(fù)載變化動(dòng)態(tài)進(jìn)行搶占式調(diào)度方面的研究。

1 基于kubernetes調(diào)度問題的描述

在kubernetes中,Pod是資源使用對(duì)象的最小單位。調(diào)度是找出一個(gè)Pod并將其綁定的過程。調(diào)度的輸入需要Pod和被調(diào)度的節(jié)點(diǎn)信息。調(diào)度的輸出是將Pod和Node節(jié)點(diǎn)綁定,根據(jù)調(diào)度算法選擇Node節(jié)點(diǎn)并將該P(yáng)od綁定到上面。調(diào)度類似于黑盒子,把等待調(diào)度的Pod和部署節(jié)點(diǎn)隊(duì)列輸入,將一個(gè)節(jié)點(diǎn)和某節(jié)點(diǎn)的綁定信息輸出。kubernetes調(diào)度器對(duì)Pod調(diào)度后,Pod就會(huì)和一個(gè)特定的節(jié)點(diǎn)綁定,當(dāng)有多種kubernetes資源使用對(duì)象時(shí),kubernetes中的controller manager組件會(huì)把這些資源數(shù)量分解為合適數(shù)量的Pod,并讓API Server將Pod放到PodQueue的等待隊(duì)列中去。PodQueue是一個(gè)先進(jìn)先出隊(duì)列(FIFO),調(diào)度器每次從調(diào)度隊(duì)列中取出一個(gè)Pod進(jìn)行調(diào)度。調(diào)度器在kubernetes集群中發(fā)揮橋梁作用,把來自controller manager創(chuàng)建的待調(diào)度的Pod放到最適合的Node節(jié)點(diǎn)上運(yùn)行,綁定的指定操作完成后,讓目標(biāo)節(jié)點(diǎn)上的Kubelet繼續(xù)進(jìn)行后續(xù)操作。

kubernetes調(diào)度存在以下問題:①在大規(guī)模集群中處于等待狀態(tài)的容器較多,如果Pod調(diào)度失敗,則會(huì)重新加入到隊(duì)列中進(jìn)行等待,影響容器的調(diào)度速度。②集群資源不足時(shí),這種調(diào)度隊(duì)列沒有搶占式調(diào)度策略,一些急需相應(yīng)資源的應(yīng)用無法調(diào)度成功或是不能提前調(diào)度,只能人工操作釋放資源。

kubernetes采用先進(jìn)先出隊(duì)列,每次只能按順序彈出一個(gè)Pod供調(diào)度器來調(diào)度,但是在實(shí)踐生產(chǎn)環(huán)境中有著不同資源的需求任務(wù)和應(yīng)用程序。例如,圖形圖像處理任務(wù)、實(shí)時(shí)計(jì)算、數(shù)據(jù)庫(kù)存儲(chǔ)服務(wù)、web服務(wù)等,這些應(yīng)用中有的需要GPU幫助,有的對(duì)CPU性能有著較高的需求,還有一些需要較大的內(nèi)存來提高運(yùn)行效率,對(duì)于這種情況,需要把特定的任務(wù)調(diào)度到指定的服務(wù)器上運(yùn)行。還有的用戶對(duì)應(yīng)用A的需求比應(yīng)用B高,此時(shí)則需要為kubernetes設(shè)計(jì)一種搶占式調(diào)度方案。

2 基于Kubernetes的搶占式調(diào)度

搶占式調(diào)度是分布式調(diào)度中較為常見的一種設(shè)計(jì),其應(yīng)用場(chǎng)景是當(dāng)集群中沒有足夠的資源供應(yīng)時(shí),有些任務(wù)又較為緊急,則會(huì)通過搶占低優(yōu)先級(jí)的任務(wù)來完成調(diào)度?；趉ubernetes的搶占式調(diào)度是給pod設(shè)置高低優(yōu)先級(jí),高優(yōu)先級(jí)的Pod搶占低優(yōu)先級(jí)的Pod資源,從而令高優(yōu)先級(jí)Pod能被調(diào)度。搶占式調(diào)度需遵循以下規(guī)則:①中斷預(yù)算。為了在kubernetes中保證服務(wù)的高可用,需遵守PDB(Pod Disrution Budget)規(guī)則,其核心目標(biāo)是為了保證服務(wù)的可用性,確保對(duì)應(yīng)的Pod維持在特定的數(shù)量。在Pod搶占過程中,盡可能保證不去搶占有pod中斷預(yù)算的資源,防止搶占后導(dǎo)致服務(wù)不可用。②減少高低優(yōu)先級(jí)Pod之間的高度耦合。如果高優(yōu)先級(jí)Pod高度依賴于低優(yōu)先Pod,則會(huì)因?yàn)橐蕾噯栴}造成優(yōu)先級(jí)無效,從而導(dǎo)致無法搶占式調(diào)度。

搶占式調(diào)度的應(yīng)用場(chǎng)景。一個(gè)在調(diào)度隊(duì)列中有多個(gè)待調(diào)度的任務(wù)或進(jìn)程,當(dāng)排在隊(duì)列尾端的任務(wù)需要緊急被處理時(shí),如果按照默認(rèn)的調(diào)度順序,需要等到該任務(wù)前面的所有任務(wù)調(diào)度完之后才能輪到該任務(wù)調(diào)度。在實(shí)踐應(yīng)用場(chǎng)景中,要保證需要被緊急調(diào)度的任務(wù)能夠被提前進(jìn)行,即需要給任務(wù)分配優(yōu)先級(jí),根據(jù)任務(wù)的優(yōu)先級(jí)調(diào)度順序來進(jìn)行調(diào)度,而不是根據(jù)任務(wù)的進(jìn)隊(duì)順序進(jìn)行調(diào)度。

kubernetes默認(rèn)情況下采用的是先進(jìn)先出的調(diào)度方式(FIFO,First Input First Output)。然而在大多數(shù)調(diào)度場(chǎng)景下,需要采用優(yōu)先級(jí)調(diào)度,確保優(yōu)先級(jí)較高的任務(wù)或需求優(yōu)先被滿足,從而減少后續(xù)高優(yōu)先級(jí)對(duì)低優(yōu)先級(jí)Pod的搶占。

在kubernetes集群中,CPU、內(nèi)存等資源是有限的,需要平衡各個(gè)Pod的運(yùn)行情況。在kubernetes集群中,實(shí)時(shí)Pod的優(yōu)先級(jí)比普通Pod優(yōu)先級(jí)高,kubernetes優(yōu)先選擇高優(yōu)先級(jí)Pod進(jìn)入到調(diào)度隊(duì)列,高優(yōu)先級(jí)Pod調(diào)度完成之后,才輪到低優(yōu)先級(jí)Pod調(diào)度。

在kubernetes中,搶占調(diào)度要解決的問題是當(dāng)Pod調(diào)度失敗時(shí)如何處理。正常情況下,一個(gè)Pod調(diào)度失敗后會(huì)被擱置處于待定狀態(tài),只有當(dāng)Pod被更新或集群狀態(tài)發(fā)生變化時(shí)才會(huì)對(duì)該P(yáng)od重新調(diào)度。而kubernetes搶占式調(diào)度是當(dāng)一個(gè)高優(yōu)先級(jí)Pod調(diào)度失敗后,該P(yáng)od會(huì)搶占某個(gè)低優(yōu)先級(jí)Pod,從而保證高優(yōu)先級(jí)Pod能夠調(diào)度成功。

搶占式調(diào)度的流程如下:從等待的隊(duì)列中取出一個(gè)待調(diào)度的Pod進(jìn)行調(diào)度,如果調(diào)度成功,則將該P(yáng)od和所選出來的Node綁定,如果調(diào)度失敗,則進(jìn)入搶占式調(diào)度流程。在搶占式調(diào)度流程中,分析該P(yáng)od的優(yōu)先級(jí)信息,篩選出可以進(jìn)行搶占調(diào)度的Node節(jié)點(diǎn),需保證被搶占Pod的數(shù)量盡可能少且對(duì)其他服務(wù)影響小來進(jìn)行調(diào)度。取代被搶占的低優(yōu)先級(jí)Pod,并將高優(yōu)先級(jí)的Pod綁定到指定的Node節(jié)點(diǎn)上。

3 實(shí)驗(yàn)驗(yàn)證

3.1 實(shí)驗(yàn)環(huán)境

搭建kubernetes集群,采用4臺(tái)安裝有CentOS 7.6的服務(wù)器進(jìn)行集群部署。使用4臺(tái)主機(jī)、3臺(tái)Master節(jié)點(diǎn)、3臺(tái)Node節(jié)點(diǎn),其中兩個(gè)主機(jī)既是Master節(jié)點(diǎn)也是Node節(jié)點(diǎn)。集群IP和主機(jī)名如表1所示。

表1 集群主機(jī)名和IPTab.1 Cluster host name and IP

集群軟件信息如表2所示。

表2 軟件環(huán)境信息Tab.2 Software environment information

Kubernetes集群部署采用主從式架構(gòu),即Master-Node節(jié)點(diǎn)。Master節(jié)點(diǎn)上部署的Kubernetes組件有kube-apiserver、kube-scheduler、kube-controller-manager,網(wǎng)絡(luò)組件為flannel。為了使集群不會(huì)因?yàn)閱蝹€(gè)存儲(chǔ)節(jié)點(diǎn)故障而導(dǎo)致整個(gè)集群不可用,需把數(shù)據(jù)存儲(chǔ)Etcd搭建為一個(gè)集群,在其中兩臺(tái)Master部署Haproxy和keepalived,保證集群高可用。Node節(jié)點(diǎn)部署的Kubernetes組件有Kubelet、kube-proxy,容器組件為Docker,網(wǎng)絡(luò)組件為Flannel。Kubernetes集群部署如圖1所示。

圖1 Kubernetes集群部署架構(gòu)Fig.1 Kubernetes cluster deployment architecture

3.2 Pod搶占式調(diào)度實(shí)現(xiàn)

3.2.1 高低優(yōu)先級(jí)Pod搶占調(diào)度

為3個(gè)Node節(jié)點(diǎn)添加相應(yīng)的label,如表3所示。

表3 Node節(jié)點(diǎn)標(biāo)簽Tab.3 Node label

創(chuàng)建兩個(gè)不同優(yōu)先級(jí)的yaml文件。使用node親和性的pod調(diào)度方式,將兩個(gè)pod調(diào)度到master-node 1和master-node 2,而調(diào)度到標(biāo)簽test的值為k8s的節(jié)點(diǎn)上,在node 3上創(chuàng)建的標(biāo)簽test值為k8s,最終調(diào)度到node 3上,內(nèi)存和CPU的需求設(shè)置為64 Mi和1 200 m,超過node3 CPU的一半,基于kubernetes調(diào)度方案搶占式調(diào)度策略,測(cè)試其正確性。為了使實(shí)驗(yàn)測(cè)試更加直觀,對(duì)kubernetes集群中的master_node1節(jié)點(diǎn)進(jìn)行測(cè)試,即對(duì)IP地址為192.168.34.34節(jié)點(diǎn)進(jìn)行測(cè)試。master-node1節(jié)點(diǎn)的資源使用情況如表4所示。

表4 master-node1節(jié)點(diǎn)資源情況Tab.4 Master-node resources

在某一時(shí)刻,kubernetes集群等待隊(duì)列中有2個(gè)Pod,如表5所示。

表5 待調(diào)度Pod信息Tab.5 Information of the Pod to be scheduled

令nginx-high高優(yōu)先級(jí)Pod和nginx-low低優(yōu)先級(jí)同時(shí)生效,如圖2所示。

圖2 高低優(yōu)先級(jí)Pod同時(shí)運(yùn)行Fig.2 High and low priority Pod running simultaneously

由于兩個(gè)不同優(yōu)先級(jí)Pod需要的CPU總量超過node 3的CPU總數(shù),低優(yōu)先級(jí)Pod被迫停止。nginx-high搶占了nginx-low,最終只剩高優(yōu)先級(jí)Pod運(yùn)行,如圖3所示。

圖3 搶占調(diào)度結(jié)果Fig.3 Results of preemption scheduling

3.2.2 多個(gè)低優(yōu)先級(jí)Pod并發(fā)調(diào)度

在某一時(shí)刻集群等待隊(duì)列中有3個(gè)高、低、中優(yōu)先級(jí)Pod。優(yōu)先級(jí)信息、CPU及內(nèi)存資源的限制信息如表6所示。

表6 多個(gè)Pod同時(shí)并發(fā)調(diào)度信息Tab.6 Schedule information concurrently sent by multiple Pods

多個(gè)Pod優(yōu)先級(jí)調(diào)度信息如圖4所示。

圖4 多個(gè)Pod同時(shí)并發(fā)調(diào)度Fig.4 Schedule concurrently sent by multiple Pods

各個(gè)Node工作節(jié)點(diǎn)的CPU、內(nèi)存、網(wǎng)絡(luò)等資源的使用情況如表7所示。

表7 多個(gè)Pod并發(fā)調(diào)度的資源情況Tab.7 Resources of schedule concurrently sent by multiple Pods

集群中有多個(gè)Pod同時(shí)并發(fā)調(diào)度時(shí),Master控制節(jié)點(diǎn)會(huì)根據(jù)各個(gè)Node工作節(jié)點(diǎn)的資源使用情況將Pod調(diào)度到各個(gè)節(jié)點(diǎn)上,令各個(gè)Node節(jié)點(diǎn)都運(yùn)作起來,提高集群資源使用率。如果集群將多個(gè)Pod都調(diào)度到某一節(jié)點(diǎn),會(huì)導(dǎo)致該節(jié)點(diǎn)的資源很快耗盡。

3.2.3 多個(gè)Pod并發(fā)調(diào)度

在多個(gè)Pod并發(fā)調(diào)度前,Node1～Node3節(jié)點(diǎn)上的資源剩余情況如表8所示。

表8 并發(fā)調(diào)度前資源剩余情況Tab.8 Remaining resources before concurrent scheduling

在某一時(shí)刻,集群等待隊(duì)列中有如下Pod的并發(fā)調(diào)度信息,如表9所示。Nginx-Middle-1～Nginx-Middle-3調(diào)度到Node工作節(jié)點(diǎn)的情況如圖5所示。此時(shí),3臺(tái)node節(jié)點(diǎn)資源請(qǐng)求幾乎耗盡。再創(chuàng)建2臺(tái)中低優(yōu)先級(jí)Pod,但未能都調(diào)度到任何節(jié)點(diǎn)上,如圖6所示。這說明Node 3上的CPU、內(nèi)存等計(jì)算資源已經(jīng)快要被耗盡,該工作節(jié)點(diǎn)上的資源已經(jīng)不能夠滿足其他Pod的調(diào)度需要,如果再有調(diào)度,需要調(diào)度到Node 2或Node 3工作節(jié)點(diǎn)上。

圖5 優(yōu)先Pod調(diào)度情況Fig.5 Schedule of medium priority Pod

圖6 Pod并發(fā)調(diào)度最新情況Fig.6 Latest scheduling status of Pod concurrent

表9 多個(gè)Pod并發(fā)調(diào)度的節(jié)點(diǎn)Tab.9 Nodes where multiple Pods are scheduled concurrently

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

Docker虛擬化技術(shù)和kubernetes云平臺(tái)已逐漸投入到了生產(chǎn)實(shí)踐中。介紹了相關(guān)理論和技術(shù),綜述了云資源彈性調(diào)度系統(tǒng)的研究現(xiàn)狀,對(duì)資源調(diào)度器的演進(jìn)、kubernetes容器云平臺(tái)、彈性伸縮理論、云計(jì)算技術(shù)、Docker虛擬化技術(shù)進(jìn)行分析。對(duì)云資源彈性伸縮調(diào)度方案進(jìn)行研究,指出了云資源和kubernetes彈性伸縮的問題,分析了kubernetes的調(diào)度機(jī)制,包括搶占式調(diào)度規(guī)則、Pod優(yōu)先級(jí)的劃分及搶占式調(diào)度流程。采用云計(jì)算技術(shù)和Docker容器虛擬化技術(shù)搭建實(shí)驗(yàn)環(huán)境,部署kubernetes高可用集群,設(shè)計(jì)了基于kubernetes云平臺(tái)的Pod彈性水平自動(dòng)伸縮方案和Pod優(yōu)先級(jí)搶占式調(diào)度方式,對(duì)Pod彈性伸縮和搶占式調(diào)度進(jìn)行實(shí)現(xiàn)。采用黑盒測(cè)試,驗(yàn)證了此設(shè)計(jì)能夠根據(jù)負(fù)載變化達(dá)到彈性伸縮和搶占式調(diào)度的效果。未來,還需進(jìn)一步研究如何更好地掌握Pod退場(chǎng)時(shí)間。當(dāng)?shù)蛢?yōu)先級(jí)的Pod被搶占時(shí),該P(yáng)od上相應(yīng)的工作也相繼停下來,如果能夠保持這部分工作且下次啟動(dòng)時(shí)能夠無縫對(duì)接,將大大提高集群資源的利用率。