GPU 資源調度：k8s-device-plugin 知多少？

作者：Luga Lee 2024-12-17 16:20:40

人工智能云原生

在 AI 領域，GPU 作為加速計算的利器，其重要性不言而喻。云原生編排系統 Kubernetes 憑借其強大的資源調度能力，為 GPU 資源的管理提供了高效可靠的解決方案。

Hello folks，我是 Luga，今天我們來聊一下人工智能應用場景 - 基于 k8s-device-plugin 機制所實現的 GPU 資源動態調度。

近幾年，隨著大數據和人工智能技術的迅猛發展，AI 應用場景日益豐富，成為推動產業升級的重要驅動力。云計算作為 AI 發展的堅實基礎，提供了強大的計算資源和靈活的部署環境。

而 Kubernetes 作為云原生領域的旗艦項目，憑借其出色的可擴展性、高可用性和自動化能力，成為了管理云原生應用的事實標準。

而在 AI 領域，GPU 作為加速計算的利器，其重要性不言而喻。云原生編排系統 Kubernetes 憑借其強大的資源調度能力，為 GPU 資源的管理提供了高效可靠的解決方案。

一、如何理解 Kubernetes Device Plugin ?

Kubernetes Device Plugin 是 Kubernetes 中的一種標準化資源擴展機制，旨在將特殊硬件(如 GPU、FPGA)作為可調度資源集成到 Kubernetes 的資源管理框架中。

對于 NVIDIA GPU，Device Plugin 充當了連接 Kubernetes 調度器與底層 GPU 硬件的橋梁，負責發現、注冊和管理 GPU 資源，使工作負載能夠無縫利用 GPU 提供的計算能力。

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  restartPolicy: Never
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1 
  tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule

從本質上來講，Kubernetes Device Plugin 設計目標是提供一個通用的接口，使硬件供應商能夠開發自定義插件來支持其設備，同時確保與 Kubernetes 調度系統的良好兼容性。

眾所周知，Kubernetes 本身通過 Linux 的 namespace 和 cgroups 實現資源隔離與限制，將 CPU 和內存等資源按需分配給各個 Pod。例如，Kubernetes 可以根據節點的資源狀況，將需要計算和存儲的 Pod 調度到具有相應空閑資源的節點上，并為容器中的進程設置 CPU 和內存的配額。然而，當前 Kubernetes 內部尚不支持對 GPU 資源的直接調度和隔離，而是依賴于設備插件(Device Plugin) 和調度器擴展，通過第三方工具來完成這項功能。

NVIDIA Kubernetes 設備插件是 Kubernetes 中最常用的 GPU 設備插件之一，專門為 NVIDIA GPU 的資源分配與調度提供支持。其核心功能包括如下：

(1) 自動發現 GPU 設備

Device Plugin 能夠自動檢測節點中的 GPU 硬件，并將其作為資源注冊到 Kubernetes API 中，使調度器能夠識別和分配 GPU。

(2) 資源暴露與分配

Device Plugin 通過標準的 Kubernetes API，將 GPU 資源暴露給 Pods，使其能夠根據配置請求 GPU 加速計算資源。

(3) 硬件抽象

通過屏蔽底層 GPU 設備的復雜性，Device Plugin 提供了一個高層次的抽象接口，讓開發者專注于工作負載的邏輯，而無需關心硬件的具體細節。

(4) 熱插拔支持

Device Plugin 支持動態設備注冊，使得在集群運行時新增或移除 GPU 等硬件資源成為可能，大大增強了系統的靈活性。

(5) 與調度器的無縫集成

Device Plugin 能夠與 Kubernetes 調度器協同工作，根據 Pod 的資源需求高效調度 GPU 資源，避免資源爭搶或浪費。

二、Kubernetes Device Plugin 實現原理解析

當使用 Kubernetes 時，用戶通常希望能夠在 Pod 對象中直接聲明所需的 GPU 資源，并通過 Kubernetes 的調度器(kube-scheduler)自動完成所需 GPU 的分配。例如，以下 Pod 清單中使用了 limits 字段來指定對 NVIDIA GPU 的資源需求：

apiVersion: v1  
kind: Pod  
metadata:  
  name: cuda-vector-add  
spec:  
  restartPolicy: OnFailure  
  containers:  
    - name: cuda-vector-add  
      image: "k8s.gcr.io/cuda-vector-add:v0.1"  
      resources:  
        limits:  
          nvidia.com/gpu: 1

在上述配置中，nvidia.com/gpu 是聲明 GPU 需求的一種特殊字段，稱為 Extended Resource(擴展資源)，其值為 1，表示該 Pod 請求一個 NVIDIA 類型的 GPU。通過這種方式，用戶能夠在 Pod 級別直觀地表達對 GPU 資源的需求，極大地簡化了對高性能計算資源的使用和管理。

為了使 Kubernetes 能夠正確地調度 GPU 資源，調度器需要了解每個節點上的 GPU 可用情況。GPU 資源的可用量通常通過 Node 對象的 Status 字段報告。例如，一個節點對象可以包含以下狀態信息：

apiVersion: v1  
kind: Node  
...  
Status:  
  Capacity:  
    cpu:  2  
    memory:  2049008Ki  
    nvidia.com/gpu: 1

在上述狀態中，nvidia.com/gpu: 1 表示該節點擁有 1 個可用的 NVIDIA GPU。調度器根據這些信息，將 GPU 請求的 Pod 調度到滿足條件的節點上。

通常，在實際的業務場景中，為節點添加 GPU 資源的可用量信息，可以通過以下兩種方式實現：

1.手動更新 Extended Resource

Extended Resource 是一種基于節點級別(Node-level)的 API，允許用戶直接更新節點的 Status 字段以報告 GPU 的可用資源。例如，使用 PATCH 請求更新某節點的 GPU 資源。

$ curl --header "Content-Type: application/json-patch+json" \  
  --request PATCH \  
  --data '[{"op": "add", "path": "/status/capacity/nvidia.com/gpu", "value": "1"}]' \  
  http://localhost:8001/api/v1/nodes/<your-node-name>/status

這種方式適用于簡單場景，可以獨立于設備插件(Device Plugin)使用。通過手動更新節點的狀態信息，調度器便可記錄 GPU 類型及其可用數量。然而，這種方法需要額外的腳本化管理，維護成本較高，且不具備動態檢測硬件變化的能力。

2.使用 Device Plugin 自動維護

更常見和推薦的方式是通過 Device Plugin 來完成 GPU 資源的自動管理。在 Kubernetes 中，所有硬件資源(如 GPU、NIC、TPU 等)的發現、報告和分配通常由 Device Plugin 統一管理。

Device Plugin 會運行在每個節點上，自動檢測硬件資源的類型和數量，并通過 Kubernetes API 動態更新節點的狀態信息。

在 Kubernetes 中，所有專用硬件資源的管理都依賴于 Device Plugin(設備插件) 框架進行擴展和實現。Device Plugin 提供了一種標準化的機制，用于發現、注冊和管理節點上的專用硬件設備(例如 GPU、FPGA、NIC 等)。通過這一框架，Kubernetes 可以將這些硬件資源統一抽象為節點資源的一部分，從而納入標準的調度和管理流程。

不僅如此，Device Plugin 還負責匯報和維護 Extended Resources(擴展資源) 的狀態，這些擴展資源是 Kubernetes 用于表示專用硬件資源的一種邏輯抽象形式。在擴展資源匯報的過程中，設備插件會基于節點上的硬件狀態，動態更新資源的可用性和健康狀況，確保調度器能夠準確了解節點的資源分布情況。

如下圖所示，Device Plugin 在 Kubernetes 的資源管理體系中承擔了關鍵角色，通過與 Kubelet 的緊密協作，將專用硬件資源的發現與分配無縫集成到 Kubernetes 的調度框架中，為分布式環境中的硬件資源調配提供了標準化的支持。這一機制不僅提升了資源管理的靈活性，還極大擴展了 Kubernetes 的硬件適配能力，使其能夠支持各種復雜的異構計算場景，如 AI 訓練、數據分析和高性能網絡通信等。

通常而言，Kubernetes Device Plugin 的工作流程包括以下幾個關鍵步驟，具體可參考：

(1) 設備發現

Device Plugin 會掃描工作節點上的 GPU 設備，并通過 gRPC 接口向 kubelet 報告設備列表，包括每個設備的標識符和狀態信息。

(2) 設備注冊

Device Plugin 向 kubelet 注冊后，這些設備會被 Kubernetes API 服務器識別并記錄，成為 Kubernetes 資源調度的一部分。例如，GPU 資源可能被標記為 nvidia.com/gpu。

(3) 資源分配

當一個 Pod 請求 GPU 時，調度器根據請求的資源規格將任務分配到具有可用 GPU 的節點上。kubelet 與 Device Plugin 協作，為 Pod 分配所需的 GPU 設備，并將設備信息掛載到容器中。

(4) 生命周期管理

Device Plugin 負責監控 GPU 的狀態，確保其健康運行。當設備狀態發生變化(如故障或移除)時，Device Plugin 會通知 kubelet，觸發資源更新。

三、Kubernetes Device Plugin 優劣勢分析

隨著 Kubernetes 在異構計算場景(如 GPU、FPGA、NIC 等專用硬件資源)中的廣泛應用，Device Plugin(設備插件)機制成為 Kubernetes 內部管理專用硬件資源的標準化擴展方案。作為 Kubernetes 原生的設備管理框架，Device Plugin 提供了一種高效、靈活且可擴展的機制，用于發現、注冊和調度節點上的專用硬件資源。然而，盡管其在解決硬件資源調度難題方面表現出色，但仍然存在一定的局限性。

盡管通過 Device Plugin，Kubernetes 在調度時可以一定程度上滿足對 Extended Resource 的基本需求，但其調度機制主要基于設備數量的匹配。這種簡單的資源分配方式在面對異構設備或復雜硬件屬性需求時顯得不足。例如，當硬件設備的屬性多樣化且 Pod 對某些特定硬件屬性有明確要求時，單純依賴數量匹配的調度策略無法提供所需的精細化調度能力。此外，在資源分配方面，Device Plugin 對于配額(Quota)的限制粒度較粗，難以滿足更細化的資源管理需求。

1.基于節點標簽與節點選擇器的調度方案

為了彌補上述不足，一種常見的替代方案是使用 Node Label 和 Node Selector 來優化資源調度。通過為節點設置標簽(Node Label)并在 Pod 配置中使用選擇器(Node Selector)，可以實現某種類型硬件的定向分配。例如，將同一類型的 GPU(如 NVIDIA Tesla K80)掛載到同一個節點，并通過節點標簽將資源屬性暴露給調度器，從而實現按類型資源的調度。然而，這種方式依然存在明顯的限制：

屬性覆蓋不足：這種方法僅適用于同類型硬件資源的分配，無法支持更復雜的調度需求。例如，當一個節點上掛載了多塊顯存不同的 GPU(如 8GB 和 12GB)，某些應用希望使用顯存大于 10GB 的 GPU，這種需求無法通過節點標簽和選擇器實現。
靈活性不足：節點標簽是一種靜態配置，無法動態感知節點上硬件資源的變化。

2.基于 CRD 和調度器擴展機制的解決方案

為了解決上述問題，可以借助 Kubernetes 的 CustomResourceDefinition (CRD) 和 Scheduler Extender 機制。這種方法通過定義自定義資源(CR)來詳細描述硬件資源的屬性，并通過擴展調度器邏輯，實現對異構設備的精準調度。以下是具體思路：

(1)定義 CRD 表達設備屬性

自定義資源定義(CRD)可用來表示設備的復雜屬性，例如顯存大小、計算能力(Compute Capability)等。節點上的設備插件負責動態發現這些屬性并將其通過 CR 報告給 Kubernetes 集群。

(2)擴展調度器邏輯

使用 Scheduler Extender，可自定義調度邏輯，使調度器能夠根據 Pod 對資源的特定需求(如顯存大于 10GB)篩選符合條件的節點。這種方法通過外部擴展避免直接修改 Kubernetes 核心代碼，同時提高調度的靈活性和可擴展性。

(3)動態資源調度

結合 CRD 和調度器擴展，設備插件能夠動態報告硬件資源的狀態，并根據 Pod 的資源請求進行智能調度。這種方法特別適合處理異構設備場景。

盡管 CRD 和 Scheduler Extender 提供了更強大的功能，但它們的使用往往涉及到一定程度的 Kubernetes 源碼修改或額外的開發投入：

復雜性增加：引入自定義資源和擴展調度器需要開發和維護額外的邏輯，對團隊的技術能力提出了更高要求。
兼容性風險：擴展方案可能與 Kubernetes 的未來版本更新產生兼容性問題，增加了維護成本。

綜上所述，Kubernetes Device Plugin 是實現 GPU 資源調度的基礎組件，通過提供標準化接口將 GPU 資源透明地暴露給 Kubernetes 調度器，為工作負載的 GPU 需求提供精準匹配。其輕量化設計專注于資源分配，簡化了 GPU 與 Kubernetes 的集成，是滿足基本 GPU 使用需求的理想選擇。

然而，Kubernetes Device Plugin 功能相對單一，無法覆蓋驅動安裝、高級功能配置等更復雜的運維需求。因此，它更適合已完成基礎 GPU 環境搭建的場景，尤其是在對調度性能和資源開銷要求較高的工作負載中展現了獨特優勢。對于尋求靈活、高效 GPU 資源調度的用戶，Device Plugin 是一種低門檻、高適配性的解決方案。

Happy Coding ~

Reference ：

[1] https://github.com/NVIDIA/k8s-device-plugin
[2] https://aws.amazon.com/blogs/opensource/virtual-gpu-device-plugin-for-inference-workload-in-kubernetes/

責任編輯：趙寧寧來源：架構驛站

GPU 資源調度：k8s-device-plugin 知多少 ？