向曉婷

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 實驗驗證

3.1 實驗環(huán)境

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

表1 集群主機名和IPTab.1 Cluster host name and IP

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

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

Kubernetes集群部署采用主從式架構(gòu),即Master-Node節(jié)點。Master節(jié)點上部署的Kubernetes組件有kube-apiserver、kube-scheduler、kube-controller-manager,網(wǎng)絡(luò)組件為flannel。為了使集群不會因為單個存儲節(jié)點故障而導(dǎo)致整個集群不可用,需把數(shù)據(jù)存儲Etcd搭建為一個集群,在其中兩臺Master部署Haproxy和keepalived,保證集群高可用。Node節(jié)點部署的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)度實現(xiàn)

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

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

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

創(chuàng)建兩個不同優(yōu)先級的yaml文件。使用node親和性的pod調(diào)度方式,將兩個pod調(diào)度到master-node 1和master-node 2,而調(diào)度到標(biāo)簽test的值為k8s的節(jié)點上,在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)度策略,測試其正確性。為了使實驗測試更加直觀,對kubernetes集群中的master_node1節(jié)點進行測試,即對IP地址為192.168.34.34節(jié)點進行測試。master-node1節(jié)點的資源使用情況如表4所示。

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

在某一時刻,kubernetes集群等待隊列中有2個Pod,如表5所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖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 多個Pod并發(fā)調(diào)度的節(jié)點Tab.9 Nodes where multiple Pods are scheduled concurrently

4 結(jié)束語

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