Microsoft、AKSにDRA対応のNVIDIA vGPUサポートを追加
本文の状態
日本語全文を表示中
詳細モードで約6分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
InfoQ
MicrosoftのAzure Kubernetes Serviceチームが、AKSでDynamic Resource Allocation（DRA）とNVIDIA vGPU技術を連携させる詳細ガイドを公開した。この更新により、AIやメディア処理における共有GPU利用の制御性と効率性が向上する。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Azure Kubernetes Service チームは、AKS で NVIDIA vGPU テクノロジーと Dynamic Resource Allocation (DRA) を使用する方法に関する詳細なガイドを共有しました。この更新により、AI およびメディアタスクにおける共有 GPU 利用の制御性と効率性が向上します。
Dynamic Resource Allocation (DRA) は現在、Kubernetes における GPU リソース利用の標準となっています。nvidia.com/gpu などの静的リソースに代わり、DeviceClasses と ResourceClaims を用いて GPU が動的に割り当てられます。この変更によりスケジューリングが強化され、NVIDIA vGPU などの仮想化技術との統合が改善されます。
これらの技術を組み合わせる理由は明確です。NVIDIA vGPU などの仮想アクセラレータは、多くの場合小規模なタスクを処理します。これにより、1 つの物理 GPU を多数のユーザーやアプリケーション間で分割して使用することが可能になります。この構成は、エンタープライズ向けの AI/ML 開発、ファインチューニング、音声・映像処理において有益です。vGPU はコンテナ化されたワークロードに CUDA の機能を提供しつつも、予測可能なパフォーマンスを実現します。
インフラストラクチャ側では、この機能は Azure の NVadsA10_v5 仮想マシンシリーズに依存しています。GPU を 1 つの VM に完全に割り当てるのではなく、vGPU テクノロジーによりハイパーバイザ層で複数の固定サイズのスライスに分割されます。Kubernetes の視点からは、各 VM は明確な GPU デバイスを 1 つ持つことになります。容量とメモリの制限はソフトウェアではなく、ハイパーバイザによって設定されます。
セットアップには Kubernetes 1.34 以降が必要です。現時点では、deviceclasses や resourceslices といった DRA プリミティブが利用可能です。チームは NVadsA10_v5 インスタンスを持つノードプールをプロビジョニングし、NVIDIA DRA kubelet プラグインのノードセレクターとしてラベル (nvidia.com/gpu.present=true) を適用します。その後、Helm を経由して NVIDIA DRA ドライバーを展開します。この投稿では、vGPU シナリオにおける 3 つの重要な Helm フラグが強調されています。gpuResourcesEnabledOverride=true というフラグは、異なる GPU 名のためにレガシーデバイスプラグインとの併用インストールを防止するチェックをスキップします。FeatureGates.IMEXDaemonsWithDNSNames=false は、Azure の A10 シリーズでサポートされているバージョンよりも新しい GRID ドライバーバージョンを必要とする IMEX 機能を無効化します。
ドライバーがアクティブになると、各ノードをスキャンして Azure VM から単一の vGPU デバイスを検出し、それを DRA 管理デバイスとして Kubernetes コントロールプレーンに登録します。各ノードは VM が提示するものに応じて、1 つの割り当て可能なデバイスを登録します。オペレーターは gpu.nvidia.com DeviceClass や ResourceSlices を確認することでセットアップを検証できます。これにより、コントロールプレーンが利用可能なハードウェアを検出したことを確認できます。
ベースラインとなる 1/6 スライス（Standard_NV6ads_A10_v5）に加え、このシリーズではアクセラレータメモリ 8 GB を備えた 1/3 プロファイルと、12 GB の 1/2 プロファイルも提供されています。制限はハイパーバイザ層で enforced されるため、AKS は予測可能な容量を持つ単一の GPU デバイスとして認識します。これにより、プラットフォームチームはノードの過剰プロビジョニングを行わずに、ワークロードの要件に基づいて GPU の割り当てサイズを柔軟に調整できます。
AKS チームは、この機能のより広範な意義を方向性として捉えています。GPU が Kubernetes においてファーストクラスのリソースとなる中で、仮想化された vGPU と DRA（Device Resource Allocation）を組み合わせることで、共有型かつ本番環境グレードのワークロードを実行する実用的な手段が得られます。大規模な AKS デプロイメント、特に規制産業やコスト敏感な業界においては、最適な GPU の配置と利用率がジョスのスループットとインフラ効率に直接影響を及ぼします。vGPU と DRA を併用することで、組織は粗いノードレベルの割り当てから、大規模かつ制御されたワークロード駆動型の GPU 利用へと移行することが可能になります。
Google Cloud は GKE においても同様の道筋をたどっており、GPU と TPU の両方に対するスケジューリングの基礎要素として DRA に注力しています。GKE の DRA サポートにより、ワークロードは CEL 式を使用して特定の属性を持つデバイスをフィルタリングできます。これにより、異なる GPU タイプを備えた複数のクラスターに対して、変更を加えることなく単一のマニフェストからデプロイが可能になります。特に vGPU に関しては、Google は最近、GKE を介して管理され、コンテナのビンパッキングと組み合わせてより高い利用率を実現する、RTX PRO 6000 Blackwell GPU に基づく NVIDIA vGPU テクノロジーを活用した断片的な G4 VM のプレビューを発表しました。Google の動的ワークロードスケジューラ（Dynamic Workload Scheduler）を介してスケジュールされる場合、フォールバック優先順位によりリソースへのアクセスが改善されます。
Amazon EKS は異なるアプローチを採用しており、DRA を主に高価な GPU ハードウェアの複雑さを簡素化するために使用し、断片化された共有のためには使用していません。Amazon EKS では、Kubernetes バージョン 1.33 から DRA が一般提供されました。この技術は、P6e-GB200 UltraServer インスタンスにおいて不可欠です。これらのインスタンスでは、従来の静的 GPU スケジューリングでは、マルチノードワークロードに必要な NVLink や IMEX 相互接続をモデル化することができません。EKS でより小規模なワークロードを実行し、GPU の共有を望むチームにとって、DRA は now、構造化された属性ベースのリクエストをサポートするようになりました。これにより、スケジューラーは「計算能力が少なくとも 1/7 分の 10 GB の MIG パーティション」といったリクエストに応答できるようになり、GPU を単なるカウントとして扱う必要がなくなります。3 つの主要クラウドプロバイダーすべてにおいて、静的デバイスプラグインから DRA への移行が加速しています。これは、AI インフラストラクチャの複雑さとコストが増大する中で、より表現力豊かでトポロジー認識型の GPU スケジューリングが必要とされていることによるものです。
About the Author
Claudio Masolo
Claudio は Nearform のシニア DevOps エンジニアです。趣味はランニング、読書、そして古いビデオゲームをプレイすることです。
原文を表示
The Azure Kubernetes Service team shared a detailed guide on how to use Dynamic Resource Allocation (DRA) with NVIDIA vGPU technology on AKS. This update improves control and efficiency for shared GPU use in AI and media tasks.
Dynamic Resource Allocation (DRA) is now the standard for GPU resource use in Kubernetes. Instead of static resources like nvidia.com/gpu, GPUs are allocated dynamically using DeviceClasses and ResourceClaims. This change enhances scheduling and improves integration with virtualization technologies like NVIDIA vGPU.
The reason for combining these technologies is clear: virtual accelerators like NVIDIA vGPU often handle smaller tasks. They allow one physical GPU to be split among many users or applications. This setup is helpful for enterprise AI/ML development, fine-tuning, and audio/visual processing. vGPU offers predictable performance while still providing CUDA capabilities to containerized workloads.
On the infrastructure side, this feature relies on Azure's NVadsA10_v5 virtual machine series. Instead of assigning the whole GPU to one VM, vGPU technology partitions it into multiple fixed-size slices at the hypervisor layer. From Kubernetes' view, each VM shows one clear GPU device. The hypervisor sets capacity and memory limits, not the software.
The setup requires Kubernetes 1.34 or newer. At this point, DRA primitives like deviceclasses and resourceslices are available. Teams provision a node pool with NVadsA10_v5 instances and apply a label (nvidia.com/gpu.present=true) for the NVIDIA DRA kubelet plugin as its node selector. They then deploy the NVIDIA DRA driver via Helm. The post highlights three important Helm flags for vGPU scenarios. The gpuResourcesEnabledOverride=true flag skips a check that prevents the NVIDIA DRA driver from installing with the legacy device plugin due to different GPU names. FeatureGates.IMEXDaemonsWithDNSNames=false disables an IMEX feature that requires a newer GRID driver version than what's supported on the A10 series in Azure.
Once the driver is active, it scans each node, detects the single vGPU device from the Azure VM, and registers it to the Kubernetes control plane as a DRA-managed device. Each node registers one allocatable device because that’s what the VM presents. Operators can check the setup by looking at the gpu.nvidia.com DeviceClass and ResourceSlices. This way, they can confirm that the control plane has found the available hardware.
Beyond the baseline one-sixth slice (Standard_NV6ads_A10_v5), the series offers a one-third profile with 8 GB of accelerator memory and a one-half profile with 12 GB. Limits are enforced at the hypervisor layer, so AKS sees a single GPU device with predictable capacity. This gives platform teams flexibility to size GPU allocation based on workload needs without overprovisioning nodes.
The AKS team frames the broader significance as directional. As GPUs become first-class resources in Kubernetes, combining virtualized GPU with DRA offers a practical way to run shared, production-grade workloads. For large AKS deployments, especially in regulated or cost-sensitive industries, optimal GPU placement and utilization directly impact job throughput and infrastructure efficiency. Using DRA with vGPU helps organizations move from coarse node-level allocation to controlled, workload-driven GPU use at scale.
Google Cloud is pursuing a similar path on GKE, focusing on DRA as a scheduling primitive for both GPUs and TPUs. GKE's DRA support lets workloads use CEL expressions to filter devices with specific attributes. This allows a single manifest to deploy to different clusters with various GPU types without changes. Specifically for vGPU, Google recently previewed fractional G4 VMs using NVIDIA vGPU technology based on the RTX PRO 6000 Blackwell GPU, managed through GKE and combined with container binpacking for higher utilization. When scheduled via Google's Dynamic Workload Scheduler, fallback priorities can improve resource access.
Amazon EKS takes a different approach, using DRA mainly to simplify the complexity of its high-end GPU hardware instead of fractional sharing. Amazon EKS made DRA generally available starting in Kubernetes version 1.33. This technology is essential for P6e-GB200 UltraServer instances, where traditional static GPU scheduling cannot model the NVLink and IMEX interconnect needed for multi-node workloads. For teams running smaller workloads wanting GPU sharing on EKS, DRA now supports structured, attribute-based requests. This allows schedulers to respond to requests like "a 10 GB MIG partition with at least 1/7th compute" instead of treating GPUs as simple counts. Across all three cloud providers, the shift from static device plugins to DRA is accelerating, driven by the need for more expressive, topology-aware GPU scheduling as AI infrastructure grows in complexity and cost.
About the Author
Claudio Masolo
Claudio is a Senior DevOps Engineer at Nearform.
In his spare time, he likes running, reading, and playing old video games.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み