Kubernetes 1.34でGA（一般提供）に到達し、1.35でフィーチャーゲートがロックされたDynamic Resource Allocation（DRA）。GPU・FPGA・カスタムアクセラレータといった「CPU/メモリ以外のリソース」を、Kubernetesネイティブに宣言的管理する仕組みが、ついに本番運用の標準となった。本記事では、DRAの技術的背景、従来のDevice Pluginフレームワークとの決別、そしてAI/MLワークロード時代のリソース設計がどう変わるかを解析する。

DRAとは何か ── 「数を数えるだけ」の時代の終わり

従来のKubernetesにおけるGPU管理は、Device Pluginフレームワークに依存していた。2017年にKubernetes 1.8で導入されたこの仕組みは、ノード上のデバイスを「カウントベース」で管理する。Podはnvidia.com/gpu: 2のように数量を指定するだけで、どのGPUか、どんな属性を持つかは指定できない。

この設計は、GPUが「あれば十分」だった時代には機能した。しかし、AI/MLワークロードが爆発的に増加した2024年以降、その限界は明白になっている。LLMの分散学習では特定のNVLink接続トポロジを持つGPUペアが必要であり、推論ワークロードではVRAM容量による選別が不可欠である。Device Pluginの「カウントベース」モデルでは、こうした属性ベースの要求に応えられない。

DRA（Dynamic Resource Allocation）は、この根本的な制約を打破するために設計された。PersistentVolumeClaimがストレージを抽象化したように、ResourceClaimがGPUやアクセラレータを抽象化する。ただし、ストレージよりはるかに複雑な属性ベースのフィルタリングをCEL（Common Expression Language）式でサポートする点が決定的に異なる。

KEP-3063からKEP-4381へ ── アーキテクチャの根本的転換

DRAの歴史は、一度の大きな失敗と、それを乗り越えた再設計の物語である。

2022年12月、Kubernetes 1.26でKEP-3063として最初のDRAアルファが導入された。このバージョンは「コントローラベースモデル」と呼ばれ、スケジューラとデバイスドライバ間でPodSchedulingContextオブジェクトを介した逐次的なやりとりを必要とした。スケジューラがノード候補を提示し、ドライバがノード除外リストを返し、スケジューラが最終決定し、ドライバがリソースを割り当てる——この多段階のプロセスは、Podスケジューリングのレイテンシを増大させた。

しかし、致命的だったのはCluster Autoscalerとの非互換性である。コントローラベースモデルでは、リソース割り当てがドライバのブラックボックス内で行われるため、Autoscalerが「このResourceClaimは満たせるか？」を事前にシミュレーションできなかった。クラウドネイティブ環境で最も重要なオートスケーリングが機能しないDRAは、本番投入不可能だった。

この教訓から生まれたのがKEP-4381「Structured Parameters」モデルである。2024年のKubernetes 1.30-1.31でアルファとして導入され、1.32でベータに昇格すると同時に、旧KEP-3063は完全に削除された。構造化パラメータモデルでは、デバイスドライバがResourceSliceオブジェクトを通じてデバイスの属性（VRAM容量、ドライババージョン、トポロジ情報など）をクラスタ全体に公開する。スケジューラは、ドライバに問い合わせることなく、ResourceSliceの情報だけでリソース割り当てをシミュレーションできる。

筆者はこれまで多種多様なインフラ設計に携わってきたが、アーキテクチャの問題は個別の最適化では超えられないという教訓を何度も得てきた。DRAにおけるKEP-3063からKEP-4381への転換は、まさにそのパターンの典型である。スケジューリングのボトルネックをドライバ側のパフォーマンス改善で解決しようとするのではなく、「スケジューラが自律的に判断できる」というアーキテクチャ自体を再設計したのだ。

4つのAPIオブジェクト ── DRAの設計思想

DRAはresource.k8s.io/v1 APIグループに属する4つの主要オブジェクトで構成される。

ResourceClaimは、PersistentVolumeClaim（PVC）に相当するオブジェクトである。Podが必要とするデバイスリソースを宣言的に定義する。CEL式による属性フィルタリング（例:「VRAM 16GB以上でNVIDIAドライバv550以上のGPU」）が可能であり、これがDevice Pluginとの最大の差異である。

ResourceClaimTemplateは、PVCテンプレートのように、Pod単位でResourceClaimを自動生成する。Podの終了とともにClaimも削除されるため、ステートレスなAI推論ワークロードに適している。

DeviceClassは、StorageClassに相当する管理者向けオブジェクトである。クラスタ管理者がデバイスのカテゴリ（例:「学習用GPU」「推論用GPU」「FPGA」）を定義し、使用可能なドライバやパラメータ制約を指定する。ワークロード開発者はDeviceClassを参照するだけで、インフラの詳細を知る必要がない。

ResourceSliceは、デバイスドライバがノード上の利用可能デバイスをクラスタに広告するオブジェクトである。各デバイスの属性（メモリ容量、コンピュート能力、パーティション状態など）を構造化データとして公開する。スケジューラはこのResourceSliceを読み取り、ドライバへの問い合わせなしにリソース割り当てを判断する。

この4オブジェクトモデルは、「関心の分離」を徹底している。インフラチームはDeviceClassとResourceSliceで物理リソースを管理し、ワークロード開発者はResourceClaimで論理的な要求を宣言する。これはKubernetesのStorageClass/PVC/PVパターンの正統な拡張であり、運用チームにとって学習コストが低い。

GPU時代のリソース設計 ── 「ゴールデンシグナル」の再定義

Kubernetesのリソース管理は、長年にわたりCPU requestsとmemory limitsの2軸を中心に設計されてきた。HPA（Horizontal Pod Autoscaler）のスケーリング閾値、VPA（Vertical Pod Autoscaler）の推奨値、Cluster Autoscalerのノードプロビジョニング判断——すべてがCPU/メモリを「ゴールデンシグナル」として機能してきた。

AI/MLワークロードは、この前提を根底から覆す。LLMの推論レイテンシはCPU使用率ではなくGPU SM（Streaming Multiprocessor）稼働率で決まる。学習ジョブのスループットはメモリ帯域ではなくGPU間通信（NVLink/NVSwitch）のトポロジで決まる。DRAの登場により、これらの指標をKubernetesネイティブに扱えるようになった。

具体的な設計変更を見てみよう。従来のDevice Plugin環境では、GPUリソースのミスアラインメント（不適切な割り当て）が頻発していた。ベンチマークによれば、リソースが適切にアラインされていない場合、スループットは最適時の71%まで低下し、最悪ケースでは40%の効率にまで落ち込むと報告されている。DRAの属性ベースフィルタリングにより、トポロジ整合性を保証した割り当てが可能になり、GPU稼働率は約30%から約60%へと倍増する見込みである。

全国規模のインフラ運用に携わった経験から言えば、「止められない」という制約が技術的判断の全てを支配する環境では、リソースの適切な割り当ては性能だけでなく可用性の問題でもある。GPUリソースのミスアラインメントは、単にスループットが落ちるだけでなく、OOM（Out of Memory）によるPodクラッシュやノード全体の不安定化を引き起こす。DRAによる宣言的なリソース管理は、この種の運用リスクを構造的に排除する。

GPUベンダーの実装状況と実践的移行ガイド

2026年2月時点で、主要GPUベンダーのDRAドライバ実装状況には明確な差がある。

NVIDIAは最も成熟したDRAドライバを提供している。NVIDIA/k8s-dra-driver-gpuリポジトリで公開されているドライバは、GPU Operatorとの統合、MIG（Multi-Instance GPU）パーティションの動的割り当て、ComputeDomainsサポートを備え、本番環境での運用に耐えるレベルに達している。NVIDIAドライバ580以上とCDI（Container Device Interface）サポートが前提条件である。

AMDは、ROCm/k8s-gpu-dra-driverとして実験的なDRAドライバを公開している。CEL式による属性ベースGPU選択、パーティショニング、コンテナ間共有をサポートするが、2026年2月時点では本番運用は推奨されていない。ROCmエコシステムとの統合は進行中である。

Intelは、Intel Device Plugins for Kubernetesの一部として統合GPU（iGPU）向けのDRAリソースドライバを提供している。Kubernetes 1.32以上とCDI対応のcontainerdが必要で、主に統合GPU向けの機能に限定されている。

実践的な移行では、以下の段階的アプローチを推奨する。まず、Device Pluginとの共存期間を設ける。DRAは既存のDevice Pluginを即座に置き換えるものではなく、新規ワークロードからDRAベースのResourceClaimを導入し、既存ワークロードは段階的に移行する。次に、DeviceClassの設計が重要である。学習用と推論用でDeviceClassを分離し、属性制約を明確に定義する。最後に、ResourceSliceのモニタリング体制を整備する。Kubernetes PodResources APIを通じてDRAリソースの監視が可能であり、Prometheus/Grafanaとの統合によりGPU割り当て状況をリアルタイムに可視化できる。

DRAがもたらすパラダイムシフト ── CPU/メモリ中心設計の終焉

DRAのGA到達は、単なるAPI追加ではない。Kubernetesのリソースモデルにおける根本的なパラダイムシフトである。

第一に、Cluster Autoscalerとの統合が実現した。構造化パラメータモデルにより、Autoscalerが「このPendingなPodのResourceClaimを満たすには、どのノードプールをスケールアウトすべきか」をドライバに問い合わせることなく判断できる。AWS EKS、Google GKE、Azure AKSの主要クラウドプロバイダがDRAをサポートしており、クラウドネイティブなGPUオートスケーリングが現実のものとなった。

第二に、マルチテナントGPU共有が宣言的に管理可能になった。Kubernetes 1.34で導入されたAdmin Access Labeling機能により、Namespace単位でのGPUアクセス制御が実現している。resource.k8s.io/admin-access: "true"ラベルを使用することで、高権限のリソースClaimを特定のNamespaceに限定できる。

第三に、Kubernetes 1.35で追加されたConsumable Capacity、Partitionable Devices、Device Taintsにより、GPUのオーバーサブスクリプション管理やパーティション制御が可能になった。これは、GPU利用率の最適化とコスト削減に直結する機能である。

筆者がフルスタックエンジニアとしてさまざまなインフラ技術を横断してきた経験から言えば、技術選定においてバイアスなく最適解を選ぶには、抽象化レイヤーの設計思想を理解することが不可欠である。DRAは「GPUを管理する機能」ではなく「リソースモデル自体の拡張フレームワーク」として設計されている。FPGA、DPU、量子プロセッサ——今後登場するあらゆるアクセラレータが、同じResourceClaim/DeviceClassパターンで管理される未来が見えている。

CPU/メモリ中心のリソース設計は、2024年にはすでに限界を迎えていた。DRAのGA到達は、その事実をKubernetesコミュニティが公式に認め、新しい時代への移行を完了したことを意味する。AI/MLワークロードの爆発的増加を背景に、2026年以降のKubernetesクラスタ設計は、DRAを前提としたアクセラレータファーストのリソースモデルが標準となるだろう。

FAQ

DRAとDevice Pluginの違いは何か？

Device Pluginはデバイスを「数量」でしか指定できないカウントベースモデルである。DRAはCEL式で属性（VRAM容量、ドライババージョン、トポロジ等）を指定でき、デバイス共有やCluster Autoscalerとの統合もサポートする。

DRAを使うにはKubernetesのバージョンをいくつ以上にすればよいか？

本番運用にはKubernetes 1.34以上を推奨する。1.34でDRAコアがGA（一般提供）に到達し、デフォルトで有効化されている。1.35ではフィーチャーゲートがロックされ無効化できなくなった。

NVIDIAのGPU以外でもDRAは使えるか？

使える。AMDは実験的ドライバを、Intelは統合GPU向けドライバを公開している。DRAはベンダー中立なフレームワークであり、FPGA・DPU等の任意のデバイスに対応可能な設計である。

既存のDevice Pluginベースのワークロードはすぐに移行が必要か？

即座の移行は不要である。DRAとDevice Pluginは共存可能であり、新規ワークロードからDRAに移行し、既存ワークロードは段階的に切り替える戦略が推奨される。

DRAによりGPUのコスト効率はどの程度改善されるか？

ベンチマークによれば、属性ベースの適切なリソースアラインメントにより、GPU稼働率は約30%から約60%へ倍増すると報告されている。トポロジ整合性の保証によりスループットが最大40%改善されるケースもある。

参考文献