基于kubernetes的計算資源的搶占式調度

向曉婷

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

0 引言

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

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

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

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

1 基于kubernetes調度問題的描述

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

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

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

2 基于Kubernetes的搶占式調度

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

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

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

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

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

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

3 實驗驗證

3.1 實驗環境

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

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

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

表2 軟件環境信息Tab.2 Software environment information

Kubernetes集群部署采用主從式架構,即Master-Node節點。Master節點上部署的Kubernetes組件有kube-apiserver、kube-scheduler、kube-controller-manager,網絡組件為flannel。為了使集群不會因為單個存儲節點故障而導致整個集群不可用,需把數據存儲Etcd搭建為一個集群,在其中兩臺Master部署Haproxy和keepalived,保證集群高可用。Node節點部署的Kubernetes組件有Kubelet、kube-proxy,容器組件為Docker,網絡組件為Flannel。Kubernetes集群部署如圖1所示。

圖1 Kubernetes集群部署架構Fig.1 Kubernetes cluster deployment architecture

3.2 Pod搶占式調度實現

3.2.1 高低優先級Pod搶占調度

為3個Node節點添加相應的label,如表3所示。

表3 Node節點標簽Tab.3 Node label

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

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

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

表5 待調度Pod信息Tab.5 Information of the Pod to be scheduled

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

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

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

圖3 搶占調度結果Fig.3 Results of preemption scheduling

3.2.2 多個低優先級Pod并發調度

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

表6 多個Pod同時并發調度信息Tab.6 Schedule information concurrently sent by multiple Pods

多個Pod優先級調度信息如圖4所示。

圖4 多個Pod同時并發調度Fig.4 Schedule concurrently sent by multiple Pods

各個Node工作節點的CPU、內存、網絡等資源的使用情況如表7所示。

表7 多個Pod并發調度的資源情況Tab.7 Resources of schedule concurrently sent by multiple Pods

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

3.2.3 多個Pod并發調度

在多個Pod并發調度前,Node1～Node3節點上的資源剩余情況如表8所示。

表8 并發調度前資源剩余情況Tab.8 Remaining resources before concurrent scheduling

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

圖5 優先Pod調度情況Fig.5 Schedule of medium priority Pod

圖6 Pod并發調度最新情況Fig.6 Latest scheduling status of Pod concurrent

表9 多個Pod并發調度的節點Tab.9 Nodes where multiple Pods are scheduled concurrently

4 結束語

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