Hello folks，我是 Luga，今天我們來聊一下云原生應用場景 - 基于 Kubernetes DRA 進行 GPU 設備資源高效調度。

在現(xiàn)代云原生架構中，Kubernetes 已經(jīng)成為企業(yè)動態(tài)資源調度的核心技術。隨著業(yè)務需求的復雜性和多樣性日益增加，如何高效地在 Kubernetes 集群中分配和調整資源，成為提升系統(tǒng)彈性和利用率的關鍵課題。

動態(tài)資源調度通過智能化地分配 CPU、內存、GPU 等關鍵資源，不僅能夠滿足不同負載的性能需求，還能降低資源浪費，提高基礎設施的投資回報率。本篇文章將圍繞 Kubernetes 動態(tài)資源調度的核心原理、關鍵技術及最佳實踐展開，從調度框架、擴展機制到實際應用場景，全面解析如何在云原生環(huán)境中實現(xiàn)高效、靈活的資源管理，為讀者提供深刻的技術洞見和實操指導。

如何理解 Kubernetes 中動態(tài)資源?

要理解 Kubernetes 中的“動態(tài)資源”，需要區(qū)分傳統(tǒng)資源管理方式和 Kubernetes 的創(chuàng)新之處。傳統(tǒng)方式通常是靜態(tài)分配資源，而 Kubernetes 引入了多種機制來實現(xiàn)資源的動態(tài)管理，從而更好地適應不斷變化的應用程序需求。

眾所周知，在傳統(tǒng)的虛擬化或裸金屬環(huán)境中，資源分配通常是靜態(tài)的。通常情況下，管理員預先為應用程序分配固定的 CPU、內存、存儲等資源，這些資源在應用程序運行期間保持不變。這種方式存在以下局限性：

• 資源浪費： 如果應用程序的負載波動較大，靜態(tài)分配的資源可能在低峰時閑置，造成浪費。
• 彈性不足： 當應用程序需要更多資源時，靜態(tài)分配無法快速響應，可能導致性能下降甚至服務中斷。
• 管理復雜： 對于大規(guī)模部署和復雜的應用程序，靜態(tài)資源管理變得非常繁瑣。

為了解決上述痛點以及面對不斷新穎的業(yè)務需求場景，動態(tài)資源的概念便應運而生。

其實，圍繞著 Kubernetes 歷史發(fā)展，其已經(jīng)通過多種機制實現(xiàn)了資源的動態(tài)管理，主要包括以下幾個方面：

(1) 資源請求和限制(Requests and Limits)： 在 Pod 規(guī)范中，可以定義容器的資源請求(Requests)和限制(Limits)。Requests 指定容器運行所需的最小資源量，Kubernetes 調度器會根據(jù) Requests 來選擇合適的節(jié)點。Limits 指定容器可以使用的最大資源量，防止容器過度使用資源影響其他應用。雖然 Requests 和 Limits 是靜態(tài)配置的，但它們?yōu)楹罄m(xù)的動態(tài)調整奠定了基礎。

(2) Horizontal Pod Autoscaler (HPA)： HPA 可以根據(jù) CPU 利用率、內存使用率或其他自定義指標自動調整 Pod 的副本數(shù)量。當指標超過預設的閾值時，HPA 會自動增加 Pod 副本，反之則減少。這實現(xiàn)了應用程序的水平彈性伸縮，根據(jù)實際負載動態(tài)調整資源使用。

(3) Vertical Pod Autoscaler (VPA)： VPA 可以自動調整 Pod 中容器的資源請求(Requests)和限制(Limits)。VPA 監(jiān)控容器的資源使用情況，并根據(jù)歷史數(shù)據(jù)和實時負載推薦合適的資源配置。VPA 可以自動更新 Pod 的資源配置，或者提供建議供管理員手動調整。這實現(xiàn)了應用程序的垂直彈性伸縮，根據(jù)實際需求動態(tài)調整單個 Pod 的資源分配。

(4) 動態(tài)卷分配(Dynamic Volume Provisioning)： Kubernetes 允許根據(jù)需要動態(tài)創(chuàng)建和分配持久卷。當 Pod 需要存儲時，可以動態(tài)地創(chuàng)建一個新的持久卷并將其掛載到 Pod 上。這避免了預先創(chuàng)建大量持久卷的麻煩，提高了存儲資源的利用率。

(5) 動態(tài)資源分配(DRA - Dynamic Resource Allocation)： 這是 Kubernetes 較新的一個特性，旨在解決除 CPU、內存和存儲之外的其他類型資源的動態(tài)分配問題，例如 GPU、FPGA 等硬件加速器。DRA 允許應用程序以更精細的方式請求和使用這些特殊資源，并允許資源驅動程序根據(jù)實時需求進行分配和管理。DRA 將持久卷 API 的概念推廣到通用資源的管理，提供了更靈活、更高效的資源分配機制。

本文主要圍繞“動態(tài)資源分配(DRA - Dynamic Resource Allocation)” 進行展開描述。在詳細解析 DRA 之前，我們先了解一下 Device Plugin 概念，那么，什么是 Device Plugin 呢?

Kubernetes 的 Device Plugin 機制(源于 KEP-3573)是一項早期就引入 Kubernetes 的重要功能，旨在擴展 Kubernetes 的資源管理能力，使其能夠支持除 CPU 和內存之外的各種硬件資源，例如圖形處理器(GPU)、數(shù)據(jù)處理單元(DPU)、現(xiàn)場可編程門陣列(FPGA)以及非統(tǒng)一內存訪問(NUMA)節(jié)點等。

Device Plugin 機制通過提供一個簡單而強大的接口——Device Plugin Interface，實現(xiàn)了對這些硬件資源的抽象和管理。通過實現(xiàn)這個接口，第三方供應商或用戶可以開發(fā)自己的 Device Plugin，從而將特定的硬件資源集成到 Kubernetes 集群中。

從某種意義上而言，Device Plugin (設備插件)的引入極大擴展了 Kubernetes 的能力，使其不僅局限于管理傳統(tǒng)的 CPU 和內存資源，還能支持各種類型的特殊硬件資源。這對于依賴硬件加速的任務(如 AI 模型訓練、數(shù)據(jù)科學計算和高性能網(wǎng)絡處理)具有重要意義。通過設備插件，用戶可以更高效地利用集群中的硬件資源，同時通過標準化的接口降低管理和集成的復雜性。

需要注意的是，Kubernetes 在不同版本中對動態(tài)資源分配的支持經(jīng)歷了多次迭代。從 Kubernetes v1.26 到 v1.31，DRA 的經(jīng)典實現(xiàn)以 Alpha 特性形式提供，但由于其局限性和不完善性，該實現(xiàn)已經(jīng)被廢棄。目前主流 Kubernetes 版本(從 v1.32 開始)引入了更現(xiàn)代化的動態(tài)資源分配方法，在設計上更加成熟和穩(wěn)定，并被廣泛應用于生產(chǎn)環(huán)境。—02 —

如何在 Kubernetes 中使用 GPU 資源 ?

眾所周知，長期以來，在云計算領域，人們普遍認為計算資源主要以中央處理器(CPU)為中心，應用程序的開發(fā)和部署也大多圍繞 CPU 進行。這種以 CPU 為中心的模式在過去很長一段時間內有效地支撐了各種業(yè)務需求。然而，隨著人工智能、大數(shù)據(jù)分析、高性能計算等技術的蓬勃發(fā)展，以及新興業(yè)務模式的不斷涌現(xiàn)，越來越多的應用場景對計算能力提出了前所未有的高要求，需要遠超傳統(tǒng) CPU 的強大算力才能有效支撐業(yè)務的持續(xù)發(fā)展和創(chuàng)新。

在傳統(tǒng)的虛擬化或裸金屬服務器環(huán)境中部署和承載這些高算力需求的業(yè)務，往往會導致顯著的資源浪費。例如，為滿足峰值負載而配置的硬件資源，在業(yè)務低谷期會處于閑置狀態(tài)，造成巨大的經(jīng)濟成本消耗。此外，傳統(tǒng)的部署方式在資源彈性伸縮和快速部署方面也存在諸多限制，難以滿足現(xiàn)代應用快速變化的需求。

為了有效應對這些挑戰(zhàn)，實現(xiàn)降本增效的目標，越來越多的企業(yè)開始積極擁抱云原生技術，探索如何在云原生生態(tài)系統(tǒng)中實現(xiàn)資源的動態(tài)承載。云原生技術以容器化、微服務和自動化等為核心，能夠更好地管理和調度各種計算資源，包括 CPU、GPU、FPGA 等異構計算資源，從而實現(xiàn)資源的按需分配、彈性伸縮和高效利用，最大程度地降低成本并提高運營效率。

然而，在 Kubernetes 中部署 GPU 節(jié)點池，即使是初始階段，也需要一些特定于供應商的軟件組件，其中最關鍵的包括 Kubernetes 設備插件和 GPU 驅動程序。安裝 GPU 驅動程序是必不可少的，這是毋庸置疑的。然而，我們?yōu)槭裁催€需要安裝特定的設備插件呢?

原因在于 Kubernetes 平臺本身并不原生支持諸如 GPU 這類特殊硬件資源。設備插件的關鍵作用就在于發(fā)現(xiàn)并向應用程序暴露這些資源。其工作機制是：設備插件通過設備插件 API 接收可分配資源列表，并將其傳遞給 kubelet，從而對外呈現(xiàn)節(jié)點上的 GPU 數(shù)量。kubelet 負責持續(xù)跟蹤這些資源，并將節(jié)點上各種資源類型的數(shù)量匯報給 API Server，以便 kube-scheduler 在進行 Pod 調度決策時能夠充分利用這些信息。

然而，這種基于設備插件的方案存在一些固有的局限性：

• 資源選擇的精細程度有限： 只能通過一些節(jié)點屬性和標簽來對節(jié)點上的資源類型進行相對粗略的選擇，無法進行更精細的控制。
• 缺乏有效的調度反饋機制： 設備插件和 kube-scheduler 之間缺乏有效的反饋回路。這意味著，即使 kube-scheduler 為一個待調度的 Pod 找到了看似合適的節(jié)點，設備插件也無法根據(jù)節(jié)點的就緒狀態(tài)等關鍵因素進行進一步的“校驗”，這可能導致 Pod 被錯誤地調度到尚未完全準備好接收新資源的“未就緒”節(jié)點上。

為了有效克服上述局限性，Kubernetes 引入了動態(tài)資源分配(DRA)機制。DRA 的核心目標是確保應用程序能夠在恰當?shù)臅r機獲得所需數(shù)量的資源。“動態(tài)資源分配 API”將持久卷 API 的設計理念擴展到通用資源的管理，例如 GPU 等。它支持基于實時需求和預設配置進行動態(tài)的資源調整，從而最大程度地減少人工干預的需求。

如何理解 DRA(Dynamic Resource Allocation) ?

DRA 即全稱為(Dynamic Resource Allocation，動態(tài)資源分配) 是 Kubernetes 提供的一項至關重要的機制，用于實現(xiàn) Pod 和 Pod 內容器之間資源的高效請求、管理和共享。 DRA 的核心目標是通過靈活且統(tǒng)一的方式管理復雜的異構資源，使 Kubernetes 能夠適配現(xiàn)代云原生場景中日益多樣化的需求。在本質上，DRA 是對通用資源持久卷(Generic Resource Persistent Volume，PV)API 的泛化，其設計理念在于提供更強的靈活性，特別是在涉及 GPU 等特殊硬件設備時，DRA 的優(yōu)勢尤為明顯。

通常而言，DRA 核心特性與工作機制主要體現(xiàn)在如下幾點，具體可參考：

(1) 對通用資源持久卷 API 的泛化

傳統(tǒng)的資源分配方式通常只涵蓋 CPU 和內存等通用資源，而 DRA 的出現(xiàn)則使 Kubernetes 能夠支持更廣泛的資源類型。這種泛化的實現(xiàn)，使得 DRA 不僅限于硬件設備的管理，還能夠擴展到其他復雜資源類型，從而滿足不同場景下的動態(tài)需求。例如，在深度學習場景中，用戶不僅可以請求 GPU 資源，還可以指定具體的顯存大小或計算核心數(shù)，以便更精確地滿足任務需求。

(2) 第三方資源驅動程序的關鍵作用

DRA 的高效運行離不開第三方資源驅動程序的支持。這些驅動程序主要負責以下任務：

• 資源發(fā)現(xiàn)：檢測和報告節(jié)點上的可用資源狀態(tài)，例如 GPU 的數(shù)量、型號和當前負載情況。
• 資源分配：根據(jù)用戶的具體需求分配資源，并將資源綁定到目標 Pod。
• 資源監(jiān)控：在資源生命周期內持續(xù)跟蹤資源的使用狀態(tài)，以確保任務的順利完成并避免資源沖突。

通過第三方驅動程序，DRA 能夠實現(xiàn)對資源的細粒度控制。例如，在 AI 模型訓練任務中，用戶可以通過自定義驅動程序參數(shù)指定 GPU 顯存分配的上限，以適應特定模型對顯存的需求，從而最大化計算性能和資源利用率。

(2) 參數(shù)化與結構化的資源管理

DRA 在 Kubernetes 1.30 中引入了一種基于結構化參數(shù)的機制。這一機制允許用戶為不同類型的資源定義靈活的需求和初始化參數(shù)。例如：

• GPU 配置：可以指定顯存大小、計算核心數(shù)、CUDA 支持版本等。
• FPGA 配置：可以定義板卡型號、邏輯單元使用量或頻率等。
• 網(wǎng)絡設備：支持指定帶寬、吞吐量或 RDMA 能力。

基于這種參數(shù)化設計為用戶提供了高度靈活的資源定制能力，同時也為復雜資源的動態(tài)管理奠定了基礎。

作為 Kubernetes 動態(tài)資源管理中的關鍵機制之一，動態(tài)資源分配 (DRA) 目標在于為特殊資源的高效利用提供統(tǒng)一、靈活的管理方式。DRA 通過將資源的請求、分配、調度和監(jiān)控模塊化和參數(shù)化，使 Kubernetes 能夠以標準化的方式支持各種異構硬件資源，從而滿足現(xiàn)代云原生應用對高性能計算和精細化資源管理的需求。

Reference ：

• [1] https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
• [2] https://mp.weixin.qq.com/s/AqLNJoyDWxZDFEtGWEqpoA