はじめに

Kubernetesが長らく前提としてきたリソースモデルは、とてもシンプルなものでした。Podは「CPU時間」と「メモリ量」を要求し、スケジューラはそれを満たすノードを選ぶ。この抽象化は美しく、10年近くにわたって膨大なワークロードを支えてきました。

しかし、AI・エッジ・通信（Telco）といった領域のワークロードが本格的に載り始めると、この二次元のモデルでは足りない場面が急速に増えました。GPUを1枚まるごと欲しいのか、それとも分割された一部で足りるのか。特定のインターコネクトで結ばれたアクセラレータ同士を組にして確保したいのか。ネットワークインターフェースやFPGAはどう扱うのか——CPUとメモリだけでは表現できない要求が、当たり前に現れるようになったわけです。

2026年6月24日にKubernetes Blogで公開された「Spotlight on WG Device Management」は、まさにこの課題に取り組んできたワーキンググループの歩みを紹介する記事です。本稿ではこのスポットライト記事を起点に、Dynamic Resource Allocation（DRA）が何を解決するのか、どのような経緯で再設計されたのか、そして実務でクラスタに入れるときに何を確認すべきかを整理します。

なお本稿では、公式ページで確認できた内容と、確認できなかった内容を明確に分けて書きます。裏が取れていない項目については推測で埋めず、「未確認」と明記します。

WG Device Managementとは何をしている集まりなのか

WG Device Management（デバイス管理ワーキンググループ）は、Kubernetesにおける特殊ハードウェアの扱いを設計・実装するために作られた横断組織です。スポットライト記事によれば、共同議長（co-chair）は次の3名です。

  • Kevin Klues — NVIDIAのDistinguished Engineer。2019年からkubeletのメンテナを務めています
  • Patrick Ohly — IntelのPrincipal Engineer。SIG TestingおよびSIG Instrumentationのテックリードでもあります
  • John Belamaric — GoogleのSenior Staff Software Engineer。2019年からSIG Architectureの共同議長を務めています

ワーキンググループという形態が選ばれた理由は、この問題が単一のSIGに閉じないからです。デバイスの割り当てはスケジューラの領域であり、ノード上での実際の払い出しはkubeletの領域であり、APIの形はSIG Architectureのレビュー対象になります。さらにkubeletのdevice manager、CPU manager、topology managerといった既存コンポーネントとも整合を取る必要があります。スポットライト記事では、KubeCon Paris（2024年）の後にWGが立ち上がり、こうした関係者のコラボレーションを促す場として機能してきたことが述べられています。

WGが向き合っている技術的な難しさとして、記事では以下の点が挙げられています。

  • CPU時間とメモリ割り当てだけでは、現代のワークロードの要求を表現できないこと
  • GPU・TPU・ネットワークインターフェースといったデバイスの割り当てが必要なこと
  • Pod起動後の割り当て（post-pod-start allocation）への対応
  • ハードウェアリソースの時分割共有（time-sharing）への対応
  • ハードウェアを考慮した配置問題が本質的にNP困難であること

最後の点は運用者として意識しておく価値があります。「どのノードのどのデバイスをどの組み合わせで割り当てるか」という問題は、制約が増えるほど組合せ爆発を起こします。DRAの設計判断の多くは、この計算量とどう折り合いをつけるかという観点から理解すると腑に落ちます。

Classic DRAから構造化パラメータへ：なぜ作り直したのか

DRAの歴史は一直線ではありません。スポットライト記事は、大きく2つのフェーズがあったと整理しています。

第1フェーズ「Classic DRA」（2020〜2023年ごろ） は、Patrick Ohlyが書いた最初のKEPに基づく実装です。Kubernetes 1.26でアルファAPIとして登場しました。この設計では、デバイスの割り当て判断をベンダー提供のドライバ側に大きく委ねる形になっていました。柔軟ではあるものの、致命的な副作用がありました——クラスタオートスケーラが「このPodを起動するには、どんなノードを追加すればよいか」を判断できなくなるのです。スケジューリングの決定が不透明なブラックボックスの中にあるため、外部から結果を予測できません。この点はコミュニティ内で懸念となり、ベータ昇格に進むことへの疑問が上がりました。

第2フェーズ「Structured Parameters DRA」（2023〜2026年） は、この問題を受けた全面的な再設計です。新しいKEPが書き直され、Kevin Klues、Patrick Ohly、John Belamaric、そしてTim Hockinらの間で合意形成が行われたと記事には記されています。

この再設計の肝は、デバイスの情報とその選択ロジックを、Kubernetesが理解できる構造化されたデータとしてAPIに載せたことです。ドライバは「自分が管理しているデバイスはこれで、こういう属性を持つ」という情報をAPIに公開し、実際に「どれを割り当てるか」を決めるのはKubernetesのスケジューラ側になります。結果として、オートスケーラのようなコンポーネントも同じ情報を見て判断できるようになりました。

そしてスポットライト記事の時点で、DRAは GA（Generally Available）に到達しています。記事から辿れるリリース記事のタイトルによれば、GA昇格はKubernetes v1.34（2025年9月）です。アルファ登場のv1.26から数えると、およそ3年をかけた道のりということになります。

DRAを構成する4つのオブジェクト

公式ドキュメント「Dynamic Resource Allocation」によれば、DRAのコアAPIは resource.k8s.io グループに属し、次の4つのオブジェクトで構成されます。

オブジェクト 役割 主に扱う人
DeviceClass デバイスのカテゴリと選択条件を定義する。CEL式でデバイス属性による絞り込みを書ける クラスタ管理者
ResourceClaim 具体的なデバイスの要求。Podから参照される ワークロード担当者
ResourceClaimTemplate Podごとに個別のResourceClaimを自動生成するためのテンプレート ワークロード担当者
ResourceSlice ノードに接続されているデバイスの実体情報。ドライバが公開する デバイスドライバ

役割分担のイメージはこうです。まずデバイスドライバがノード上のハードウェアを検出し、ResourceSliceとしてAPIサーバに公開します。クラスタ管理者はDeviceClassを定義し、「accelerators と言えばこの条件に合致するデバイス群を指す」という語彙をクラスタ利用者に提供します。利用者はResourceClaimまたはResourceClaimTemplateでDeviceClassを指定してデバイスを要求し、Podの spec.resourceClaims からそれを参照します。スケジューラはResourceSliceの情報を見て割り当て可能なノードを選び、kubeletがドライバ経由で実際の払い出しを行います。

PersistentVolumeClaimとStorageClassの関係を知っていれば、構造の親近感は強いはずです。DeviceClassがStorageClassに、ResourceClaimがPVCに、ResourceSliceが実ボリュームに相当する、と考えると全体像を掴みやすいでしょう。

なお、ResourceClaimやResourceClaimTemplateの具体的なフィールド名（spec.devices.requests[] の構造や allocationMode、count の指定方法など）は、APIのバージョンによって変化してきた部分です。本稿では実際のマニフェスト例を掲載しませんが、これは意図的なものです。導入時は必ず、対象クラスタのバージョンに対応する ResourceClaim APIリファレンス を参照してください。ブログ記事のサンプルをコピーして動かない、という事故が起きやすい領域です。

GA後も広がり続ける機能群

DRAがGAになったことは「完成した」という意味ではありません。むしろコアが安定したことで、その上に載る機能の開発が加速しています。スポットライト記事では、以下の機能名が挙げられています。

  • DRA core — 基本的な割り当て機能。GA済み
  • Admin access — 管理者がデバイスへ特権的にアクセスするための仕組み。診断やメンテナンス用途を想定したものです
  • Prioritized alternatives（優先順位付きの代替）— 「大容量GPUが1枚欲しい、なければ小容量2枚でもよい」といった要求を、優先順位付きの候補リストとして表現できます
  • Partitionable devices（分割可能デバイス）— 1つの物理デバイスを複数の論理デバイスに分割し、それぞれ独立に割り当てる仕組みです。NVIDIAのMIGのような機能を素直に表現できます
  • Device taints/tolerations — ノードのtaint/tolerationと同じ考え方をデバイス単位に適用するものです。故障の疑いがあるデバイスや、特定用途に予約したいデバイスを、通常のワークロードから隔離できます
  • Consumable capacity（消費可能キャパシティ）— デバイスを排他的に占有するのではなく、容量の一部を複数のワークロードで分け合う形での割り当てです
  • Extended resource mapping — 従来のextended resource（nvidia.com/gpu のような記法）による要求を、DRAの仕組みにマッピングするものです。既存マニフェストを書き換えずに移行を進められる点で、移行戦略上とても重要な機能です

これらの機能はそれぞれフィーチャーゲートで制御されます。ドキュメント上は DRAAdminAccess、DRAPrioritizedList、DRAPartitionableDevice、DRADeviceTaints、DRAConsumableCapacity、DRAExtendedResource、DRAResourceClaimDeviceStatus といったゲート名が使われています。

ただし、それぞれのゲートがどのバージョンでアルファ／ベータ／GAのどの段階にあるかは、リリースごとに動きます。本稿執筆時点でバージョンごとの正確な対応表を一次情報から確定できなかったため、この点は未確認とします。実際に有効化する際は、公式の Feature Gates ページで、対象バージョンにおける段階とデフォルト値を必ず確認してください。

また、v1.34では「Pods Report DRA Resource Health」という機能も追加されています。割り当てられたデバイスの健全性がPodのステータスから見えるようになるもので、運用視点では非常にありがたい追加です。GPUが壊れているのにPodがRunningのまま無言で失敗し続ける、という状況を減らせます。

導入・移行時の注意点

ここからは、実際にDRAをクラスタへ入れる立場で押さえておきたい点を挙げます。

1. ドライバ側の対応が前提になります。 DRAはKubernetes単体では機能しません。ResourceSliceを公開するDRA対応ドライバがベンダーから提供されている必要があります。DRAのコアがGAであることと、手元のハードウェアのドライバが本番運用に耐える成熟度であることは、まったく別の話です。導入判断の最初のステップは、Kubernetesのバージョン確認ではなく、使っているアクセラレータのDRAドライバの状況確認です。

2. Device Pluginからの移行は段階的に進めてください。 従来のDevice Plugin方式は引き続き動作します。いきなり全面移行するのではなく、まず新規のワークロードや検証環境でDRAを使い、既存のものはextended resource mappingのような橋渡し機能の成熟を待つ、という進め方が現実的です。両方式が同じデバイスを同時に管理しようとした場合の挙動には注意が必要で、この点の詳細な制約は公式ドキュメントで確認してください（本稿では未確認とします）。

3. ResourceClaimは名前空間スコープです。 ResourceClaimはPodと同じ名前空間に存在する必要があります。マルチテナント環境では、名前空間ごとのResourceQuotaやRBACの設計と合わせて考える必要があります。特にAdmin accessのような特権的な機能は、誰が使えるのかをRBACで明確に制限しておくべきです。

4. スケジューリングの挙動が変わることを想定してください。 DRAではスケジューラが割り当て可能なデバイスを探索するため、Pending状態のPodのイベントメッセージやトラブルシューティングの手順が従来と変わります。「なぜこのPodがスケジュールされないのか」を調べる導線を、ResourceClaimのstatusとResourceSliceの内容まで含めて事前に整理しておくと、障害時に慌てずに済みます。

5. アルファ機能の有効化は本番と検証で分けてください。 上に挙げた新機能の多くは、まだアルファまたはベータの段階にあります。アルファ機能はデフォルト無効であり、リリース間で非互換な変更が入り得ます。魅力的な機能ほど、まず検証クラスタで試す規律が要ります。

6. コミュニティへの参加窓口について。 スポットライト記事は、WGの活動に参加するための入口として kubernetes.dev のWGページ を案内しています。ただし、定例ミーティングの具体的な時刻、Slackチャンネル名、メーリングリストのアドレスについては、本稿執筆時点で当該ページの内容を直接確認できていないため未確認とします。参加を検討する場合は、上記のWGページから最新情報を取得してください。

まとめ

WG Device Managementの歩みは、Kubernetesがどのように大きな設計変更を扱うかの好例になっています。Classic DRAでいったんアルファまで進めたものを、オートスケーリングとの相性という本質的な問題を理由に作り直し、構造化パラメータという形で合意を取り直してGAまで運んだ——この判断には3年近い時間がかかりましたが、結果としてスケジューラもオートスケーラも同じ情報を見て判断できる、筋の通ったモデルが手に入りました。

実務者としての要点を3つに絞ると、次のようになります。

  1. DRAのコアはGA（v1.34）に到達しており、GPU等の割り当ては「将来の話」ではなく「今の選択肢」になりました。 ただし本番投入の可否を決めるのは、Kubernetesのバージョンよりもベンダードライバの成熟度です
  2. DeviceClass / ResourceClaim / ResourceClaimTemplate / ResourceSlice の4オブジェクトと、その役割分担を先に理解してください。 StorageClassとPVCのアナロジーが有効です
  3. 周辺機能の多くはまだアルファ・ベータです。 フィーチャーゲートの段階は必ず対象バージョンの公式ドキュメントで確認し、アルファ機能は検証環境から始めてください

AIワークロードをKubernetesに載せる流れは当面続きます。その基盤としてDRAを理解しておくことは、これから数年の運用設計において確実に効いてくるはずです。

参考資料