GPU 排程新標準上線,HAMi 為何還沒退場:拆解 Kubernetes DRA 與執行期強制的分工
CNCF Blog · 2026-08-07
CNCF TAG Infrastructure 技術主席暨 HAMi 專案貢獻者 Mesut Oezdil 於 2026 年 8 月 7 日在 CNCF Blog 發表文章,比較 Kubernetes 原生的 Dynamic Resource Allocation(DRA)與開源 GPU 共享專案 HAMi,釐清兩者在 v1.34–v1.36 演進過程中的分工。文章結論很直接:DRA 接管了 GPU 資源的宣告與排程,但完全沒有取代 HAMi-core 在容器內攔截 CUDA/NVML 呼叫、實際強制配額的執行期機制。原文對照了兩個專案的 Kubernetes DRA 官方文件與 HAMi-DRA 安裝文件作為依據。
背景:device plugin 的整數計數困境
在 DRA 出現前,Kubernetes 的 device plugin 機制只能做整數式的裝置計數,無法描述「這顆 GPU 要切多少記憶體」或「哪些裝置屬性符合條件」。HAMi 原本填補的正是這個空缺:它用 mutating webhook 把使用者聲明的 vGPU 記憶體與算力請求編碼進 Pod annotation,再由自家排程器完成分配。DRA 官方文件則說明,新機制改用 Common Expression Language(CEL)做屬性篩選,並讓裝置分享與細粒度請求成為排程器原生能力,不再依賴外部 webhook 轉譯。
核心改動:ResourceClaim 接管排程,HAMi-core 留守執行期
根據 Kubernetes 官方文件,DRA 的核心物件是 DeviceClass(裝置分類)、ResourceClaim(資源請求)、ResourceClaimTemplate(依 Pod 生命週期自動產生請求)與 ResourceSlice(驅動回報節點上可用裝置)。DRA 已於 v1.35 預設啟用,v1.36 再把「優先順序清單」列為穩定功能。文件明確指出,這套 API 只負責排程時的分配決策與容量追蹤,並未涵蓋容器執行期實際限制裝置存取的機制。
對應到 GPU 場景,HAMi-DRA 文件說明它是「把傳統 GPU 資源請求轉換成 DRA ResourceClaim 的 mutating webhook」,需要 Kubernetes 1.34 以上版本、開啟 DRA Consumable Capacity feature gate,並要求 NVIDIA 驅動 440 以上。它提供兩種模式:Native DRA 模式直接建立帶容量規格的 ResourceClaim,DevicePlugin 相容模式則自動轉換舊式請求以維持相容。無論哪種模式,實際攔截 CUDA/NVML 呼叫的仍是 HAMi-core 透過 libvgpu.so 動態庫預載完成,DRA 規格本身不涉及這一層。
| 面向 | Kubernetes DRA | HAMi-core |
|---|---|---|
| 負責層級 | 排程與資源宣告(API 物件) | 容器執行期強制 |
| 核心機制 | ResourceClaim / ResourceSlice / DeviceClass | libvgpu.so 攔截 CUDA/NVML |
| 版本現況 | v1.35 起預設開啟 | HAMi v2.8/v2.9,HAMi-DRA v0.2.1 |
| 是否含執行期隔離 | 不含 | 是 |
影響範圍:叢集仍離不開 HAMi-core
對正在導入 GPU 共享的叢集管理者而言,升級到支援 DRA 的 Kubernetes 版本不代表可以移除 HAMi。若只部署 DRA,ResourceClaim 能讓分配決策在 API 層變得可見、可查詢,取代過去藏在 annotation 裡的隱性狀態,但裝置分配完成後,容器內部是否真的遵守記憶體與算力上限,DRA 完全無法過問。文章也提醒,HAMi-core 的軟體攔截層本身仍有已知弱點,例如針對驅動的靜態連結、CUDA_DISABLE_CONTROL 環境變數,以及容器中再起容器都可能繞過攔截,這些風險與 DRA 是否存在無關。DRA 解決的是排程可見度問題,HAMi-core 解決的是實際隔離問題,兩者疊加使用才是 HAMi 專案目前建議的部署方式。
原始來源:Kubernetes Dynamic Resource Allocation 官方文件、HAMi-DRA 安裝與使用文件
影子 AI 滲透 CI/CD:從開發者筆電到 Kubernetes 的六個失守節點
CNCF Blog · 2026-08-07
ReeVo SpA 資安工程師 Matteo Bisi 於 2026 年 8 月 7 日在 CNCF Blog 發表文章,針對「影子 AI」(Shadow AI)如何從開發者筆電一路滲透到 CI/CD 管線與 Kubernetes 執行環境,提出一套六階段威脅模型。文章把影子 AI 定義為「任何未經正式核准、未指定負責人、未做風險評估與監控的 AI 工具、模型、代理人或整合」。核心主張是防禦重心應放在 AI 從「給建議」轉為「能動手」的那個臨界點——也就是代理人開始持有 Git token、雲端憑證或 Kubernetes ServiceAccount 的時刻。
背景:六個交付階段各自的風險
文章沿著軟體交付路徑列出風險逐階段升高的六個節點:
- 開發者筆電:未經核准的 AI 助手外洩原始碼、密鑰與架構資訊
- 原始碼控管:擁有過大權限的 AI bot 能提交未經審查的不安全變更
- CI 管線:建置密鑰與雲端憑證外流,或觸發未經授權的供應鏈變更
- Artifact registry:含漏洞或來源不明的依賴項流入生產環境
- CD 平台:繞過變更控管、造成未授權部署
- Kubernetes 執行期:過度授權的 ServiceAccount 執行破壞性操作
威脅來源不只限於外部攻擊者,文章也點名惡意內部人員、被入侵的第三方服務供應商、prompt injection 攻擊,以及被下達模糊指令、卻擁有過大權限的代理人本身。
核心規格:用非人類身分治理取代單點防護
文章主張把 AI 代理人當成「非人類身分」(non-human identity)治理,而不是額外加裝單一防線。具體做法是用 SPIFFE/SPIRE 簽發短期身分憑證:每個工作負載取得格式為 spiffe://trust-domain/service-name 的 SPIFFE ID,再由 SVID(SPIFFE Verifiable Identity Document,X.509 憑證或 JWT)提供可自動輪替、不需要人工管理的憑證,取代 CI/CD 管線裡常見的長效期靜態密鑰。在 Kubernetes 執行期這一端,文章把 Kyverno 這類准入控制器列為「硬性關卡」:透過 ValidatingPolicy 或 MutatingPolicy,平台團隊能在准入時直接擋下缺乏簽章驗證、使用不明來源映像檔,或請求過大權限的工作負載,而不必仰賴代理人的指令設計是否可靠。
其餘建議機制包括:自主代理人限定在一次性、隔離的虛擬機工作區內執行;GitOps 平台(Argo CD、Flux)強制 pull-request 審批才能部署;Falco 與 Tetragon 做執行期異常偵測;Cilium 做網路分段;Sigstore/Cosign、Trivy、Syft、in-toto、Notation 等工具鏈負責簽章驗證與 SBOM 產生。文章反覆強調的架構原則是「單一控制失效時,代理人仍不能造成實質損害」,也就是沒有任何一層防護被賦予單獨兜底的責任。
影響範圍:命名空間層級 RBAC 成為前提
對已經在用 AI 輔助開發或自建內部代理人的團隊,文章的六階段模型等於是把既有 CI/CD 安全清單重新按「AI 專屬」角度盤點一次——尤其是命名空間層級 RBAC 是否把 AI 代理人與一般服務帳號區隔開。被點名的技術棧集中在 CNCF 專案:Kyverno、OPA/Gatekeeper 做准入策略,Falco 做執行期偵測,Cilium 與 SPIFFE/SPIRE 分別負責網路與身分邊界,顯示這套威脅模型的落地路徑預設建立在雲原生既有工具鏈之上,而非引入額外的 AI 專屬安全產品。