基于DPU的云原生計(jì)算資源共池管理解決方案

1. 方案背景和挑戰(zhàn)

在傳統(tǒng)的云環(huán)境中，通常存在著不同的技術(shù)棧，支撐多樣化的計(jì)算服務(wù)，具體如下：

① OpenStack環(huán)境與虛擬化云主機(jī)及裸金屬服務(wù)

OpenStack是一個(gè)開源的云計(jì)算管理平臺(tái)項(xiàng)目，它提供了部署和管理大規(guī)模計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施的一整套軟件堆棧。在OpenStack技術(shù)棧中，Nova服務(wù)主要負(fù)責(zé)管理虛擬化云主機(jī)，而Ironic服務(wù)則專注于裸金屬資源的管理。

② Kubernetes環(huán)境與容器服務(wù)

Kubernetes（簡(jiǎn)稱K8s）是廣受歡迎的容器管理平臺(tái)，是行業(yè)內(nèi)的事實(shí)標(biāo)準(zhǔn)，主要用于自動(dòng)化容器應(yīng)用的部署、擴(kuò)展和管理。Kubernetes技術(shù)棧圍繞容器化應(yīng)用構(gòu)建，通過其核心組件如kubelet、kube-apiserver、scheduler等，實(shí)現(xiàn)了容器資源的高效調(diào)度與管理。

虛擬化云主機(jī)、裸金屬、容器這三種計(jì)算服務(wù)及其對(duì)應(yīng)的資源池通常獨(dú)立運(yùn)行和管理，各自遵循不同的管理和調(diào)度規(guī)則。

這種分池管理的方式雖然在一定程度上保證了資源的專屬性和安全性，但也構(gòu)成了一個(gè)明顯的瓶頸，嚴(yán)重制約了資源的靈活性、擴(kuò)展性和整體利用率，對(duì)運(yùn)營(yíng)效率和成本控制帶來了多重挑戰(zhàn)。以下是對(duì)這一問題的深入剖析：

1.1. 擴(kuò)展性受限

在分池管理的框架下，業(yè)務(wù)的可擴(kuò)展性受到了嚴(yán)重制約。首先，由于資源池的容量是固定的，當(dāng)某一資源池的資源即將耗盡時(shí)，即便其他類型的資源池中尚有大量閑置資源，也無法實(shí)現(xiàn)快速調(diào)配。其次，資源池的擴(kuò)容往往需要人工介入，包括資源的重新規(guī)劃、配置、測(cè)試等一系列繁瑣流程，不僅耗時(shí)費(fèi)力，還可能因?yàn)轭A(yù)判失誤導(dǎo)致資源閑置或供給不足，從而影響業(yè)務(wù)的連續(xù)性和服務(wù)質(zhì)量。這種擴(kuò)展性差的問題，使得企業(yè)在面對(duì)市場(chǎng)變化和業(yè)務(wù)增長(zhǎng)時(shí)，難以做到敏捷響應(yīng)和快速擴(kuò)張，進(jìn)而錯(cuò)失商機(jī)。

1.2. 資源分配僵化與切換困難

資源池之間的獨(dú)立管理進(jìn)一步加劇了資源分配的僵化，使得在不同資源池之間進(jìn)行資源切換或重新分配變得異常困難。例如，在虛擬機(jī)資源池接近滿負(fù)荷運(yùn)行的同時(shí)，裸金屬資源池可能仍存在大量未充分利用的節(jié)點(diǎn)，但由于缺乏有效的資源池間通信和資源共享機(jī)制，這些裸金屬節(jié)點(diǎn)無法被快速轉(zhuǎn)換為虛擬機(jī)資源，以緩解虛擬機(jī)資源池的壓力。這種資源分配的不靈活性不僅限制了系統(tǒng)的彈性伸縮能力，還導(dǎo)致了資源的冗余和浪費(fèi)。

1.3. 整體資源利用率低下

資源池的獨(dú)立管理導(dǎo)致了資源利用率的顯著下降。由于各資源池之間的資源無法實(shí)現(xiàn)共享，即便某些資源池存在資源過剩的情況，也無法有效支援資源緊張的池子，從而造成了資源分配的不平衡。例如，容器資源池中創(chuàng)建的節(jié)點(diǎn)可能只承載了少量的容器應(yīng)用，而與此同時(shí)，虛擬機(jī)資源池卻可能面臨嚴(yán)重的資源擠兌現(xiàn)象，導(dǎo)致新虛擬機(jī)的創(chuàng)建受阻。這種資源孤島現(xiàn)象不僅降低了整體資源的使用效率，還可能引發(fā)一系列連鎖反應(yīng)，如服務(wù)延遲、性能下降和客戶滿意度降低等問題。

綜上所述，傳統(tǒng)云環(huán)境中資源池的獨(dú)立管理方式暴露出了一系列問題，包括擴(kuò)展性差、資源分配不靈活和資源利用率低等，這些問題共同構(gòu)成了云計(jì)算資源管理的一大難題。為了解決這一挑戰(zhàn)，業(yè)界正在積極探索和實(shí)踐資源池融合、自動(dòng)化資源調(diào)度和智能資源配置等創(chuàng)新技術(shù)，以期實(shí)現(xiàn)資源的高效利用和靈活調(diào)度，推動(dòng)云計(jì)算基礎(chǔ)設(shè)施向著更加智能、彈性和經(jīng)濟(jì)的方向發(fā)展。

2. 方案介紹

2.1. 整體方案架構(gòu)

為了解決上述問題，我們提出了基于DPU的云原生計(jì)算資源共池管理解決方案，結(jié)合了DPU的硬件優(yōu)勢(shì)與Kubernetes的能力和插件生態(tài)，在Kubernetes架構(gòu)下實(shí)現(xiàn)了虛擬機(jī)、裸金屬和容器資源的無縫整合與統(tǒng)一管理，可以實(shí)現(xiàn)當(dāng)某一類資源池（如虛擬機(jī)資源池）面臨資源緊張時(shí)，系統(tǒng)能夠自動(dòng)從共享資源池中調(diào)用資源，實(shí)現(xiàn)Worker節(jié)點(diǎn)的快速擴(kuò)容，而當(dāng)資源需求下降時(shí)，又能夠智能縮容，將多余Worker節(jié)點(diǎn)回收至共享池中，確保資源的按需分配與適時(shí)釋放。

本方案中包括了BareMetalManager，這是基于DPU的裸金屬管理軟件包，由bm-controller、bm-api、bm-handler三個(gè)組件組成。它負(fù)責(zé)管理裸金屬機(jī)器的生命周期，實(shí)現(xiàn)裸金屬服務(wù)器的無盤啟動(dòng)、云盤的動(dòng)態(tài)熱插拔以及網(wǎng)卡動(dòng)態(tài)熱插拔。BareMetalManager?將裸金屬服務(wù)器作為 k8s資源進(jìn)行統(tǒng)一管理，從而提升裸金屬服務(wù)器的管理效率，并為虛擬機(jī)、容器資源池Worker節(jié)點(diǎn)的快速部署提供基礎(chǔ)保障。

本方案的核心部分包括資源池狀態(tài)感知、評(píng)估和調(diào)度，基于Kubernetes Cluster AutoScaler進(jìn)行設(shè)計(jì)，其整體架構(gòu)如下：

該架構(gòu)主要是由以下幾個(gè)核心組件完成：

• AutoScaler：核心模塊，負(fù)責(zé)集群節(jié)點(diǎn)及Pod信息檢查，調(diào)用擴(kuò)縮容功能。
• Estimator：負(fù)責(zé)評(píng)估worker節(jié)點(diǎn)擴(kuò)容需求，進(jìn)行Pod預(yù)調(diào)度。
• Simulator：負(fù)責(zé)評(píng)估worker節(jié)點(diǎn)縮容需求，模擬節(jié)點(diǎn)縮容。
• Yusur Cloud Provider：負(fù)責(zé)將裸金屬資源注冊(cè)到為供Cluster AutoScaler擴(kuò)縮容使用的NodeGroup。管理裸金屬實(shí)例的創(chuàng)建和刪除，并將裸金屬實(shí)例加入或移出 Kubernetes?集群。

2.2. 方案詳細(xì)描述

本節(jié)主要對(duì)云原生計(jì)算資源共池管理方案的核心部分，即Cluster AutoScaler模塊、擴(kuò)縮容邏輯以及cloud provider進(jìn)行介紹。

2.2.1. AutoScaler

AutoScaler啟動(dòng)后觸發(fā)循環(huán)控制邏輯。每10s執(zhí)行一次，檢測(cè)集群狀態(tài)，決定是否執(zhí)行擴(kuò)容或縮容操作。整體流程圖如下：

從流程圖中可以看到，AutoScaler關(guān)鍵邏輯為發(fā)現(xiàn)node，pod以及cloud provider信息。經(jīng)過幾個(gè)模塊處理，將因資源不足導(dǎo)致未調(diào)度的pod緩存起來。然后進(jìn)行下一步判斷，是否需要調(diào)用ScaleUp或者ScaleDown進(jìn)行擴(kuò)縮容控制。

2.2.2. ScaleUp

ScaleUp是AutoScaler評(píng)估后需要執(zhí)行擴(kuò)容操作后調(diào)用的模塊，其流程圖如下：

從流程圖中可以看到，當(dāng)AutoScaler檢測(cè)到需要進(jìn)行擴(kuò)容操作后，ScaleUp還是會(huì)進(jìn)行一些基礎(chǔ)檢查，如當(dāng)前計(jì)算節(jié)點(diǎn)數(shù)量是否達(dá)到最大限制、擴(kuò)容后資源是否超限等前置檢查。然后通過調(diào)用Estimator，進(jìn)行Pod預(yù)調(diào)度，進(jìn)行擴(kuò)容決策，最終選出一個(gè)NodeGroup，從該NodeGroup中申請(qǐng)節(jié)點(diǎn)對(duì)k8s集群進(jìn)行擴(kuò)容。

當(dāng)集群中有多個(gè) Node Group?可供選擇時(shí)，可以通過expander選項(xiàng)配置選擇 Node Group?的策略，支持如下三種方式：

• random：隨機(jī)選擇；
• most-pods：選擇容量最大（可以創(chuàng)建最多 Pod）的 Node Group；
• least-waste：以最小浪費(fèi)原則選擇，即選擇有最少可用資源的 Node Group。

2.2.3. ScaleDown

ScaleDown是AutoScaler評(píng)估后需要執(zhí)行縮容操作后調(diào)用的模塊，其流程圖如下：

從流程圖中可以看出，縮容也會(huì)進(jìn)行前置檢查。縮容過程中最重要的是檢查需要驅(qū)逐pod再移除相應(yīng)節(jié)點(diǎn)的流程。當(dāng)節(jié)點(diǎn)上需要驅(qū)逐Pod才能回收時(shí)，會(huì)調(diào)用Simulator模擬Pod驅(qū)逐，為被需要驅(qū)逐的Pod尋找可調(diào)度節(jié)點(diǎn)。由于在刪除worker節(jié)點(diǎn)時(shí)會(huì)發(fā)生Pod重新調(diào)度的情況，所以應(yīng)用必須可以容忍重新調(diào)度和短時(shí)的中斷（比如使用多副本的 Deployment），當(dāng)滿足以下條件時(shí)，worker節(jié)點(diǎn)不會(huì)刪除：

• 節(jié)點(diǎn)上有pod被PodDisruptionBudget（PDB）控制器限制，PDB是k8s中的一種資源，它為 Pod?提供了一種保護(hù)機(jī)制；
• 節(jié)點(diǎn)上有命名空間是kube-system的pods；
• 節(jié)點(diǎn)上的pod不是被控制器創(chuàng)建，例如不是被deployment, replicaset, job, statefulset創(chuàng)建；
• Pod?使用了本地存儲(chǔ)；
• 節(jié)點(diǎn)上pod驅(qū)逐后無處可去，即沒有其他worker節(jié)點(diǎn)能調(diào)度這個(gè)pod；
• 節(jié)點(diǎn)有注解：”cluster-autoscaler.kubernetes.io/scale-down-disabled“:“true”，可以通過給節(jié)點(diǎn)打上特定注解保證節(jié)點(diǎn)不被Cluster AutoScaler刪除；
• 配置 `cluster-autoscaler.kubernetes.io/safe-to-evict=false?注解，可以確保 pod不被驅(qū)逐，pod所在 worker節(jié)點(diǎn)不被縮減。

2.2.4 Yusur Cloud Provider

yusurCloudProvider會(huì)在Cluster AutoScaler初始化的過程中進(jìn)行注冊(cè)NodeGroup信息，在執(zhí)行ScaleUp和ScaleDown后得到實(shí)際的調(diào)用。其具體流程如下：

其中將裸金屬資源添加到集群共享資源池（NodeGroup），可以根據(jù)指定規(guī)則（如機(jī)型、CPU?等）將其劃分為多個(gè)組。每個(gè) NodeGroup?需要包含當(dāng)前組中機(jī)器的詳細(xì)配置，用于擴(kuò)容過程中的模擬調(diào)度。

擴(kuò)容與縮容操作中，裸金屬實(shí)例的生命周期由BareMetalManager控制。

3. 方案優(yōu)勢(shì)

本解決方案針對(duì)傳統(tǒng)云環(huán)境中資源池獨(dú)立管理的挑戰(zhàn)，提出了創(chuàng)新的資源共池管理機(jī)制，旨在大幅提升資源的靈活性、效率和利用率，以下是該方案的三大核心優(yōu)勢(shì)：

3.1. 增強(qiáng)業(yè)務(wù)可擴(kuò)展性與彈性

該方案通過構(gòu)建統(tǒng)一的資源池，打破了不同資源類型之間的界限，實(shí)現(xiàn)了資源的動(dòng)態(tài)調(diào)配與共享。當(dāng)某一資源類型（如虛擬機(jī)）面臨資源瓶頸時(shí)，系統(tǒng)能夠自動(dòng)從共享資源池中申請(qǐng)額外資源，快速擴(kuò)容以滿足業(yè)務(wù)需求。反之，在資源空閑時(shí)，又能自動(dòng)縮容，將多余的資源節(jié)點(diǎn)歸還至共享池，避免了資源浪費(fèi)。這種機(jī)制顯著增強(qiáng)了業(yè)務(wù)的可擴(kuò)展性和彈性，使得企業(yè)能夠更加從容地應(yīng)對(duì)業(yè)務(wù)波動(dòng)和突發(fā)流量，提高服務(wù)的連續(xù)性和用戶滿意度。

3.2. 提升資源分配的靈活性與效率

通過資源共池管理，實(shí)現(xiàn)了資源的自動(dòng)化和智能化分配，顯著提升了資源分配的靈活性與效率。不再局限于固定資源池的限制，系統(tǒng)能夠根據(jù)實(shí)時(shí)的資源需求和業(yè)務(wù)負(fù)載，自動(dòng)在共享資源池中尋找最優(yōu)的資源匹配，進(jìn)行即時(shí)的資源調(diào)度。這種動(dòng)態(tài)分配機(jī)制不僅簡(jiǎn)化了資源管理的復(fù)雜度，還極大地提高了資源分配的精準(zhǔn)度和響應(yīng)速度，使得資源能夠更加高效地服務(wù)于業(yè)務(wù)需求，減少人為干預(yù)，提升整體運(yùn)維效率。

3.3. 最大化資源利用率，降低成本

云原生計(jì)算資源共池管理解決方案通過打破資源池之間的壁壘，實(shí)現(xiàn)了資源的全局優(yōu)化與共享，有效解決了資源孤島問題，大幅提高了資源的整體利用率。在傳統(tǒng)模式下，由于資源池的獨(dú)立管理，資源分配往往呈現(xiàn)出不均衡狀態(tài)，導(dǎo)致部分資源長(zhǎng)期閑置。而共池管理方案能夠根據(jù)實(shí)際需求動(dòng)態(tài)調(diào)整資源分配，避免了資源的冗余和浪費(fèi)，從而顯著降低了企業(yè)的運(yùn)營(yíng)成本。此外，通過智能的資源調(diào)度算法，該方案還能進(jìn)一步挖掘資源潛力，提升資源使用效率，為企業(yè)帶來更大的經(jīng)濟(jì)效益。

基于DPU的云原生計(jì)算資源共池管理解決方案通過實(shí)現(xiàn)資源的統(tǒng)一管理、動(dòng)態(tài)調(diào)配與智能優(yōu)化，有效解決了傳統(tǒng)云環(huán)境中資源管理的痛點(diǎn)，為構(gòu)建更加靈活、高效和經(jīng)濟(jì)的云基礎(chǔ)設(shè)施提供了有力支撐。

本方案來自于中科馭數(shù)軟件研發(fā)團(tuán)隊(duì)，團(tuán)隊(duì)核心由一群在云計(jì)算、數(shù)據(jù)中心架構(gòu)、高性能計(jì)算領(lǐng)域深耕多年的業(yè)界資深架構(gòu)師和技術(shù)專家組成，不僅擁有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，還對(duì)行業(yè)趨勢(shì)具備敏銳的洞察力，該團(tuán)隊(duì)致力于探索、設(shè)計(jì)、開發(fā)、推廣可落地的高性能云計(jì)算解決方案，幫助最終客戶加速數(shù)字化轉(zhuǎn)型，提升業(yè)務(wù)效能，同時(shí)降低運(yùn)營(yíng)成本。