# Kubernetes GPU & 異構硬體管理的終極指南：深入動態資源分配 (DRA) 核心機制與未來
> 視覺化簡介：https://hctsai1006.github.io/k8s-dra
<center>
蔡秀吉</br>
國立陽明交通大學</br>
hctsai1006@cs.nctu.edu.tw
</center>
## **摘要 (Abstract)**
本綜述文章論證，Kubernetes 中的動態資源分配 (Dynamic Resource Allocation, DRA) 並非一項增量功能，而是一次根本性的典範轉移。此轉變是為應對現代工作負載，如人工智慧/機器學習 (AI/ML)、高效能運算 (HPC) 及 5G 電信，對日益複雜的異構硬體（如 GPU、FPGA、高效能網路卡）所提出的嚴苛要求。傳統的裝置插件 (Device Plugin) 框架已顯現出其在參數化、資源共享與拓撲感知方面的深刻架構性缺陷。本文旨在闡明，DRA 作為一個統一的、宣告式的、意圖驅動的框架，其演進是解決這些根本性缺陷的必然結果。
本文首先透過解構歷史脈絡，深入分析 Device Plugin 模型的內在限制。隨後，文章提供對 DRA 核心機制的深度技術剖析，以 GPU 資源管理（涵蓋 MIG、MPS、時間分片等高級共享策略）與先進網路資源管理為例，後者尤其受益於 KEP-4817 (資源宣告狀態) 與 KEP-5075 (可消耗容量) 的協同作用。最後，本文將 DRA 置於從指令式「基礎設施即程式碼 (IaC)」向宣告式「組態即資料 (CaD)」演進的宏觀哲學背景下，並與 Nephio 等更宏觀的意圖驅動自動化框架進行類比分析。我們得出結論：DRA 為 Kubernetes 奠定了關鍵的控制平面基礎，使其能夠駕馭未來複雜硬體的挑戰，從而實現一個真正由「應用需求」驅動資源調度的、更具彈性與自動化的未來。
## **前言/緒論 (Introduction)**
### **當代工作負載的基礎設施指令**
雲原生運算領域正處於一個關鍵的轉折點。驅動這一變革的力量，源自於新一代工作負載的崛起，特別是人工智慧/機器學習 (AI/ML)、高效能運算 (HPC) 以及 5G/電信網路功能。這些應用不再是傳統的無狀態、同質化服務；它們本質上是複雜、有狀態且對效能極度敏感的系統。其運作的有效性，高度依賴於對底層專用硬體的直接、可配置且高效的存取，這些硬體包括圖形處理單元 (GPU)、張量處理單元 (TPU)、現場可程式化邏輯閘陣列 (FPGA) 以及支援 SR-IOV 的高效能網路介面卡 (NIC)。這股趨勢對作為業界標準容器編排平台的 Kubernetes 提出了前所未有的挑戰：如何將這些複雜、異構的硬體資源，以一種原生、可擴展且符合雲原生哲學的方式，整合到其資源管理模型中。
### **第一代解決方案及其侷限**
為了應對此挑戰，Kubernetes 在 1.8 版本中引入了裝置插件 (Device Plugin) 框架，這是實現廠商中立硬體整合的關鍵第一步。該框架允許硬體供應商透過一個獨立的 gRPC 服務，向節點上的 Kubelet 通告其專用資源，而無需修改 Kubernetes 的核心程式碼。這無疑是一個重要的里程碑，為在 Kubernetes 上運行需要硬體加速的工作負載打開了大門。
然而，隨著硬體本身變得日益複雜與可分割，Device Plugin 框架的設計初衷，一個為相對簡單硬體時代所設計的模型開始顯現其根本性的侷限。其核心問題在於將複雜的硬體設備抽象為一個簡單的整數計數器。這種抽象模型無法傳遞結構化的配置參數，缺乏對裝置拓撲的感知能力，並且原生不支持在容器間共享昂貴的硬體資源。這些限制迫使平台工程師和開發者們採用各種脆弱且複雜的帶外 (out-of-band) 解決方案，例如：依賴節點標籤、註解或自訂排程器，這不僅增加了營運的複雜性，也違背了 Kubernetes 宣告式 API 的核心精神。
### **本文核心論點與結構**
本文的核心論點是：從 Device Plugin 框架到動態資源分配 (Dynamic Resource Allocation, DRA) 的轉變，並非一次迭代式的改進，而是一場必要的、根本性的典範轉移。DRA 以一個靈活、感知叢集狀態、且完全宣告式的 API，取代了過去僵化、僅限於節點本地的記帳機制。本文認為，這一轉變對於 Kubernetes 能否原生管理現代異構、可分割硬體的複雜性至關重要，並推動整個生態系統邁向一個真正由應用程式意圖 (application intent) 驅動的資源編排模型。
為完整闡述此論點，本文結構安排如下：第二章將深入探討歷史背景，剖析 Device Plugin 框架的架構性缺陷，論證為何一個新模型的出現已是歷史的必然。第三章將對 DRA 的核心機制進行深度技術拆解，分別以 GPU 和網路資源管理為案例，展示其統一資源模型的強大能力。第四章將 DRA 置於更宏觀的架構哲學背景下，將其與從「基礎設施即程式碼」到「組態即資料」的演進趨勢，以及與 Nephio 等意圖驅動框架進行類比，勾勒出一個完整的、分層的自動化架構願景。第五章將討論 DRA 帶來的營運模式轉變、當前的挑戰以及未來的發展方向。最後，第六章將對全文進行總結。
## **歷史的必然：從補丁到重構 (Historical Context and Problem Statement)**
要理解 DRA 的重要性，必須首先深入剖析其前身 **Device Plugin 框架** 的架構設計及其在實踐中暴露出的根本性缺陷。雖然該框架在初期成功地將硬體支援與 Kubernetes 核心解耦，但其核心設計理念最終成為了其自身發展的桎梏。
### **Device Plugin 框架：架構深潛**
Device Plugin 框架的核心機制相對直接。硬體供應商需要開發一個作為 DaemonSet 部署在每個節點上的插件。這個插件透過位於 `/var/lib/kubelet/device-plugins` 的 Unix socket 與該節點的 Kubelet 進行 gRPC 通訊。在註冊階段，插件會向 Kubelet 報告它所能提供的資源名稱（例如 `nvidia.com/gpu`）以及數量。Kubelet 隨後將這些資源作為節點的可分配資源 (allocatable resources) 向 API Server 匯報。當使用者在 Pod 的規格中請求這些資源時，Kubelet 便會調用插件的 Allocate gRPC 介面，插件負責準備設備並將所需的裝置檔案或環境變數提供給容器執行環境。
### **根本性缺陷：失真的抽象模型**
問題的根源在於該框架的核心抽象：一個不透明的整數計數器 (opaque integer counter)。Pod 規格中對擴展資源的請求，例如：`resources: { limits: { "nvidia.com/gpu": 1 } }`，本質上只是在請求一個計數單位。這種模型是對現代硬體真實能力的一種「失真壓縮 (lossy compression)」，它在抽象過程中丟失了過於豐富且關鍵的資訊，從而引發了一系列連鎖問題。
#### **缺乏粒度與參數化能力**
此模型最致命的缺陷是無法表達工作負載需要裝置的 *何種* 特定功能或配置。一個 `vendor.com/device:` 的請求是二元的：你要馬得到整個裝置，要馬什麼都得不到。Kubernetes 的原生 API 中沒有任何內建 (in-band) 的機制，允許使用者在調度時傳遞結構化的參數，例如請求特定型號的 GPU、GPU 的某個分割區 (partition)，或是為裝置設定特定的運作模式。
這種能力的缺失，迫使供應商和使用者訴諸於各種脆弱的變通方案。最常見的做法是利用節點標籤 (node labels)。例如，NVIDIA 的插件會搭配 GPU Feature Discovery (GFD) 工具，後者會偵測節點上 GPU 的各種屬性（如型號、記憶體大小、MIG 功能是否啟用），並將這些屬性作為標籤附加到節點上。使用者隨後必須在 Pod 規格中使用 `nodeSelector` 或 `nodeAffinity` 來間接表達他們的需求。這種方法將資源請求與節點選擇緊緊地綁定在一起，降低了調度的靈活性，並將資源配置的邏輯洩漏到了基礎設施的標籤管理中。
#### **原生不支持資源共享**
官方文件明確指出：「裝置不能在容器之間共享」。對於像高階 GPU 這樣昂貴的資源，這是一個巨大的限制，因為分割與共享對於提高利用率和成本效益至關重要。儘管 NVIDIA 等廠商提供了如 Multi-Process Service (MPS) 或時間分片 (Time-Slicing) 等共享技術，但這些技術的管理完全游離於 Kubernetes 的核心調度邏輯之外。通常，這些共享策略是透過 `ConfigMap` 進行配置，並由裝置插件本身在節點本地進行解釋和實現。這導致了一種脫節的用戶體驗：使用者在 Pod 規格中請求一個完整的 GPU，但實際上得到的卻是一個共享的、效能可能受影響的資源片段，**而 Kubernetes 的調度器對此一無所知**。
#### **缺乏拓撲感知**
Device Plugin 框架是一個純粹的節點本地 (node-local) 機制。Kubelet 只知道節點上有「N」個可用的裝置，但對這些裝置之間的物理或邏輯關係一無所知。例如，它不知道兩塊 GPU 是否透過高速的 NVLink 互連，也不知道某塊 GPU 與某張高效能網卡是否位於同一 PCIe 匯流排上以獲得最低延遲。由於調度器在做出決策時缺乏這些關鍵的拓撲資訊，它可能會將一個需要緊密耦合的 HPC 或 AI 訓練任務的兩個 Pod 分散到拓撲上不理想的節點，或者在同一節點上分配了物理位置疏遠的裝置，從而導致應用效能嚴重下降。
### **實踐困境案例分析：一個反模式的集合**
為了生動地展示這些架構缺陷在現實世界中的後果，我們可以構建一個基於 IBM AIU（一種假設的 AI 加速單元）整合的案例。假設 AIU 裝置有多種運作模式（例如，訓練模式、推論模式）和可配置的特性（例如，啟用特定硬體編解碼器）。若要使用 Device Plugin 框架來整合它，一個工程團隊將不可避免地陷入以下反模式的泥潭：
1. **名稱編碼 (Name Encoding)**: 為了暴露不同的裝置配置，團隊被迫發明複雜的資源名稱，例如 `ibm.com/aiu-mode-training` 和 `ibm.com/aiu-codec-enabled`。這會導致 API 中資源類型的爆炸性增長，使得資源管理變得極為混亂。
2. **自訂 Webhook**: 由於無法在請求時傳遞參數，團隊需要實現一個變異准入 Webhook (mutating admission webhook)。這個 Webhook 會攔截 Pod 的創建請求，解析 Pod 上的特定註解 (annotation)，然後將對應的裝置配置作為環境變數或掛載的設定檔注入到 Pod 規格中。這是一種典型的指令式、事後補救的操作。
3. **自訂排程器 (Custom Scheduler)**: 由於預設排程器無法理解這些透過註解傳遞的複雜約束，團隊最終可能需要編寫一個完全獨立的自訂排程器。這個排程器需要被設計成能夠讀取和理解這些自訂註解，並根據這些非原生約束來做出調度決策，這極大地增加了系統的部署和維護複雜性。
這個過程清晰地揭示了 Device Plugin 模型的窘境。它迫使工程師們層層堆疊補丁，每層補丁都離 Kubernetes 宣告式、意圖驅動的核心哲學更遠一步。正如社群中流傳的「烤麵包機比喻」所言：Device Plugin 只允許你請求「一台烤麵包機」，但現代工作負載的需求是「一個同時具備熱狗功能的烤麵包機上的貝果專用插槽」。
### **結論：新模型的必然性**
綜上所述，Device Plugin 框架的設計缺陷並非無關痛癢的小問題，而是深植於其核心抽象模型中的結構性障礙。隨著硬體變得越來越強大、越來越可程式化，圍繞這個僵化核心所構建的各種變通方案的複雜性已達到了臨界點。整個 Kubernetes 社群逐漸形成共識：需要一個全新的、原生的、宣告式的資源分配框架。這個新框架必須能夠將裝置的豐富特性、可共享性以及拓撲結構作為一等公民納入 Kubernetes API 和調度邏輯中。動態資源分配 (DRA) 正是應對這一歷史必然趨勢而生的架構重構。
## **核心機制解析：DRA 的統一資源模型**
動態資源分配 (Dynamic Resource Allocation, DRA) 作為 Device Plugin 框架的繼任者，其設計目標是從根本上解決前代模型的缺陷。它引入了一套全新的、基於 API 的宣告式原語，使得複雜硬體的請求、分配和配置成為 Kubernetes 的原生能力。DRA 的設計精髓在於其對成功模式的借鑒與推廣。
### **一個深思熟慮的架構類比：DRA 與 PV/PVC 模型**
DRA 的設計並非憑空創造，而是對 Kubernetes 中一個極其成功的模式 **用於儲存管理的 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 模型** 的推廣和泛化。這種設計上的刻意類比，為理解 DRA 的運作方式提供了一個絕佳的教學框架，讓經驗豐富的 Kubernetes 從業者能夠迅速掌握其核心概念：
* **ResourceClaim** 類比 **PersistentVolumeClaim (PVC)**：兩者都代表了使用者或工作負載對資源的**請求**。PVC 請求特定容量和存取模式的儲存空間；ResourceClaim 則請求具有特定屬性的通用裝置（如 GPU）。
* **ResourceSlice** 類比 **PersistentVolume (PV)**：兩者都代表了叢集中**可用**的實際資源實例。PV 代表一塊由管理員或動態供應的儲存卷；ResourceSlice 則由 DRA 驅動程式發布，用於通告節點上可用的裝置清單。
* **DeviceClass** 類比 **StorageClass**：兩者都由叢集管理員定義，用於描述一種**類型**的資源。StorageClass 定義了儲存的類型（如 fast-ssd）；DeviceClass 則定義了一類裝置的選擇標準和配置參數（如 high-memory-gpu）。
透過這個類比，DRA 將裝置管理從一個不透明的計數器，提升為一個結構化、生命週期明確的 API 對象模型。接下來，我們將透過兩個關鍵的應用領域 **加速器和網路** 來深入剖析這個模型的具體運作機制。
### **5.1 加速器資源管理（以 GPU 為例）**
GPU 是推動 DRA 發展的最主要驅動力之一。DRA 為解決 GPU 管理中的粒度、共享和異構性問題提供了原生的、優雅的解決方案。
#### **核心原語的協同運作**
讓我們以一個典型的 GPU 分配流程為例，來觀察 DRA 的核心 API 物件如何協同工作：
1. **`DeviceClass` (裝置類別)**：叢集管理員首先創建 `DeviceClass` 物件，用以定義不同種類的 GPU 資源。例如，可以創建一個名為 `nvidia-a100-mig-2g.20gb` 的 `DeviceClass`。這個類別可以包含一個 CEL (Common Expression Language) 表達式，用以從所有可用裝置中篩選出符合特定條件的裝置（例如，`spec.driver.name" \== "nvidia.com` 且 `attributes.gpu.product" \== "A100-SXM4-40GB` 且 `attributes.mig.profile" \== "2g.20gb`）。此外，`DeviceClass` 還可以包含一個 `parameters` 欄位，用於傳遞特定於供應商的配置資訊給 DRA 驅動程式。
2. **`ResourceSlice` (資源切片)**：在每個擁有 GPU 的節點上，NVIDIA 的 DRA 驅動程式會運行並負責清點可用的 GPU 資源。它會為每個可用的 GPU 實例（包括完整的 GPU 或 MIG 分割區）創建一個 `ResourceSlice` 物件並發布到 API Server。`ResourceSlice` 中詳細記錄了該裝置的唯一標識符、所屬節點以及一組豐富的屬性（如型號、記憶體大小、UUID 等）10。這構成了整個叢集的即時硬體庫存。
3. **`ResourceClaim` / `ResourceClaimTemplate` (資源宣告)**：應用程式開發者現在可以在其工作負載中宣告對 GPU 資源的需求。如果是一個獨立的 Pod，可以直接創建一個 `ResourceClaim`，並在 `spec.deviceClassName` 中引用之前定義的 `nvidia-a100-mig-2g.20gb`。對於像 Deployment 或 StatefulSet 這樣的控制器，開發者會使用 `ResourceClaimTemplate`。這樣，控制器會為每個 Replica Pod 自動創建一個獨立的 `ResourceClaim` 實例。
當帶有 `ResourceClaim` 的 Pod 等待調度時，Kubernetes 調度器會介入。它會掃描所有的 `ResourceSlice`，尋找一個尚未被分配且滿足 `ResourceClaim` 所引用的 `DeviceClass` 中 CEL 表達式的裝置。一旦找到匹配的裝置，調度器就會將該裝置的資訊寫入 `ResourceClaim` 的 `status` 欄位，並將 Pod 調度到該裝置所在的節點上。節點上的 Kubelet 隨後通知 DRA 驅動程式準備該已分配的裝置供容器使用。
#### **解鎖高級 GPU 共享策略**
DRA 的強大之處在於它如何將複雜的 GPU 共享策略無縫整合到上述的宣告式流程中。這在多個 KubeCon 演講中得到了重點展示。
* **多實例 GPU (Multi-Instance GPU, MIG)**：如上所述，DRA 可以將每個 MIG 實例視為一個獨立的、可被宣告的裝置。DRA 驅動程式將每個 MIG 分割區作為單獨的條目發布在 ResourceSlice 中。這使得 MIG 的使用從一種需要特殊標籤和自訂邏輯的變通方案，變成了 Kubernetes 原生的、可被調度器直接理解的資源類型。
* **時間分片 (Time-Slicing) 與多進程服務 (Multi-Process Service, MPS)**：對於這類共享模式，DRA 利用了其結構化參數的能力。管理員可以創建一個 `DeviceClass`，在其 `parameters` 欄位中指定 `sharingStrategy: time-slicing`。當開發者的 `ResourceClaim` 引用這個 DeviceClass 時，這個參數會被記錄下來。Pod 被調度到節點後，DRA 驅動程式會讀取這個參數，並相應地為該工作負載配置 GPU 的時間分片。這將配置邏輯從帶外的 `ConfigMap` 拉回到了帶內的、與資源請求綁定的宣告式 API 流程中，大大提高了透明度和一致性。
* **異構 GPU 管理與彈性調度**: 在 Kubernetes 1.33 中引入的 PrioritizedList alpha 功能，是 DRA 靈活性的又一力證 15。開發者可以在一個
ResourceClaim 中定義一個偏好順序列表，例如：「我首先想要一塊 A100 GPU；如果沒有，兩塊 V100 GPU 也可以接受；如果再沒有，就分配一塊 T4 GPU」。調度器會按照這個順序嘗試滿足請求，這極大地提高了工作負載被成功調度的機率和整個叢集的資源利用率，這是 Device Plugin 模型完全無法企及的。
### **5.2 網路資源管理 (The CNI-DRA Revolution)**
如果說 DRA 對 GPU 管理的改進是「優化」，那麼它對網路資源管理的影響則是「革命」。DRA 提出了一個全新的範式：將網路介面卡 (NIC) 及其功能（如頻寬、虛擬功能）視為可被宣告、分配和配置的一等公民裝置，從而克服了現有 CNI (Container Network Interface) 生態和 Multus 等工具的諸多限制。
這一革命性的轉變並非由單一功能促成，而是由兩個關鍵的、相輔相成的 Kubernetes 增強提案 (KEP) 共同實現的。一個提供了必要的「讀取」路徑（狀態回饋），另一個則提供了關鍵的「寫入」路徑（調度時的資源核算）。
#### **KEP-4817: 缺失的回饋迴路 (ResourceClaimDeviceStatus)**
第一個關鍵的賦能者是 KEP-4817，它在 Kubernetes 1.33 中晉升為 Beta。這個 KEP 的核心是解決一個長期存在的資訊不對稱問題：當一個資源在節點上被分配和配置後，叢集層面的其他組件（包括使用者）如何得知其運行時的狀態？
* **動機**: KEP-4817 的主要動機是為 DRA 驅動程式提供一個標準化的、基於 API 的通道，用以回報已分配資源的狀態 17。在網路場景下，當一個網路裝置被分配給 Pod 後，它可能會透過 DHCP 獲得一個 IP 位址，或者被分配一個特定的 MAC 位址。在 KEP-4817 出現之前，這些資訊被鎖在節點本地，無法被叢集中的其他控制器或使用者輕易獲取。
* **API 變更**: 該 KEP 為 ResourceClaim.Status 物件增加了一個新的 devices 欄位。這個欄位是一個列表，允許節點上的 DRA 驅動程式為其管理的每個已分配裝置回填任意的、特定於驅動程式的狀態資料。為了促進互通性，社群還提出了一個標準化的 `NetworkDeviceStatus` 子結構，用於回報網路裝置的通用資訊，如 IP 位址、MAC 位址、MTU 和運行狀態等。
* **使用者故事**: 這一變更解鎖了兩個至關重要的使用場景：
1. **網路服務自動化**: 其他控制器（例如 DNS 控制器、Service 控制器或 IPAM 系統）現在可以監聽 (watch) `ResourceClaim` 物件的狀態變化。一旦發現一個新的 IP 位址被分配，它們就可以自動為該 Pod 創建對應的 DNS 記錄或配置其他網路策略，實現端到端的自動化。
2. **增強的可觀測性與除錯**: 對於平台工程師和開發者而言，`kubectl describe resourceclaim \<claim-name\>` 命令變成了一個強大的除錯工具。他們可以直接從 API 中看到由驅動程式即時回報的網路介面狀態，例如 IP 是否成功分配、介面是否處於 UP 狀態等，極大地簡化了對複雜多網路環境的故障排查。
#### **KEP-5075: 實現有保證的 QoS (ConsumableCapacity)**
如果說 KEP-4817 提供了事後的回饋，那麼 KEP-5075 則提供了事前的保證。這個 KEP 旨在解決 Kubernetes 網路 QoS 的一個核心痛點。
* **痛點**: 長期以來，Kubernetes 中透過註解（如 `kubernetes.io/ingress-bandwidth`）來設定的頻寬限制並沒有真正的保證性。調度器在放置 Pod 時不會考慮這些註解。因此，兩個都宣告需要 10Gbps 頻寬的 Pod 完全有可能被調度到同一台主機的同一張 10Gbps 網卡上，導致嚴重的頻寬競爭和服務品質下降。
* **解決方案**: KEP-5075 引入了「可消耗容量 (Consumable Capacity)」的概念，將頻寬等資源轉化為可被調度器理解和核算的實體。其工作流程如下：
1. 在 `ResourceSlice` 中，CNI-DRA 驅動程式可以標記一個裝置（如一張實體網卡）為 shared: true，並定義其可被消耗的總容量，例如 `capacities: { "sriov.io/bandwidth": "10Gi" }`。
2. 在 `ResourceClaim` 中，使用者可以明確請求需要消耗多少容量，例如 `capacities: { "sriov.io/bandwidth": "5Gi" }`。
* **價值**: 這一機制從根本上改變了調度器的角色。調度器不再僅僅是匹配標籤，而是在執行真正的**資源會計**。當它評估一個節點是否適合放置某個 Pod 時，它會檢查該節點上對應 `ResourceSlice` 的剩餘容量。它會將所有已分配給該節點上 Pod 的 `ResourceClaim` 所消耗的容量進行匯總，並從總容量中減去。只有當剩餘容量足以滿足新 Pod 的請求時，調度才會成功。這意味著，透過 DRA 申請到的網路頻寬是**有保證的 (guaranteed)**，從而首次在 Kubernetes 中實現了原生的、可信的網路 QoS。
總而言之，DRA 透過這兩個 KEP 的協同作用，為網路管理帶來了閉環控制。KEP-4817 關閉了狀態監控的迴路，而 KEP-5075 則關閉了資源分配的迴路。兩者結合，使得 Kubernetes 終於能夠以一種與其核心宣告式哲學完全一致的方式，來管理複雜的網路資源。
## **架構哲學與宏觀類比 (Architectural Philosophy & Broader Context)**
動態資源分配 (DRA) 的意義遠不止於一組新的 API 物件；它標誌著雲原生基礎設施管理在核心哲學上的一次重要演進。要完全理解其深遠影響，必須將其置於從指令式自動化向宣告式、意圖驅動自動化的更廣闊技術浪潮中進行審視。本章節將 DRA 從微觀的技術實現提升到宏觀的架構哲學層面，並透過與 Nephio 等前瞻性專案的類比，揭示其在原則上的同構性。
### **宏大的統一主題：從指令式到宣告式**
雲原生技術的發展史，在很大程度上是一部不斷追求更高層次抽象和更徹底宣告式模型的歷史。DRA 的出現，正是這一歷史趨勢在硬體資源管理領域的集中體現。
* **基礎設施即程式碼 (Infrastructure-as-Code, IaC)**: IaC 是對傳統手動配置的巨大飛躍，它允許使用程式碼來定義和部署基礎設施。然而，許多早期的 IaC 實踐，雖然使用了程式碼，但在思維模式上仍帶有指令式 (imperative) 的色彩。它們的核心是定義
**如何 (how)** 達到目標狀態的一系列步驟或腳本。前一章節中討論的圍繞 Device Plugin 所構建的複雜變通方案——例如，編寫自訂排程器來解析註解，或使用 Webhook 來注入環境變數——正是這種指令式思維的體現。開發者或運維者需要精心編排一個過程，這個過程的正確性依賴於每一步的成功執行。這種模式往往是脆弱的，難以維護和擴展。
* **組態即資料 (Configuration-as-Data, CaD)**: CaD 代表了一種更為成熟的宣告式哲學。在這種模式下，系統的期望狀態被描述為一組結構化的**資料**（通常是 YAML 或 JSON 格式的 API 物件），而非一段待執行的程式碼。系統的核心職責變成了一個持續運行的**調節迴路 (reconciliation loop)**，它不斷地比較「觀測到的當前狀態」與「定義在資料中的期望狀態」，並自動採取行動來彌合兩者之間的差異。DRA 完美地體現了 CaD 的精神：開發者只需提交一個 ResourceClaim 物件來宣告**他們想要什麼 (what)**——例如，「一個具備特定 MIG 配置的 GPU」——而將**如何實現 (how)** 這一目標的複雜邏輯完全委託給系統內部的各個控制器（如 Kubernetes 調度器和 DRA 驅動程式）去處理。
### **宏觀與微觀的類比：Nephio 與 DRA**
如果說 DRA 是在節點和 Pod 層級實踐 CaD 哲學的微觀範例，那麼 Nephio 專案則是在整個網路和多叢集拓撲層級應用相同哲學的宏觀典範。透過比較這兩者，我們可以清晰地看到一種跨越不同抽象層次的、統一的架構思想。
* **Nephio 的使命**: Nephio 是一個基於 Kubernetes 的開源專案，旨在利用 Kubernetes 控制平面來自動化大規模、多廠商電信網路功能（如 5G 核心網）的部署和生命週期管理。其核心理念是允許網路架構師或運營商透過高層次的 Kubernetes 自訂資源 (CRD) 來表達他們的
**意圖 (intent)**，例如，「在三個地理位置分散的邊緣叢集上，部署一個具備特定容量和延遲要求的 5G 用戶平面功能 (UPF)。
* **共享的哲學與機制**: Nephio 和 DRA 雖然處理的抽象層次截然不同，但它們在底層的設計哲學上是同構的。它們都將 Kubernetes API Server 作為一個統一的「真理之源 (source of truth)」，並利用 Kubernetes 的調節迴路機制來驅動自動化。Nephio 使用這個機制來管理跨越多個叢集的複雜服務拓撲，而 DRA 則使用它來管理單一節點上的單個硬體裝置。
下表清晰地展示了從舊有的 Device Plugin 模式，到現今的 DRA，再到宏觀的 Nephio 框架，在關鍵架構維度上的演進路徑：
| 特性 (Feature) | 裝置插件 (Device Plugin) | 動態資源分配 (DRA) | Nephio |
| :---- | :---- | :---- | :---- |
| **抽象層級** | 低 (節點本地的裝置計數器) | 中 (叢集感知的資源宣告) | 高 (服務/拓撲層級的意圖) |
| **資源模型** | 不透明的整數 `(vendor.com/gpu: 1\)` | 結構化、有類型的 API 物件 (ResourceClaim) | 抽象、高層次的 CRD (例如 FiveGCore) |
| **參數化** | 帶外 (透過註解、環境變數) | 帶內、結構化的參數 | 高層次的意圖參數，逐層細化 |
| **共享與拓撲** | 原生不支持；需自訂邏輯 | 原生支援共享、分割與拓撲 | 管理相互連接的服務拓撲 |
| **生命週期** | 與 Kubelet 綁定；手動註冊 | 解耦；由控制平面管理 | 管理從基礎設施到組態的完整生命週期 |
| **主要參與者** | 叢集管理員 (安裝插件) | 應用程式開發者 (創建 ResourceClaim) | 網路架構師 (定義意圖) |
這個表格不僅僅是特性的羅列，它揭示了一條清晰的演進軌跡：責任的轉移（從管理員到開發者再到架構師）、模型的演進（從不透明到結構化再到抽象意圖），以及抽象層次的逐步提升。這有力地證明了 DRA 並非孤立的技術點，而是整個雲原生架構演進藍圖中的關鍵一環。
### **一個完整的、分層的自動化架構願景**
將這些層次串聯起來，我們可以勾勒出一個從頂層業務意圖到底層硬體實現的、無縫的宣告式自動化鏈條。設想一個電信營運商部署新服務的端到端流程：
1. **意圖定義 (Nephio 層)**: 一位網路架構師在 Nephio 的管理叢集中創建一個高層次的 CRD，定義了一個新的網路服務的意圖，包括其容量、覆蓋範圍和效能指標。
2. **意圖水合 (Nephio 層)**: Nephio 的控制器接收到這個意圖，並將其「水合 (hydrate)」成一系列更具體的、底層的組態。這包括為構成該服務的各個網路功能（如 AMF, SMF, UPF）生成對應的 Kubernetes 清單檔案（Deployments, Services 等）。
3. **資源宣告 (DRA 層)**: 在這些生成的清單中，UPF（用戶平面功能）的 Pod 規格包含了一個 ResourceClaimTemplate。這個模板宣告了該 Pod 需要一個支援 SR-IOV 的虛擬功能 (VF)，並透過 KEP-5075 的機制，要求保證 20Gbps 的頻寬。
4. **調度與分配 (Kubernetes/DRA 層)**: Kubernetes 的預設調度器接收到這個 Pod 的 ResourceClaim。它查詢由 CNI-DRA 驅動程式發布的 ResourceSlice，在整個叢集中尋找一個擁有可用 SR-IOV VF 且剩餘頻寬大於 20Gbps 的節點，並將 Pod 調度至此。
5. **硬體配置與狀態回報 (DRA/CNI 層)**: 目標節點上的 CNI-DRA 驅動程式被觸發。它負責在實體 NIC 上創建並配置所需的 VF，為其分配 IP 位址，然後透過 KEP-4817 的機制，將分配到的 IP 和 MAC 位址等狀態資訊回寫到 ResourceClaim 的 status 欄位中。
在這個理想的流程中，DRA 扮演了至關重要的橋樑角色。它將上層應用程式（由 Nephio 代表）對資源的抽象需求，精確地轉譯為對底層實體硬體的具體、可執行的配置操作，並將執行結果以結構化資料的形式回饋到控制平面。這構成了一個完整的、宣告式的、自我調節的自動化閉環。
## **討論 (Discussion)**
動態資源分配 (DRA) 的引入，不僅在技術層面重塑了 Kubernetes 的資源管理能力，更在營運模式、社群發展和未來架構演進上引發了深遠的影響。本章節將探討這些影響，分析當前面臨的挑戰，並展望其未來的發展軌跡。
### **營運與文化模式的轉變**
DRA 最顯著的影響之一，是它觸發了平台團隊與應用開發團隊之間協作模式的根本性轉變。傳統的 Device Plugin 模型本質上是一種「供給側驅動 (supply-side driven)」的模式。在這種模式下，叢集管理員負責安裝和配置各種裝置插件，並以一種相對固定的、預定義的方式（如節點標籤）向開發者「供給」一個可用的硬體資源目錄。開發者的角色相對被動，他們只能從這個有限的目錄中進行選擇。
DRA 則將此模式徹底轉變為「需求側驅動 (demand-side driven)」。現在，權力的天平向應用程式開發者傾斜。開發者可以透過 ResourceClaim 物件，以一種極其精確和富有表現力的方式，主動宣告其應用程式對硬體資源的**真實需求**。他們不再只是說「我需要一個 GPU」，而是可以明確地說「我需要一個擁有至少 24GB 記憶體、支援 MPS 共享模式的 GPU」。
這種轉變帶來了雙重效應。一方面，它極大地賦予了開發者權力，使其能夠為應用程式爭取到最優化的硬體配置，從而釋放最大的效能潛力。另一方面，這也對開發者提出了更高的要求：他們需要對其應用程式的硬體依賴有更深入的理解。這推動了一種新的文化，即應用程式的效能和資源需求成為其架構設計中不可或缺的一部分，促進了 DevOps 和平台工程文化的進一步融合。
### **當前的挑戰與社群的整合路徑**
儘管 DRA 的前景光明，但它作為一項仍在快速演進中的技術，其推廣和落地仍面臨一些挑戰。
首先，DRA 本身的成熟度仍在不斷提升。其核心功能在 Kubernetes 1.32 版本中進入 Beta 階段，社群的目標是在 1.34 版本中達到通用可用性 (GA)。然而，許多最強大的擴展功能，如 `PartitionableDevices`（動態分割裝置）和 `PrioritizedList`（優先級列表請求），在 1.33 版本中仍處於 Alpha 階段。這意味著早期採用者需要在享受新功能的同時，承擔一定的 API 穩定性風險。其次，在網路領域，如何將 DRA 與現有成熟的 CNI (Container Network Interface) 生態進行整合，是社群正在積極探討的複雜問題。KubeCon 的相關討論中浮現出幾種可能的路徑：
1. **CNI 的完全替代者**：一種激進的觀點認為，一個功能完備的 CNI-DRA 驅動程式最終可以完全取代傳統的 CNI 插件模型。
2. **Multus 的增強插件**：一種更為務實的方案是將 CNI-DRA 驅動程式作為一個插件，在 Multus（一個 CNI 元插件，用於為 Pod 附加多個網路介面）下工作，專門負責處理需要高級功能（如 SR-IOV、QoS保證）的網路介面。
3. **新的網路附加點 (Hook Point)**：另一種可能性是利用像 NRI (Node Resource Interface) 這樣的新介面，為網路設置提供一個獨立於 CNI 的、更靈活的附加點。
這些路徑各有取捨，社群的選擇將深刻影響未來 Kubernetes 網路架構的形態。這需要在保持向後兼容性、降低遷移成本和釋放新架構潛力之間做出艱難的權衡。
### **未來軌跡與前瞻性展望**
展望未來，DRA 的發展潛力遠未耗盡。它的出現為 Kubernetes 的進一步演進打開了新的想像空間。
* **與宏觀編排框架的深度融合**: 目前，我們可以設想 Nephio 這樣的宏觀框架生成 ResourceClaim。在未來，這種整合可能會更加深入。例如，Nephio 是否可以不僅僅是生成請求，而是根據高層次的服務等級目標 (SLO)，動態地創建和配置 DeviceClass？如果一個服務的 SLO 要求極低的延遲，Nephio 控制器可以自動生成一個 DeviceClass，其 CEL 表達式會篩選出與特定 CPU NUMA 節點緊密耦合的網卡，從而實現完全自動化的拓撲感知調度。
* **AI 驅動的意圖生成**: 更進一步，我們可以設想一種由 AI 驅動的意圖生成模式。一個先進的 AI 模型可以透過靜態分析應用程式的原始碼，或動態分析其在測試環境中的效能剖析數據 (performance profile)，來自動推斷出其最優的硬體資源需求。這個模型可以直接生成一個高度優化的 ResourceClaim，甚至可以為開發者推薦最合適的 DeviceClass。這將是意圖驅動自動化的終極形態，它將開發者從手動指定資源需求的負擔中解放出來，實現了從「程式碼」到「基礎設施」的智慧映射。
* **超越裝置的資源管理**: 儘管 DRA 目前的焦點主要集中在「裝置」上，但其 API 設計的泛用性（generic resources）為其未來擴展到其他資源類型預留了空間。例如，叢集中昂貴的軟體授權 (software licenses)、節點本地的特殊快取空間，或其他任何可被量化、可被宣告的資源，都有可能被納入 DRA 的統一管理框架之下。這將使 Kubernetes 的資源模型更加完整和強大。
總之，DRA 正處於其發展的早期階段，但它已經清晰地展示了其作為 Kubernetes 下一代資源管理基石的潛力。它不僅解決了過去遺留的技術債，更為雲原生生態的未來創新鋪平了道路。
## **結論 (Conclusion)**
本文深入剖析了 Kubernetes 資源管理從傳統的 Device Plugin 框架向動態資源分配 (DRA) 的演進，並論證了這不僅是一次技術升級，而是一場深刻的典範轉移。
我們首先回顧了歷史，指出了 Device Plugin 框架基於不透明整數計數器的核心抽象模型，在面對現代異構硬體的複雜性時，暴露出的在參數化、資源共享和拓撲感知方面的根本性、結構性缺陷。這些缺陷迫使生態系統採用各種脆弱且違背宣告式原則的變通方案，證明了一個全新模型的必要性。
接著，本文詳細闡述了 DRA 作為這一必然趨勢的解決方案。DRA 借鑒並推廣了 Kubernetes 中成功的 PV/PVC 模型，透過 ResourceClaim、DeviceClass 和 ResourceSlice 等一系列新的 API 原語，建立了一個統一、宣告式且富有表現力的資源請求與分配框架。透過對 GPU 和網路資源管理這兩個關鍵用例的深度分析，我們展示了 DRA 如何原生支持如 MIG 分割、MPS 共享等高級 GPU 策略，以及如何透過 KEP-4817 和 KEP-5075 的協同作用，首次在 Kubernetes 中實現了有狀態回饋和有保證 QoS 的網路管理。
最後，我們將 DRA 置於更廣闊的架構哲學背景下。它代表了從指令式「基礎設施即程式碼」(IaC) 向宣告式「組態即資料」(CaD) 的重要轉變。透過與 Nephio 等宏觀意圖驅動框架的類比，我們勾勒出一個從高層業務意圖到底層硬體配置的、無縫銜接的自動化願景。
總而言之，動態資源分配 (DRA) 為 Kubernetes 奠定了駕馭未來複雜硬體的統一、可擴展且面向未來的基礎。它用一個靈活、宣告式且意圖感知的 API，取代了過去僵化、指令式的計數器模型。這一根本性的轉變，將確保 Kubernetes 在 AI、HPC 和 5G 等新興工作負載定義的下一個運算十年中，繼續保持其作為領先基礎設施編排平台的地位。
> 本文成果承蒙陽明交大「高等教育深耕計畫」113 學年度第 2 學期「職涯學習助學金－校外職訓」計畫支持
:::spoiler **參考文獻 (References)**
* 6 Kubernetes Authors. (n.d.).
*Device Plugins*. Kubernetes Documentation. Retrieved from [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* 9 NVIDIA. (n.d.).
*NVIDIA/k8s-device-plugin*. GitHub. Retrieved from [https://github.com/NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)
* 4 Qin, L. (n.d.).
*Device Plugins*. Retrieved from [https://qinlj.github.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/](https://qinlj.github.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
* 8 Kubernetes Authors. (n.d.).
*Schedule GPUs*. Kubernetes Documentation. Retrieved from [https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/)
* 5 Kubernetes Authors. (2022, December 19).
*Kubernetes 1.26: Device Manager graduates to GA*. Kubernetes Blog.
* 10 Kubernetes Authors. (n.d.).
*Dynamic Resource Allocation*. Kubernetes v1.32 Documentation. Retrieved from [https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* 12 Google Cloud. (n.d.).
*About dynamic resource allocation (DRA)*. Google Kubernetes Engine Documentation. Retrieved from [https://cloud.google.com/kubernetes-engine/docs/concepts/about-dynamic-resource-allocation](https://cloud.google.com/kubernetes-engine/docs/concepts/about-dynamic-resource-allocation)
* 11 Kubernetes Authors. (n.d.).
*Dynamic Resource Allocation*. Kubernetes Documentation. Retrieved from [https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* 17 Kubernetes SIG Node. (n.d.).
*KEP-4817: Resource Claim Status With Possible Standardized Network Interface Data*. GitHub. Retrieved from [https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md)
* 20 Kubernetes SIG Node. (2025, January 22).
*DRA: Consumable Capacity \#5075*. GitHub Issues. Retrieved from [https://github.com/kubernetes/enhancements/issues/5075](https://github.com/kubernetes/enhancements/issues/5075)
* 19 Choochotkaew, S. (n.d.).
*KEP-5075: DRA with Consumable Capacity*. HackMD. Retrieved from [https://hackmd.io/@thc1006/BkkSllJ4lg](https://www.google.com/search?q=https://hackmd.io/@thc1006/BkkSllJ4lg)
* 2 Nephio Authors. (n.d.).
*About Nephio*. Nephio Project. Retrieved from [https://nephio.org/about/](https://nephio.org/about/)
* 26 Nephio Project. (n.d.).
*nephio-project/nephio*. GitHub. Retrieved from [https://github.com/nephio-project/nephio](https://github.com/nephio-project/nephio)
* 27 The Linux Foundation. (2022, April 12).
*The Linux Foundation and Google Cloud Launch Nephio to Enable and Simplify Cloud Native Automation of Telecom Network Functions*. The Linux Foundation.
* 28 Nephio Project. (n.d.).
*Nephio – Linux Foundation Project*. Retrieved from [https://nephio.org/](https://nephio.org/)
* 25 CNCF. (2025, March 7).
*Why Infrastructure as Code Needs to Be Secure by Default*. CNCF Blog.
* 21 Terramate. (n.d.).
*Rethinking IaC: Infrastructure as Code is the Answer*. Terramate Blog.
* 22 env0. (n.d.).
*Infrastructure as Code 101*. env0 Blog.
* 23 Spacelift. (n.d.).
*What Is Infrastructure as Code (IaC)?*. Spacelift Blog.
* 24 CNCF. (n.d.).
*Infrastructure as Code*. CNCF Glossary.
* 17 Kubernetes SIG Node. (n.d.).
*KEP-4817: Resource Claim Status With Possible Standardized Network Interface Data*. GitHub. Retrieved from [https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md)
* 7 B. T. V., Doug. (2025, January 31).
*Kubernetes Dynamic Resource Allocation (DRA) for... Networking?*. dougbtv.com.
* 18 Kubernetes SIG Node. (n.d.).
*KEP-4817 Tracking Issue*. GitHub Issues. Retrieved from [https://github.com/kubernetes/enhancements/issues/4817](https://github.com/kubernetes/enhancements/issues/4817)
* 16 Torkildsen, M., & Ohly, P. (2025, May 1).
*Kubernetes v1.33: New features in DRA*. Kubernetes Blog.
* 20 Kubernetes SIG Node. (2025, January 22).
*DRA: Consumable Capacity \#5075*. GitHub Issues. Retrieved from [https://github.com/kubernetes/enhancements/issues/5075](https://github.com/kubernetes/enhancements/issues/5075)
* 19 Choochotkaew, S. (n.d.).
*KEP-5075: DRA with Consumable Capacity*. HackMD. Retrieved from [https://hackmd.io/@thc1006/BkkSllJ4lg](https://www.google.com/search?q=https://hackmd.io/@thc1006/BkkSllJ4lg)
* 3 Patel, A. (2024, November 14).
*Open for Development: NVIDIA Works With Cloud-Native Community to Advance AI and ML*. NVIDIA Blogs.
* 13 Klues, K., & Chen, Y. (2024, November 14).
*Which GPU Sharing Strategy Is Right for You? A Comprehensive Benchmark Study Using DRA*. KubeCon \+ CloudNativeCon North America 2024\.
* 1 Jouin, L., & Choochotkaew, S. (2025, June 17).
*Reimagining Cloud-Native Networks: The Critical Role of DRA*. KubeCon \+ CloudNativeCon Japan 2025\.
* 29 Jouin, L., & Choochotkaew, S. (2025).
*Q\&A session from "Reimagining Cloud-Native Networks: The Critical Role of DRA"*. KubeCon \+ CloudNativeCon.
* 15 Torkildsen, M., & Ohly, P. (2025, May 1).
*Kubernetes v1.33: New features in DRA*. Kubernetes Blog.
* 14 Gaponcic, D. (n.d.).
*GPU Sharing at CERN: Cutting the Cake Without Losing a Slice\!*. KubeCon \+ CloudNativeCon.
* 2 Nephio Authors. (n.d.).
*About Nephio*. Nephio Project. Retrieved from [https://nephio.org/about/](https://nephio.org/about/)
* 11 Kubernetes Authors. (n.d.).
*Dynamic Resource Allocation*. Kubernetes Documentation. Retrieved from [https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* 20 Kubernetes SIG Node. (2025, January 22).
*DRA: Consumable Capacity \#5075*. GitHub Issues. Retrieved from [https://github.com/kubernetes/enhancements/issues/5075](https://github.com/kubernetes/enhancements/issues/5075)
* 2 Nephio Authors. (n.d.).
*About Nephio*. Nephio Project. Retrieved from [https://nephio.org/about/](https://nephio.org/about/)
* 19 Choochotkaew, S. (n.d.).
*KEP-5075: DRA with Consumable Capacity*. HackMD. Retrieved from [https://hackmd.io/@thc1006/BkkSllJ4lg](https://www.google.com/search?q=https://hackmd.io/@thc1006/BkkSllJ4lg)
#### **引用的著作**
1. Reimagining Cloud Native Networks: The C... \- KubeCon \+ CloudNativeCon Japan 2025, [https://kccncjpn2025.sched.com/event/1x71v/reimagining-cloud-native-networks-the-critical-role-of-dra-lionel-jouin-ericsson-software-technology-sunyanan-choochotkaew-ibm-research](https://kccncjpn2025.sched.com/event/1x71v/reimagining-cloud-native-networks-the-critical-role-of-dra-lionel-jouin-ericsson-software-technology-sunyanan-choochotkaew-ibm-research)
2. About – Nephio, [https://nephio.org/about/](https://nephio.org/about/)
3. Open for Development: NVIDIA Works With Cloud-Native Community to Advance AI and ML, [https://blogs.nvidia.com/blog/open-source-cloud-native-ai-ml/](https://blogs.nvidia.com/blog/open-source-cloud-native-ai-ml/)
4. Device Plugins \- SuperMap iDesktop .NET, [https://qinlj.github.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/](https://qinlj.github.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
5. Kubernetes 1.26: Device Manager graduates to GA, [https://kubernetes.io/blog/2022/12/19/devicemanager-ga/](https://kubernetes.io/blog/2022/12/19/devicemanager-ga/)
6. Device Plugins | Kubernetes, [https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
7. Kubernetes Dynamic Resource Allocation (DRA) for... Networking? \- dougbtv, [https://dougbtv.com/nfvpe/2025/01/31/k8s-dra-132/](https://dougbtv.com/nfvpe/2025/01/31/k8s-dra-132/)
8. Schedule GPUs | Kubernetes, [https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/](https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/)
9. NVIDIA device plugin for Kubernetes \- GitHub, [https://github.com/NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin)
10. Dynamic Resource Allocation | Kubernetes, [https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://v1-32.docs.kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
11. Dynamic Resource Allocation | Kubernetes, [https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
12. About dynamic resource allocation in GKE | Google Kubernetes Engine (GKE), [https://cloud.google.com/kubernetes-engine/docs/concepts/about-dynamic-resource-allocation](https://cloud.google.com/kubernetes-engine/docs/concepts/about-dynamic-resource-allocation)
13. KubeCon \+ CloudNativeCon North America 2024: Which GPU Sharing Strategy Is Right for... \- Schedule, [https://kccncna2024.sched.com/event/1i7ol](https://kccncna2024.sched.com/event/1i7ol)
14. GPU Sharing at CERN: Cutting the Cake Without Losing a Slice ..., [https://www.youtube.com/watch?v=\_pgOuaYwvBQ](https://www.youtube.com/watch?v=_pgOuaYwvBQ)
15. Kubernetes v1.33: New features in DRA, [https://kubernetes.io/blog/2025/05/01/kubernetes-v1-33-dra-updates/](https://kubernetes.io/blog/2025/05/01/kubernetes-v1-33-dra-updates/)
16. Kubernetes v1.33: Octarine, [https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/)
17. enhancements/keps/sig-node/4817-resource-claim-device-status ..., [https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4817-resource-claim-device-status/README.md)
18. DRA: Resource Claim Status with possible standardized network interface data · Issue \#4817 · kubernetes/enhancements \- GitHub, [https://github.com/kubernetes/enhancements/issues/4817](https://github.com/kubernetes/enhancements/issues/4817)
19. 用DRA 重新定義Kubernetes 網路：深度解析CNI 的下一步與 ..., [https://hackmd.io/@thc1006/BkkSllJ4lg?utm\_source=preview-mode\&utm\_medium=rec](https://hackmd.io/@thc1006/BkkSllJ4lg?utm_source=preview-mode&utm_medium=rec)
20. DRA: Consumable Capacity · Issue \#5075 · kubernetes/enhancements \- GitHub, [https://github.com/kubernetes/enhancements/issues/5075](https://github.com/kubernetes/enhancements/issues/5075)
21. Infrastructure as Code is the Answer \- Terramate, [https://terramate.io/rethinking-iac/infrastructure-as-code-is-the-answer/](https://terramate.io/rethinking-iac/infrastructure-as-code-is-the-answer/)
22. What is Infrastructure-as-Code? IaC 101 \- Env0, [https://www.env0.com/blog/infrastructure-as-code-101](https://www.env0.com/blog/infrastructure-as-code-101)
23. Infrastructure as Code : Best Practices, Benefits & Examples \- Spacelift, [https://spacelift.io/blog/infrastructure-as-code](https://spacelift.io/blog/infrastructure-as-code)
24. Infrastructure as Code (IaC) \- Cloud Native Glossary, [https://glossary.cncf.io/infrastructure-as-code/](https://glossary.cncf.io/infrastructure-as-code/)
25. Why Infrastructure as Code Needs to be Secure by Default | CNCF, [https://www.cncf.io/blog/2025/03/07/why-infrastructure-as-code-needs-to-be-secure-by-default/](https://www.cncf.io/blog/2025/03/07/why-infrastructure-as-code-needs-to-be-secure-by-default/)
26. nephio-project/nephio: Nephio is a Kubernetes-based automation platform for deploying and managing highly distributed, interconnected workloads such as 5G Network Functions, and the underlying infrastructure on which those workloads depend. \- GitHub, [https://github.com/nephio-project/nephio](https://github.com/nephio-project/nephio)
27. The Linux Foundation and Google Cloud Launch Nephio to Enable and Simplify Cloud Native Automation of Telecom Network Functions, [https://www.linuxfoundation.org/press/press-release/the-linux-foundation-and-google-cloud-launch-nephio-to-enable-and-simplify-cloud-native-automation-of-telecom-network-functions](https://www.linuxfoundation.org/press/press-release/the-linux-foundation-and-google-cloud-launch-nephio-to-enable-and-simplify-cloud-native-automation-of-telecom-network-functions)
28. Nephio – Linux Foundation Project, [https://nephio.org/](https://nephio.org/)
29. CNI Updates and Direction\! \- Michael Zappa, Microsoft & Lionel Jouin, Ericsson \- YouTube, [https://www.youtube.com/watch?v=sWQ6Vonzkr0](https://www.youtube.com/watch?v=sWQ6Vonzkr0)
:::
Sign in with Wallet
Connect another wallet