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

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

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

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

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

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

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

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

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

1.1. 擴展性受限

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

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

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

1.3. 整體資源利用率低下

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

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

2. 方案介紹

2.1. 整體方案架構

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

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

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

該架構主要是由以下幾個核心組件完成：

AutoScaler：核心模塊，負責集群節(jié)點及Pod信息檢查，調(diào)用擴縮容功能。

Estimator：負責評估worker節(jié)點擴容需求，進行Pod預調(diào)度。

Simulator：負責評估worker節(jié)點縮容需求，模擬節(jié)點縮容。

Yusur Cloud Provider：負責將裸金屬資源注冊到為供Cluster AutoScaler擴縮容使用的NodeGroup。管理裸金屬實例的創(chuàng)建和刪除，并將裸金屬實例加入或移出 Kubernetes集群。

2.2. 方案詳細描述

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

2.2.1. AutoScaler

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

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

2.2.2. ScaleUp

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

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

當集群中有多個 Node Group可供選擇時，可以通過expander選項配置選擇 Node Group的策略，支持如下三種方式：

random：隨機選擇；

most-pods：選擇容量最大（可以創(chuàng)建最多 Pod）的 Node Group；

least-waste：以最小浪費原則選擇，即選擇有最少可用資源的 Node Group。

2.2.3. ScaleDown

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

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

節(jié)點上有pod被PodDisruptionBudget（PDB）控制器限制，PDB是k8s中的一種資源，它為 Pod提供了一種保護機制；

節(jié)點上有命名空間是kube-system的pods；

節(jié)點上的pod不是被控制器創(chuàng)建，例如不是被deployment, replicaset, job, statefulset創(chuàng)建；

Pod使用了本地存儲；

節(jié)點上pod驅(qū)逐后無處可去，即沒有其他worker節(jié)點能調(diào)度這個pod；

節(jié)點有注解：”cluster-autoscaler.kubernetes.io/scale-down-disabled“:“true”，可以通過給節(jié)點打上特定注解保證節(jié)點不被Cluster AutoScaler刪除；

配置 `cluster-autoscaler.kubernetes.io/safe-to-evict=false注解，可以確保 pod不被驅(qū)逐，pod所在 worker節(jié)點不被縮減。

2.2.4 Yusur Cloud Provider

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

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

擴容與縮容操作中，裸金屬實例的生命周期由BareMetalManager控制。

3. 方案優(yōu)勢

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

3.1. 增強業(yè)務可擴展性與彈性

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

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

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

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

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

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

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

審核編輯 黃宇