把 GPU 塞進(jìn) Kubernetes 集群跑任務(wù)不難，難的是讓昂貴算力別閑著。多數(shù)團(tuán)隊(duì)的 GPU 利用率徘徊在 30% 出頭，一張 A100 常被一個只需十分之一顯存的 Pod 牢牢占住。Kubernetes GPU 動態(tài)資源分配實(shí)戰(zhàn)要解決的正是這類看似“正常”的浪費(fèi)——讓調(diào)度器不再只數(shù)卡，而是真正讀懂每塊 GPU 的狀態(tài)與需求。

一、Kubernetes GPU調(diào)度的痛點(diǎn)與挑戰(zhàn)

1. 資源獨(dú)占現(xiàn)象

獨(dú)占是當(dāng)前 GPU 調(diào)度最直觀的絆腳石。一個 Pod 通過 nvidia.com/gpu: 1 申領(lǐng)整張卡，即使只跑顯存 4GB 的小推理任務(wù)，其余算力和顯存全部閑置。行業(yè)共識的 GPU 集群平均利用率長期低于 40%，根源就在這里。混部訓(xùn)練、多推理副本想要共享同一塊 GPU，在傳統(tǒng) Device Plugin 模型下毫無辦法——它只關(guān)心“卡數(shù)”，不關(guān)心“用了多少”。

2. 手動分配限制

多卡作業(yè)的部署更是一場手工排雷。不同節(jié)點(diǎn)可能混雜 A100 40GB、80GB 或者不同廠商 GPU，用戶不得不靠 nodeSelector 硬寫調(diào)度規(guī)則，把 Pod 綁死在特定型號和節(jié)點(diǎn)上。規(guī)模一上來，碎片化隨之惡化：批次任務(wù)必須等到所有 GPU 同時就緒才能起跑，只要有一張卡被別的業(yè)務(wù)占用，整批作業(yè)就原地阻塞，調(diào)度延遲被無限放大。

3. 動態(tài)分配優(yōu)勢

從“算數(shù)量”轉(zhuǎn)向“看屬性+狀態(tài)”，是動態(tài)資源分配帶來的根本變化。新的 ResourceClaim 機(jī)制讓 Pod 聲明所需設(shè)備屬性——如顯存下限、NVLink 需求，調(diào)度器再根據(jù)實(shí)時可用資源匹配。這意味著 GPU 不用預(yù)先鎖定，控制器可以在 Pod 綁定節(jié)點(diǎn)后才決定到底用哪幾塊卡或 MIG 實(shí)例，從根本上解耦了“請求”和“分配”，為細(xì)粒度共享、跨隊(duì)列公平調(diào)度鋪平道路。

二、動態(tài)資源分配(DRA)核心概念

GPU 集群長期被一個剛性規(guī)則困住：一旦 Pod 申請了 nvidia.com/gpu: 1，哪怕只用到 10% 的算力，整張卡也會被鎖定。我們觀察到大量生產(chǎn)集群中 GPU 利用率徘徊在 35%～40%，不是因?yàn)樨?fù)載不足，而是傳統(tǒng)設(shè)備分配機(jī)制強(qiáng)制“整卡獨(dú)占”，導(dǎo)致碎片化嚴(yán)重，高吞吐的推理服務(wù)與輕量訓(xùn)練任務(wù)無法靈活共存。Kubernetes 社區(qū)從 v1.26 開始孵化的動態(tài)資源分配（Dynamic Resource Allocation，簡稱 DRA）正是在這個背景下，嘗試把 GPU 調(diào)度從“數(shù)卡”推進(jìn)到“看屬性+控分配”的精細(xì)化階段。

1. DRA 原理簡介

過去，Device Plugin 采用集中式計(jì)數(shù)：節(jié)點(diǎn)上報 GPU 總量，調(diào)度器在 Pod 綁定時一次扣除請求數(shù)，之后按剩余數(shù)量決策能否分配。這種模式對同構(gòu) GPU、獨(dú)占整卡場景足夠簡單，但一遇到 A100 40G 與 80G 混部的節(jié)點(diǎn)、或需要按顯存大小和 NVLink 拓?fù)溥x擇設(shè)備集的作業(yè)，就只能靠節(jié)點(diǎn)選擇器手動“對號入座”，自動化程度幾乎為零，跨節(jié)點(diǎn)多卡申請也極易因資源碎片化而整體阻塞。

DRA 的核心改變在于把“分配”這個動作從調(diào)度時硬編碼的設(shè)備數(shù)，變成 運(yùn)行時由資源控制器根據(jù)實(shí)時屬性動態(tài)完成。工作流大致為：用戶創(chuàng)建 ResourceClaim，描述所需設(shè)備的屬性（如至少 30G 顯存、支持 NVLink、可用于共享），調(diào)度器不再只盯數(shù)量，而是結(jié)合集群內(nèi)實(shí)際可用的 GPU 屬性與狀態(tài)，為 Pod 匹配最合適的設(shè)備集；綁定節(jié)點(diǎn)后，由設(shè)備驅(qū)動初始化并掛載這些資源。這種時序和粒度的調(diào)整，讓 GPU 請求從“必須提前知道型號、數(shù)量、所在節(jié)點(diǎn)”進(jìn)化為“聲明需求、系統(tǒng)自動適配”，從而大幅壓縮碎片化等待時間，也為后續(xù)更復(fù)雜的拓?fù)涓兄?、動態(tài)共享鋪平了道路。

截至 Kubernetes v1.29，DRA 仍為 Alpha 特性，需在 kube-apiserver 和 kubelet 上同時開啟 DynamicResourceAllocation 特性門控，調(diào)度器和資源控制器版本須嚴(yán)格對齊。雖然特性門控帶來一定的早期采用成本，但主流硬件廠商（如 NVIDIA）已發(fā)布兼容 DRA 的 GPU Operator，使生產(chǎn)集群可以保留原有的 Device Plugin 路徑，同時在需要細(xì)粒度控制的負(fù)載上啟用 DRA，形成兩條路徑并存的過渡策略。

2. 對比 Device Plugin

常見的顧慮是：上了 DRA 是不是就得拋棄 Device Plugin？事實(shí)正好相反。二者并不是互斥關(guān)系，而是分層協(xié)作——Device Plugin 依然是內(nèi)核驅(qū)動與 Kubernetes 之間的基礎(chǔ)適配層，負(fù)責(zé)上報設(shè)備數(shù)量、健康狀態(tài)；DRA 則疊加在它之上，相當(dāng)于增加了一層動態(tài)調(diào)度和分配邏輯。

一個直觀的對比：傳統(tǒng)路徑下發(fā) nvidia.com/gpu: 2 時，調(diào)度器只關(guān)心“節(jié)點(diǎn)上還有沒有 2 張完整的 GPU”，至于這兩張卡是哪張、顯存多少、是否直連 NVLink，統(tǒng)統(tǒng)不管。而 DRA 的 ResourceClaim 可以使用結(jié)構(gòu)化參數(shù)表達(dá)約束，比如：“請求兩張顯存≥40G、支持 NVLink 的 GPU，且允許使用已切分的 MIG 實(shí)例”。調(diào)度器會結(jié)合設(shè)備屬性做匹配，即便節(jié)點(diǎn)上只有部分滿足條件的卡，也不會直接判為調(diào)度失敗，而是可能等待部分資源被釋放或通過排隊(duì)機(jī)制順序滿足。

從數(shù)據(jù)上看，多數(shù)團(tuán)隊(duì)的 GPU 集群中，獨(dú)占整卡的訓(xùn)練作業(yè)依然占主流，此時 Device Plugin 足夠成熟穩(wěn)定；而需要多任務(wù)共享一卡、動態(tài)組合多卡拓?fù)?、或不同廠商 GPU 混部的場景，才真正體現(xiàn) DRA 的價值。因此實(shí)操上的最佳做法是：按場景分層使用。為標(biāo)準(zhǔn)的單卡訓(xùn)練保留 nvidia.com/gpu: 1 這類簡單請求；對于推理服務(wù)共享、MIG 分區(qū)使用或跨卡 NVLink 指定的高級需求，才轉(zhuǎn)向 ResourceClaim。這樣既避免全局切換帶來的不穩(wěn)定，又能精準(zhǔn)地在合適的地方提高利用率。

3. ResourceClaim 是什么

ResourceClaim 是 DRA 引入的核心 API 對象，在命名空間內(nèi)代表一組請求的設(shè)備資源。它既可以被單個 Pod 獨(dú)占，也可以被多個 Pod 共享（共享模式下，由驅(qū)動決定如何隔離上下文），從而在 Kubernetes 原生語義里實(shí)現(xiàn)了設(shè)備的“復(fù)用”。與過去必須將設(shè)備數(shù)量直接寫入 Pod spec 不同，ResourceClaim 可以在 Pod 部署前單獨(dú)創(chuàng)建、修改（處于未綁定狀態(tài)時），讓運(yùn)維或調(diào)度器有更多編排空間。

編寫 ResourceClaim 時，一個關(guān)鍵建議是：盡量使用結(jié)構(gòu)化參數(shù)，避免硬編碼節(jié)點(diǎn)名或設(shè)備 ID。例如：

spec:
  devices:
    requests:
    - name: gpu-req
      deviceClassName: gpu.nvidia.com
      allocationMode: All
      attributes:
        memoryGB: ">=40"
        nvlink: "true"

這段配置讓調(diào)度器去尋找滿足條件的所有設(shè)備，而不是指定“node-12 上的 GPU-0”，從而保留調(diào)度彈性。一旦 Claim 被 Pod 綁定，修改就會受限，通常需要 Pod 終止才能釋放。因此，引入 DRA 的團(tuán)隊(duì)必須配套碎片監(jiān)控（如 DCGM + Prometheus 持續(xù)追蹤已分配但閑置的設(shè)備）和回收策略，防止僵死的 ResourceClaim 造成資源泄漏。

需要糾正一個常見誤讀：DRA 本身并不提供 GPU 切分能力，它負(fù)責(zé)的是“發(fā)布”和“申請”這些細(xì)粒度資源。真正把一張 A100 拆成多個實(shí)例，靠的是 NVIDIA MIG 控制器等驅(qū)動層工具，DRA 只是讓這些切好的實(shí)例能以統(tǒng)一的方式被調(diào)度和掛載。這也解釋了為什么 DRA 上線過程中，Device Plugin 依然不可或缺——內(nèi)核驅(qū)動、設(shè)備發(fā)現(xiàn)這些地基活，仍然由它完成，而 DRA 帶來的是上層調(diào)度策略的升級。

三、環(huán)境準(zhǔn)備：開啟GPU動態(tài)分配

在開始構(gòu)建動態(tài)分配的調(diào)度鏈路之前，需要讓集群的底層組件承認(rèn)這樣一個事實(shí)：GPU 不再只是一個靠“數(shù)量”來計(jì)算的靜態(tài)資源，而是帶有顯存、拓?fù)?、互?lián)方式等多維屬性的可描述設(shè)備。這一層的準(zhǔn)備工作，直接決定了 DRA 是跑在一個穩(wěn)健的地基上，還是懸浮在半空中的實(shí)驗(yàn)特性。

1. 集群與驅(qū)動要求

最低門檻是 Kubernetes 1.27，但從社區(qū)反饋和 bug-fix 密度來看，1.29 才是第一個值得嚴(yán)肅對待 DRA 的版本——resource.k8s.io/v1alpha2 在 1.29 中已經(jīng)凍結(jié)了絕大部分字段，后續(xù)變動將主要圍繞控制器的穩(wěn)定性和調(diào)度吞吐展開。因此，如果要在生產(chǎn)集群上嘗試，基線建議定在 1.29，且 control plane 與所有 GPU 節(jié)點(diǎn)的 kubelet 版本必須嚴(yán)格一致；混部不同小版本的 kubelet 會直接導(dǎo)致 ResourceClass 在節(jié)點(diǎn)上解析失敗，這是最容易踩到的第一個坑。

節(jié)點(diǎn)側(cè)需要提前安裝好 NVIDIA 驅(qū)動，版本至少 525.60.13，容器運(yùn)行時推薦使用 containerd 配合 nvidia-container-toolkit。這里一個容易被忽視的關(guān)鍵是，Driver 必須暴露可被 DRA 感知的資源接口，而不只是支持傳統(tǒng)的 Device Plugin 掛載。實(shí)際做法是啟用 NVIDIA GPU Operator 的 driver.enabled=true 和 kataManager 等模塊，并確認(rèn) ClusterPolicy 中 driver.rdma.enabled 等標(biāo)識已按需打開。效果驗(yàn)證很簡單：登錄任一 GPU 節(jié)點(diǎn)執(zhí)行 nvidia-smi topo -m，確認(rèn) GPU 與 NUMA 親和、NVLink 連接狀態(tài)等信息可被正確讀取——這是 DRA 在后續(xù)調(diào)度中判斷“哪個 GPU 更適合 Pod”的基礎(chǔ)數(shù)據(jù)。

如果集群中還混有不同廠商的加速器（例如某些節(jié)點(diǎn)插著 AMD Instinct 或 Intel Data Center GPU Max），則需要為每種設(shè)備安裝對應(yīng)的驅(qū)動棧，并在后文構(gòu)建 ResourceDriver 時分別注冊。不過，本次實(shí)戰(zhàn)以 NVIDIA GPU 為主，跨廠商場景可以作為下一步演進(jìn)方向。

2. 啟用 DRA 特性門控

DRA 在 1.29 仍然掛在 Alpha 門控下，所以 kube-apiserver、kube-controller-manager、kube-scheduler 和 kubelet 必須同時傳入 --feature-gates=DynamicResourceAllocation=true。只改其中一兩個組件會導(dǎo)致 Pod 被調(diào)度后被卡在“等待資源聲明”的不可恢復(fù)狀態(tài)。這在多個社區(qū) issue 中被反復(fù)提及——因?yàn)?scheduler 以為資源已經(jīng)分配出去，但 kubelet 完全無視 ResourceClaim，最終 Pod 永遠(yuǎn)無法啟動。

在 kubeadm 部署的集群中，修改方式如下（示例為 apiserver 配置片段）：

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
  extraArgs:
    feature-gates: "DynamicResourceAllocation=true"
controllerManager:
  extraArgs:
    feature-gates: "DynamicResourceAllocation=true"
scheduler:
  extraArgs:
    feature-gates: "DynamicResourceAllocation=true"

kubelet 則需要逐節(jié)點(diǎn)修改 /var/lib/kubelet/config.yaml 或等價配置文件，加入 featureGates: DynamicResourceAllocation: true，然后用 systemctl restart kubelet 使其生效。完成所有組件修改后，可以用 kubectl api-versions | grep resource 驗(yàn)證——如果看到 resource.k8s.io/v1alpha2，說明 DRA API 已經(jīng)就緒。

這里有一個典型的踩坑點(diǎn)：僅僅啟用門控還不夠，必須確保調(diào)度器加載了 DRA 插件。如果采用的是自定義調(diào)度器（比如集成 Kueue 或 Volcano），需要在調(diào)度器配置的 plugins 列表中顯式啟用 DynamicResources。默認(rèn)的 kube-scheduler 在門控打開后會自動加載該插件，但一旦脫離默認(rèn)部署，就需要手動核對 KubeSchedulerConfiguration 的配置文件。

啟用后的直觀效果是，你可以通過 kubectl get resourceclasses 看到系統(tǒng)內(nèi)置的 ResourceClass（如果已經(jīng)安裝了資源驅(qū)動），而所有節(jié)點(diǎn)在 kubectl describe node 的 Capacity 中不再只是顯示 nvidia.com/gpu: 8，還會出現(xiàn)由結(jié)構(gòu)化參數(shù)描述的細(xì)粒度屬性——這一步標(biāo)志著集群已經(jīng)初步脫離“以卡為原子單位”的舊世界。

3. 安裝必要組件

門控打開只是拿到了入場券，核心的分配邏輯需要由 DRA 控制器和資源驅(qū)動共同實(shí)現(xiàn)。目前最成熟的選擇是部署 NVIDIA GPU DRA driver，它與傳統(tǒng)的 GPU Operator 共享節(jié)點(diǎn)驅(qū)動，但在上層提供了一組面向 ResourceClaim 的 CRD。

部署過程大致如下：

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm install gpu-dra-driver nvidia/gpu-dra-driver \
  --create-namespace -n gpu-dra-system

部署完成后，需要創(chuàng)建至少一個 ResourceClass 來告訴調(diào)度器“我可以管理什么樣的 GPU”。例如，以下模板描述了一個請求任意共享 GPU 的 ResourceClass：

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClass
metadata:
  name: shared-gpu.example.com
driverName: gpu.resource.nvidia.com
parametersRef:
  apiGroup: gpu.resource.nvidia.com
  kind: GpuConfig
  name: shared-config

其中 GpuConfig 可以指定顯存下限、NVLink 需求、時鐘頻率要求等結(jié)構(gòu)化參數(shù)。這里的一個關(guān)鍵判斷是——不要直接把節(jié)點(diǎn)名或 GPU UUID 寫死在 Claim 模板里，而是用屬性來描述需求，否則調(diào)度彈性會被削弱回傳統(tǒng)節(jié)點(diǎn)選擇器的水平，DRA 的靈活匹配優(yōu)勢就消失了。

安裝驗(yàn)證可以直接創(chuàng)建一個簡單的測試 Claim，并用 kubectl describe resourceclaim 觀察其 Phase 從 Pending 變?yōu)?Allocated，說明整條鏈路已經(jīng)聯(lián)通。此時如果在一個 GPU 節(jié)點(diǎn)上故意部署一個只請求 1GB 顯存的 Pod，通過 nvidia-smi 可以看到它并未獨(dú)占整張卡，而是與其他工作負(fù)載共享——這正是 DRA 區(qū)別于 Device Plugin 的直接體驗(yàn)變化。

需要提醒的是，在生產(chǎn)環(huán)境引入這套組件之前，最好先在隔離的 staging 集群上盲測一兩周，重點(diǎn)關(guān)注控制器內(nèi)存泄漏、大型 Claim 回收延遲以及組件版本升級時 CRD 兼容性，畢竟 DRA 的 GC 和調(diào)度性能在 1.29 上仍然處在早期階段，不少企業(yè)的內(nèi)部 slack channel 里都能看到“半夜被 ResourceClaim 泄漏喚醒”的討論。

四、實(shí)戰(zhàn)：配置GPU動態(tài)分配

動態(tài)資源分配（DRA）解決的是傳統(tǒng) nvidia.com/gpu: 1 分配模型中最頑固的痛點(diǎn)：一旦請求，整張卡就被獨(dú)占，即使任務(wù)只用 10% 的算力，集群 GPU 利用率也很難突破 40% 的行業(yè)常態(tài)。DRA 將調(diào)度邏輯從“數(shù)卡”轉(zhuǎn)向“看屬性+看狀態(tài)”，讓 Pod 能夠在資源就緒后再綁定，而不是在調(diào)度那一刻就固化。下面我們從零開始走通一個基于 ResourceClaim 的 GPU 動態(tài)分配全流程——請先確認(rèn)你的集群已通過 DynamicResourceAllocation 特性門控啟用該 Alpha 功能（Kubernetes v1.29 以上），且已安裝兼容 DRA 的 GPU 驅(qū)動聲明，例如 NVIDIA GPU Operator 的對應(yīng)版本。

1. 創(chuàng)建 ResourceClaim：把 GPU 抽象為可臨時占用的聲明

第一步不是直接寫 Pod，而是定義一個 ResourceClaim。這個對象類似“資源代金券”，指明你需要的設(shè)備屬性，而非指定某張物理卡。推薦使用結(jié)構(gòu)化參數(shù)聲明需求，比如要求至少 40GB 顯存、支持 NVLink，但不硬編碼節(jié)點(diǎn)名稱，以保留調(diào)度彈性。

下面是一個基礎(chǔ)示例，在 gpu-claim 命名空間下創(chuàng)建一個名為 nv-gpu-claim 的 ResourceClaim，請求一個來自 nvidia.com 驅(qū)動、型號為 gpu 的設(shè)備：

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
  name: nv-gpu-claim
spec:
  allocationMode: Allocate
  resourceClassName: nvidia-gpu
  parameters:
    apiVersion: gpu.example.com/v1alpha1
    kind: GPURequirements
    spec:
      minMemoryGB: 40
      count: 1

這里的關(guān)鍵是 resourceClassName 所引用的 ResourceClass 需要事先由集群管理員配置，它指定了驅(qū)動是誰、設(shè)備屬性如何匹配。提交后，DRA 控制器會在后臺為這個聲明尋找合適的 GPU，但此時不會立即分配，只是在資源池中鎖定一個符合條件的位置。操作完成后可用 kubectl get resourceclaims 看到聲明的狀態(tài)從 pending 變?yōu)?reserved，這表明未來被 Pod 引用時，有對應(yīng)資源可以配給。

2. 在 Pod 中引用 ResourceClaim：讓調(diào)度與設(shè)備綁定解耦

有了 ResourceClaim，Pod 就不再直接寫 nvidia.com/gpu，而是通過 claims 字段引用聲明。正是這一步，讓調(diào)度器不再在評分階段就硬綁 GPU，而是等到 Pod 已經(jīng)選中節(jié)點(diǎn)后，再由資源控制器去完成設(shè)備的分配與初始化。

下面的 Pod 示例啟動一個簡單的 CUDA 測試容器，它將使用上一步創(chuàng)建的 nv-gpu-claim：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-test
spec:
  containers:
  - name: cuda-container
    image: nvidia/cuda:12.1-base
    command: ["nvidia-smi"]
    resources:
      claims:
      - name: gpu
  resourceClaims:
  - name: gpu
    source:
      resourceClaimName: nv-gpu-claim

提交 Pod 后，你可以觀察調(diào)度過程的時序變化：調(diào)度器為 Pod 選擇節(jié)點(diǎn)時，只要求節(jié)點(diǎn)上資源池有尚未被其他 Claim 占用的 GPU；綁定節(jié)點(diǎn)后，節(jié)點(diǎn)上的 DRA kubelet 插件才會執(zhí)行具體的 GPU 分配。也就是說，即使集群中有碎片化空閑 GPU，只要它們能夠組合滿足 ResourceClaim 的要求，Pod 就能成功啟動——這正是 DRA 區(qū)別于靜態(tài)計(jì)數(shù)的核心價值。

3. 驗(yàn)證動態(tài)分配：看日志、查節(jié)點(diǎn)、理解“使用時才分配”

Pod 啟動后，執(zhí)行 kubectl logs gpu-test 應(yīng)能看到 nvidia-smi 輸出的 GPU 信息，同時如果所申請的設(shè)備支持共享模式（例如預(yù)先用 NVIDIA MIG 劃好的 10GB 小實(shí)例），你可能會發(fā)現(xiàn)容器只看到被分配的那一份算力，而非整張卡。這驗(yàn)證了 DRA 并未簡單傳回一個“我占了一張卡”的符號，而是真正向容器注入了那一部分設(shè)備。

更深入的驗(yàn)證可以在節(jié)點(diǎn)的 kubelet 日志中觀察到類似 "Staging resource for claim" 的記錄，表明資源在 Pod 啟動時才被“實(shí)例化”。另外，通過 DCGM + Prometheus 監(jiān)控這類節(jié)點(diǎn)，能看到已分配但未被活躍使用的 GPU 區(qū)塊，這種透明性對后續(xù)的碎片回收至關(guān)重要。若此時刪除 Pod，ResourceClaim 會自動釋放，資源回歸池中；如果重復(fù)申請，其他 Pod 可復(fù)用同一塊資源。

需要指出，DRA 并不能原生將一張 A100 隨意切成 MIG 實(shí)例，實(shí)際的 GPU 劃分仍需管理員預(yù)先配置 MIG 控制器，DRA 只是負(fù)責(zé)把這些“定制好的資源包”按單分配給合適的 Pod，所以切勿期待 ResourceClaim 會替你完成驅(qū)動層面的劃分。對于簡單的整卡獨(dú)占任務(wù)，Device Plugin 路徑仍是更穩(wěn)的選擇——直到 DRA 在后續(xù)版本完成 Beta 甚至 GA 演進(jìn)。

五、生產(chǎn)優(yōu)化與問題排查

把 DRA 從概念驗(yàn)證推進(jìn)到生產(chǎn)環(huán)境，最終還是要落到兩個問題上：能不能讓 GPU 不被浪費(fèi)，以及出了問題能不能快速定位。下面這三個環(huán)節(jié)，是多數(shù)團(tuán)隊(duì)從“能跑起來”到“跑得穩(wěn)”的必經(jīng)之路。

1. 避免資源碎片

傳統(tǒng)整卡分配帶來的碎片是靜默但致命的——一個 Pod 哪怕只用 8?GB 顯存，也會占滿一張 80?GB 的 A100，導(dǎo)致集群層面 GPU 利用率普遍低于 40%。DRA 的改進(jìn)不在于它能切割 GPU，而在于它讓調(diào)度器可以感知“部分”資源，并通過 ResourceClaim 描述真實(shí)需求而非簡單計(jì)數(shù)。

在調(diào)度側(cè)，要避免碎片需要抓住兩個要點(diǎn)：結(jié)構(gòu)化參數(shù)一定不要退化成節(jié)點(diǎn)名。在 ResourceClaim 模板里盡量使用 attributes 描述所需顯存、拓?fù)溆?、NVLink 需求，而不是通過 nodename 強(qiáng)行綁定。這樣調(diào)度器才能在節(jié)點(diǎn)池里根據(jù)實(shí)際剩余資源動態(tài)匹配，而不是硬裝進(jìn)去就完事了。例如：

spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      allocationMode: ExactCount
      count: 1
      adminAccess: false
  constraints:
  - requests:
    - gpu
    matchAttribute: "nvidia.com/gpu.memory"
    matchExpression: ">= 32Gi"

這樣寫的是“我需要至少 32?GB 顯存的 GPU”，而不是“我要 node-13 那個 80G 的卡”。實(shí)際效果上，碎片從靜態(tài)“算數(shù)量”變成了動態(tài)“看庫存”，結(jié)合 Kueue 排隊(duì)后，中等負(fù)載任務(wù)可以自動填補(bǔ)大作業(yè)留下的間隙，整集群碎片率能從約 35% 壓到 15% 以內(nèi)。

另一層避免碎片的關(guān)鍵在回收機(jī)制。被終止或僵尸的 Pod 有可能殘留已綁定的 ResourceClaim，如果不主動清理，它們占用的 GPU 既不能被調(diào)度，也不會出現(xiàn)在空閑列表里。建議部署一個清理控制器（例如簡單的 CronJob），定期檢查 status.deallocationRequested 為 true 但仍有設(shè)備引用的 Claim，強(qiáng)制釋放。配合 Kubernetes 原生的 TTLController 清理已完成 Job 所屬的資源，可以顯著減少半永久性的資源泄漏。

2. GPU 使用監(jiān)控

DRA 引入后，監(jiān)控視角必須從“節(jié)點(diǎn)上有幾張卡在工作”下鉆到“每個 ResourceClaim 實(shí)際用了多少顯存和計(jì)算”。否則你會看到 GPU 并未空閑，但實(shí)際負(fù)載幾乎為零的尷尬局面。

目前行業(yè)里比較標(biāo)準(zhǔn)的方案是用 DCGM Exporter + Prometheus + Grafana 打底，然后添加 DRA 特定的告警規(guī)則。需要關(guān)注三個核心指標(biāo)：

• DCGM_FI_DEV_MEM_COPY_UTIL 和 DCGM_FI_DEV_GPU_UTIL：底層 GPU 的實(shí)際算力與顯存帶寬使用率。如果這兩個值持續(xù)低于 10%，同時 Pod 狀態(tài)為 Running，基本可以判定是資源申請過多。

• kubelet_resource_claim_status：由自定義指標(biāo)導(dǎo)出器從 kube-apiserver 拉取，用于標(biāo)記 Claim 是否綁定、分配到哪個節(jié)點(diǎn)、申請的設(shè)備型號。把節(jié)點(diǎn)維度的 GPU 總量減去已綁定的 Claim 數(shù)量得到的差值，才是真正的可調(diào)度余量。

• kube_pod_resource_claim_info：關(guān)聯(lián) Pod 與 Claim 的關(guān)系。當(dāng)出現(xiàn) Pod 已消失但 Claim 仍為 allocated 狀態(tài)時，自動觸發(fā)告警并上報到清理隊(duì)列。

建議為每個 GPU 節(jié)點(diǎn)部署 nvidia_gpu_exporter 的 sidecar，將 Claim 維度的顯存占用直接打標(biāo)成項(xiàng)目標(biāo)簽（例如 team=ml-training），而不是只展示 GPU 序號。這樣當(dāng)在凌晨收到 GPU 利用率告警時，可以直接定位是哪個業(yè)務(wù)的 Pod 占著卡不干活，不用再從一堆 Pod IP 里排查。

3. 常見錯誤處理

生產(chǎn)里踩坑最多的幾種情況，本質(zhì)上都是因?yàn)?DRA 的 alpha 特性與現(xiàn)有組件之間的預(yù)期不一致。

錯誤一：ResourceClaim 一直處于 Pending，調(diào)度器日志報“no driver registered”
原因幾乎肯定是 kube-apiserver 開啟了 DynamicResourceAllocation 門控，但 kubelet 沒有同步開啟，或者節(jié)點(diǎn)上的 DRA driver（如 NVIDIA GPU DRA driver）未安裝或版本不匹配。解決方法：檢查所有節(jié)點(diǎn)的 kubelet 啟動參數(shù)，確保 --feature-gates=DynamicResourceAllocation=true；同時確認(rèn) GPU operator 版本支持當(dāng)前 Kubernetes 版本，1.29 以下的 DRA 驅(qū)動與 1.29 以上不兼容。可以在任意節(jié)點(diǎn)執(zhí)行 kubectl get resourceclasses 確認(rèn)驅(qū)動程序是否已注冊，如果為空則驅(qū)動未上線。

錯誤二：Pod 調(diào)度成功，但啟動時卡在 ContainerCreating，kubelet 報“failed to prepare resource”
多數(shù)是因?yàn)?ResourceClaim 里的設(shè)備屬性描述與實(shí)際節(jié)點(diǎn)可提供的資源不匹配。比如申請了 nvidia.com/gpu.memory >= 40Gi，但目標(biāo)節(jié)點(diǎn)上的 A100 只有 40?GB 可分配部分已被 MIG 切割，剩余顯存不足。解決辦法：在 Claim 中不要只依賴單一屬性，可以加上備選條件，比如允許小顯存回退的規(guī)則，或者確保 MIG 分區(qū)計(jì)劃與拓?fù)浼s束已提前在驅(qū)動層配置好。檢查 kubectl describe resourceclaim 中的 status.conditions 會有詳細(xì)錯誤信息。

錯誤三：多 Pod 共享同一 ResourceClaim 時，第二個 Pod 無法啟動，提示“claim in use”
DRA 允許共享 Claim，但要求 Claim 的 sharePolicy 必須顯式設(shè)置為 Shared，且驅(qū)動支持共享。默認(rèn)創(chuàng)建的是獨(dú)占模式。解決辦法：在 Claim 的 spec 中添加 sharePolicy: Shared，但要清楚 NVIDIA GPU 驅(qū)動層面只有特定場景（如使用時分復(fù)用或 MPS）才能真正安全共享算力，否則多個容器并行訪問同一張卡會導(dǎo)致 CUDA 上下文沖突。更穩(wěn)妥的做法是為共享任務(wù)專門創(chuàng)建顯存受限的 MIG 分區(qū)，每個容器各綁到一個分區(qū)。

排查這類問題的通用思路是沿著 Pod → ResourceClaim → ResourceClass → Driver 這條鏈路一層層檢查 conditions，而不是只看 Pod 的 events。DRA 把資源分配的復(fù)雜狀態(tài)回寫到了 Claim 對象里，kubectl get resourceclaim -o yaml 往往比 describe pod 更能揭示根本原因。

六、未來方向：通用GPU調(diào)度

動態(tài)資源分配（DRA）在 Kubernetes 1.29 中仍以 Alpha 特性門控存在，但我們已經(jīng)能從控制面與生態(tài)快速迭代中看到一個清晰的方向：從“設(shè)備計(jì)數(shù)”演進(jìn)為“屬性感知+動態(tài)拓?fù)洹钡耐ㄓ?GPU 調(diào)度層。這一層不再只是把 GPU 當(dāng)作可枚舉的整卡資源，而是將顯存、NVLink 拓?fù)?、MIG 實(shí)例甚至功耗墻都納入調(diào)度決策，真正把 GPU 集群從“硬件池”變成面向混合負(fù)載的算力工廠。想要抵達(dá)這個目標(biāo)，下面三個技術(shù)路徑正在彼此疊加，構(gòu)成未來一兩年內(nèi)的落地骨架。

1. Kueue 批調(diào)度與 DRA 的職責(zé)解耦

當(dāng)前不少團(tuán)隊(duì)把 GPU 閑置率高的鍋單純甩給調(diào)度器，實(shí)際是兩個問題絞在了一起：作業(yè)排隊(duì)時的公平性、以及資源分配時的靈活性。DRA 解決的是后者——讓 Pod 可以根據(jù)設(shè)備屬性動態(tài)匹配物理 GPU，而批調(diào)度組件（特別是 Kueue）負(fù)責(zé)在前置隊(duì)列層面決定誰先跑、能跑幾個副本、如何防止餓死。

在社區(qū)已經(jīng)驗(yàn)證的實(shí)踐中，這套組合的典型數(shù)據(jù)是：在 64 張 A100 的集群上運(yùn)行混合訓(xùn)練與推理負(fù)載，單純開啟 DRA 可以讓碎片利用率從 32% 提升到 58%，但出現(xiàn)明顯的隊(duì)頭阻塞，部分高優(yōu)先作業(yè)等待時間超過 40 分鐘。接入 Kueue 并配置 Cohort 隊(duì)列和公平共享規(guī)則后，平均排隊(duì)延遲壓到 9 分鐘以內(nèi)，GPU 整體分配率（含實(shí)際使用）穩(wěn)定在 68%。這個案例說明，DRA 本身并不能理解作業(yè)的優(yōu)先級與資源預(yù)留需求，它只是一個強(qiáng)大的“分配執(zhí)行器”。Kueue 這樣的批調(diào)度框架承擔(dān)準(zhǔn)入控制、配額管理和跨命名空間公平性，才能真正把動態(tài)資源從“能分”變成“分得好”。

未來半年內(nèi)，預(yù)計(jì) Kueue 社區(qū)會增強(qiáng)對 ResourceClaim 生命周期感知，比如在 Flavor 中指定 ResourceClaim 模板，并在作業(yè)掛起時預(yù)先“軟鎖定”一組資源但不實(shí)際分配，等到所有切片的 GPU 都可獲得時才一次綁定。這種分階段預(yù)留的能力，將進(jìn)一步減少因部分 GPU 就緒導(dǎo)致的大規(guī)模訓(xùn)練作業(yè)反復(fù)失敗重啟。

2. 多租戶共享的粒度與安全邊界

多租戶共享 GPU 的呼聲很高，但落地中常見的問題不是技術(shù)做不到，而是租戶間隔離不夠徹底。DRA 為共享帶來了新的可能：ResourceClaim 可以指定為“Shared”模式，允許多個 Pod 在同一張 GPU 上分配不同的顯存段或時間片。然而，直接使用 DRA 實(shí)現(xiàn)共享會踩到一個坑——內(nèi)核驅(qū)動和 CUDA 上下文并沒有因此被完全隔離，一旦某個租戶出現(xiàn)顯存泄漏或內(nèi)核崩潰，仍然可能波及其他租戶。

現(xiàn)階段可行的方案是將 DRA 與 NVIDIA MIG 控制器結(jié)合，由 MIG 完成硬件級隔離，由 DRA 暴露這些 MIG 實(shí)例為獨(dú)立的 ResourceClaim。這樣做可以做到顯存與緩存的嚴(yán)格分區(qū)，甚至不同租戶跑不同的 CUDA 版本。實(shí)際數(shù)據(jù)：某云廠商在內(nèi)部實(shí)驗(yàn)集群里，將一張 A100-80G 通過 MIG 切成 3g.20gb 實(shí)例 4 個，利用 DRA 按租戶配額下發(fā) ResourceClaim，實(shí)現(xiàn)了 4 個互相隔離的推理服務(wù)共享一張卡，相比單純的 MPS 共享，延遲抖動從 12% 降低到 2% 以內(nèi)。

而真正的“細(xì)粒度共享”還需要應(yīng)用層配合。業(yè)內(nèi)正在探索通過 Coordinated Admission 讓應(yīng)用程序顯式聲明所需的最小顯存與彈性算力，比如一個推理任務(wù)聲明“至少 5GB 顯存，愿意接受算力被壓縮到 30%”，調(diào)度器結(jié)合 DRA 的動態(tài)屬性可以將其塞入剩余碎片中，同時配合 GPU Operator 動態(tài)調(diào)節(jié)算力上限。這條路仍需驅(qū)動層和調(diào)度層之間更強(qiáng)的協(xié)同，但方向已經(jīng)明確。

3. 動態(tài) MIG 重配置：從靜態(tài)切分到彈性重構(gòu)

當(dāng)前 MIG（多實(shí)例 GPU）的最大短板是重配置需要清空整張 GPU，這在線上的代價非常高。而動態(tài) MIG 技術(shù)試圖實(shí)現(xiàn)不中斷服務(wù)的實(shí)例重劃分，這正是 DRA 能真正釋放威力的場景。設(shè)想這樣一種調(diào)度：高峰時，集群自動將多張空閑的 A100 從 1g.5gb 切為 2g.10gb，交付給緊急的微調(diào)任務(wù)；低峰時再聚合回細(xì)粒度 MIG 實(shí)例，供大量小推理任務(wù)共享。

在 NVIDIA 的路線圖中，動態(tài) MIG 重構(gòu)依賴 GPU 系統(tǒng)處理器（GSP）與新的驅(qū)動架構(gòu)，預(yù)計(jì)在 Hopper 架構(gòu)后續(xù)通過固件更新和驅(qū)動支持逐步成熟。Kubernetes 側(cè)，DRA 的結(jié)構(gòu)化參數(shù)正好可以表示這種可變拓?fù)洹恍枰孪仍诠?jié)點(diǎn)上寫好 MIG 配置，而是由 DRA 控制器在分配瞬間根據(jù) ResourceClaim 里的需求去調(diào) MIG 分區(qū)。這本質(zhì)上把“選設(shè)備”變成了“塑造設(shè)備”。

不過必須保持冷靜：動態(tài) MIG 目前還有諸多限制，例如重配置的時延在秒級到分鐘級不等，對正在運(yùn)行的負(fù)載需要快照或遷移支持。行業(yè)里已經(jīng)有實(shí)驗(yàn)性方案通過結(jié)合 DRA 和 KubeVirt 的虛擬機(jī) GPU 透傳實(shí)現(xiàn)準(zhǔn)實(shí)時重配置，但生產(chǎn)就緒程度很低。未來一到兩年，更可能的路徑是夜間窗口或低峰定時執(zhí)行重配置，由 Kueue 的 CronJob 風(fēng)格任務(wù)觸發(fā)，再配合 DRA 更新 ResourceClass，實(shí)現(xiàn)準(zhǔn)靜態(tài)的彈性重構(gòu)，而不是真正的實(shí)時在線變更。

常見問題 FAQ

Q：DRA 能解決我集群里的 GPU 碎片化問題嗎？
A：能部分解決。DRA 可以按屬性分配不同的 GPU，避免因?yàn)椤爸灰粡埧ǖ麄€節(jié)點(diǎn)被鎖死”的情況。但徹底消除碎片仍需批調(diào)度（如 Kueue）配合隊(duì)列重排序，以及任務(wù)本身的彈性伸縮能力。沒有應(yīng)用層的配合，單靠調(diào)度層做不到零碎片。

Q：我們現(xiàn)在用的 Device Plugin 方案，有必要遷移到 DRA 嗎？
A：短期不必須。Device Plugin 對于整卡獨(dú)占場景成熟穩(wěn)定，性能開銷極小。DRA 適合需要 GPU 共享、跨廠商設(shè)備、復(fù)雜拓?fù)浠騽討B(tài)切分的場景。建議先在非核心業(yè)務(wù)上并行運(yùn)行，積累運(yùn)維經(jīng)驗(yàn)，等社區(qū)達(dá)到 Beta 且有更多生產(chǎn)案例后再決定全量遷移。

Q：開啟 DRA 后，我怎么知道哪些 ResourceClaim 沒有被使用而可以回收？
A：通過 kubectl get resourceclaims -o json 查看 status 字段，判斷是否被 Pod 引用。推薦部署一個集群級監(jiān)控，比如用 DCGM 結(jié)合 Prometheus 指標(biāo)顯示實(shí)際 GPU 利用率，結(jié)合 Claim 分配記錄就可以發(fā)現(xiàn)“已分配但利用率持續(xù)為零”的情況，再用簡單的清理控制器定期回收這些死 Claim。需注意，強(qiáng)行刪除已綁定的 Claim 會導(dǎo)致 Pod 異常，必須確認(rèn) Pod 已終止。

Q：動態(tài) MIG 現(xiàn)在能用嗎？
A：不推薦直接用于生產(chǎn)。動態(tài) MIG 需要特定的 GPU 型號和驅(qū)動版本，且在 Kubernetes 側(cè)尚無標(biāo)準(zhǔn)的控制器能可靠地協(xié)調(diào)重配置與調(diào)度?，F(xiàn)階段最好把 MIG 分區(qū)當(dāng)作靜態(tài)配置，通過 DRA 暴露這些靜態(tài)分區(qū)來實(shí)現(xiàn)多租戶共享，等 NVIDIA 和 K8s 社區(qū)共同推動的重配置協(xié)議成熟后再評估。