# Dynamic Resource Allocation (DRA) ## 定義 Dynamic Resource Allocation(DRA)は、[[Kubernetes]]がGPU・FPGA等のアクセラレータデバイスをPodへ割り当てるための、kubelet デバイスプラグインAPIに代わる宣言的リソースモデルである。ノードごとにDRAドライバが公開する `ResourceSlice`(利用可能デバイス一覧+属性)、ユーザーが要求を宣言する `ResourceClaim`、管理者が定義する `DeviceClass` という3つの新規APIオブジェクトを軸に構成される。デバイス選択はCEL式のセレクタで行われ、ベンダー固有の設定パラメータをスケジューリング判断から分離しつつドライバへ受け渡す「構造化パラメータ(structured parameters)」方式を採る。Kubernetes 1.30でアルファ実装され、1.34でGA昇格した。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]]) デバイスプラグインAPIとの違いは、(1) ネットワーク接続デバイスをノードローカル発見の制約なしに表現できる、(2) 複数コンテナ・複数Pod間でのデバイス共有を第一級でサポートする、(3) 初期化コストの高いデバイスの使い回しに対応する、(4) ベンダー定義のカスタム設定パラメータをアノテーション経由のハック無しに渡せる、という4点にある。両APIは置き換えではなく共存を前提とし、単一の線形量で表現できるデバイスにはデバイスプラグインAPIが引き続き適する。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]]) ## 横断的知見 - **DRAはオーケストレーション層の「要求・割当」を担い、MIG/MPSのようなハードウェア層の「分割・多重化」機構とは別レイヤーで補完関係にある**: [[GPU多重化(MPS・MIG)]] が扱うMIGの静的パーティショニング(カード再構成にGPUリセットが必要)は、KEP-4381の "Partial GPU allocation" ユーザーストーリーが前提とする「事前に分割済みのGPUスライスを `gpu.acme.example.com/memory` のような属性で選択する」仕組みとちょうど対応する。KEP自身も、需要に応じてカードを動的に再構成する機能(dynamic reconfiguration)は本KEPのスコープ外であり、["partitionable devices" 拡張](https://github.com/kubernetes/enhancements/issues/4815)という別KEPに委ねると明記しており、DRAが解くのは「どの(既に分割された)デバイスをどのPodに割り当てるか」というオーケストレーション判断であって、デバイスをどう分割するか自体はDRAの管轄外である。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]], [[GPU多重化(MPS・MIG)]]) - **コンテナオーケストレーション研究が「未開拓」と指摘してきたリソース宣言の柔軟性不足に対する、Kubernetesコア自身による約10年越しの回答である**: [[コンテナオーケストレーション]] concept が引く Pahl ら(2019, IEEE TCC)は2016年時点のコンテナオーケストレーション研究のギャップとして障害管理や理論基盤の不足を挙げていたが、リソース要求モデルそのものの表現力不足(単一の線形量でしか資源を表現できない)は当時のデバイスプラグインAPIにも内在していた限界であり、DRAはこの「リソース要求の表現力」という別軸のギャップを、Kubernetes 1.30〜1.34という長期の段階的リリースを経て埋めた事例として読める。(Source: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]], [[コンテナオーケストレーション]]) - **DRAとギャングスケジューリングは、Kubernetesコアが同時期に異なる軸で「単純化されすぎた旧モデル」を置き換える、並行した進化として読める**: DRAはPodあたりのデバイス要求表現力(単一の線形量しか表せない旧デバイスプラグインAPI)を刷新する一方、[[Kubernetes Workload・PodGroup API]]([[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]])はPod集合のスケジューリング単位(1Pod単位でしか考えられない旧pod-by-pod cycle)を刷新する。両者は互いに独立した拡張だが、KEP-4671自身が「DRAリソースをブロックする際に `NominatedNodeName` だけでは解決できない」という未解決のコーナーケースを明記しており、将来の `Reservation` オブジェクトが両概念を接続する結節点になる設計が示唆されている。(Source: [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]]) ## 未解決の問い - MIG/MPSのような静的・動的パーティショニング機構をDRAドライバとして実装する際、["partitionable devices" 拡張](https://github.com/kubernetes/enhancements/issues/4815)(別KEP、本ソースでは概要のみ言及)は具体的にどのAPIを追加し、DRAの `ResourceSlice`/`ResourceClaim` モデルとどう統合されるか。原KEPの取り込みが必要。 - GA条件として課される「異なる組織による3つ以上の実DRAドライバ実装」は、実際にどのベンダー(NVIDIA・AMD・Intel等)のどのドライバで満たされたか。[[GPU多重化(MPS・MIG)]] が扱うNVIDIA GPU Operator・MIG Managerとの統合状況を今後のソースで確認する必要がある。 - DRAの `Filter` 拡張点における既定10秒のタイムアウトと `DRASchedulerFilterTimeout` フィーチャーゲートは、[[GPUクラスタスケジューリング]] が扱う大規模マルチテナントGPUクラスタ(数千ノード規模)でどの程度のスケジューリング遅延を実際に生むか。実測ベンチマークとの突き合わせが必要。 - KEP-4381自身が明記する「侵害されたkubelet plugin(DRAドライバ)がroot権限昇格の経路になりうる」というリスクは、実運用クラスタでどのような緩和策(capabilities最小化、seccomp等)が採られているか。 - KEP-4671が示唆する「DRAリソースをブロックする `Reservation` オブジェクト」は、DRAの `ResourceClaim` とどう統合されるか。将来KEPが具体化した時点でDRA・ギャングスケジューリング双方のconceptを更新する必要がある。 ## 関連 - ソース: [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]] / [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]] - エンティティ: [[Kubernetes]] / [[Patrick Ohly]] / [[Intel]] - 概念: [[GPU多重化(MPS・MIG)]] / [[コンテナオーケストレーション]] / [[GPUクラスタスケジューリング]] / [[Kubernetes Workload・PodGroup API]] ## 出典 - [[@2024__KEP__KEP-4381 Dynamic Resource Allocation with Structured Parameters]](KEP全文。API・スケジューラ拡張点・GA条件・代替案) - [[@2025__KEP__KEP-4671 Gang Scheduling using Workload Object]](DRAブロッキングとの未解決の接続点、`Reservation` オブジェクトの示唆)