GPU に関する Azure Kubernetes Service (AKS) のためのベストプラクティス

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

AKS で GPU ワークロードを実行するには、コンピューティングリソースにアクセスでき、セキュリティで保護され、最適に利用されるように、適切なセットアップと継続的な検証が必要です。この記事では、GPU 対応ノードの管理、構成の検証、ワークロードの中断の削減に関するベストプラクティスについて説明します。

ほとんどの運用環境の AKS ワークロードでは、AKS Automatic が推奨される既定値です。 AKS Automatic は、構成済みの運用、セキュリティ保護、SLA に基づくポッド対応性を備えた運用対応のベースラインを提供し、チームが 2 日目のプラットフォームのオーバーヘッドを削減するのに役立ちます。

GPU ワークロードに対して AKS Automatic または AKS Standard を選択する

開始点として、次のガイダンスを使用します。

シナリオ	推奨パス	なぜでしょうか
ほとんどの実稼働 GPU ワークロード	AKS Automatic	運用環境対応の既定値、組み込みのセーフガード、クラスター操作のオーバーヘッドの削減。
デプロイから安定した運用へのより高速なパス	AKS Automatic	事前構成済みのクラスター操作と、ポッドの準備 SLA による予測可能なスタートアップ動作。
高度なプラットフォームのカスタマイズと明示的な運用制御	AKS Standard	カスタムノードプールのライフサイクルとプラットフォームのチューニングの柔軟性が向上しました。
特殊化された既定以外のプラットフォームアーキテクチャの要件	AKS Standard	インフラストラクチャの動作と構成をより手動で制御できます。

詳細については、「Azure Kubernetes Service (AKS) Automatic の概要」を参照してください。

AKS Automatic が運用環境の GPU ワークロードに提供するもの

AKS Automatic は、次の機能を提供することで、運用 GPU ワークロードの強力な運用ベースラインを確立するのに役立ちます。

クラスター構成の運用環境対応の既定値。
組み込みのベストプラクティスとセーフガード。
予測可能な起動動作を実現する、SLA で保証された Pod のレディネス。
手動の 2 日目のタスクを削減するマネージドクラスター操作。

これらのプラットフォームの既定値は、この記事で説明されている配置制御、検証チェック、分離ポリシーなどのワークロードレベルのベストプラクティスに代わるものではありません。

AI モデルトレーニング、リアルタイム推論、シミュレーション、ビデオ処理などの GPU ワークロードは、多くの場合、次に依存します。

GPU ドライバーが適切で、ランタイムに互換性がある。
GPU リソースのスケジュールが正確に設定されている。
コンテナー内で GPU ハードウェアデバイスにアクセスできる。

構成の不備は、大きなコスト、想定外のジョブエラーや、GPU を有効活用できない状態の発生につながります。

正しい GPU ワークロード配置を強制的に適用する

既定では、AKS スケジューラは、十分な CPU とメモリを備えた使用可能なノードにポッドを配置します。ワークロードの配置制御がないと、次の 2 つの問題が発生する可能性があります。

スケジューラによって GPU ワークロードが GPU なしでノードに配置され、ワークロードの開始に失敗する可能性があります。
汎用ワークロードは GPU ノードを占有し、コストのかかるリソースを無駄にすることがあります。

正しい配置を適用するには以下のようにします。

[gpu-vendor].com/gpu: NoScheduleなどのキー (たとえば、nvidia.com/gpu: NoSchedule) を使用して GPU ノードをテイントします。このテイントにより、GPU 以外のワークロードがこれらのノードでスケジュールされるのをブロックします。
対応する容認値を GPU ワークロードのポッドスペックに追加して、テイントした GPU ノード上にそれらをスケジュールできるようにします。
スケジューラが GPU 容量を確実に予約できるように、ポッドで GPU リソースの要求と制限を定義します。例えば次が挙げられます。
```
resources:
  limits:
    [gpu-vendor].com/gpu: 1
```
検証ポリシーまたはアドミッションコントローラーを使って、GPU ワークロードに、必要な容認とリソース制限を含めることを強制します。

このアプローチにより、GPU 対応のワークロードのみを GPU ノードに配置させ、必要とされる特殊なコンピューティングリソースへのアクセスを提供できます。

AKS Automatic では、プラットフォームガードレールは既定で事前構成されています。引き続きワークロードレベルの配置コントロールを適用して、厳密な GPU スケジューリング動作を適用します。

GPU ドライバーのインストールとランタイムの準備状態を検証する

実稼働 GPU ワークロードをデプロイする前に、GPU ノードプールが以下を満たしていることを必ず確認してください。

互換性のある GPU ドライバーが装備されている。
正常な Kubernetes デバイスプラグイン DaemonSet をホストしている。
公開しているスケジュール可能リソースに [gpu-vendor].com/gpu が含まれている。

GPU ノードプールで現在実行されているドライバーのバージョンは、GPU ベンダーに関連付けられているシステム管理インターフェイス (SMI) を使って確認できます。

以下のコマンドは、NVIDIA GPU 対応ノードプール上のドライバーインストール状況とランタイムの準備状況を確認するために、GPU デバイスプラグインデプロイポッド内から nvidia-smi を実行します。

kubectl exec -it $"{GPU_DEVICE_PLUGIN_POD}" -n {GPU_NAMESPACE} -- nvidia-smi

出力は、次の出力例のようになります。

+-----------------------------------------------------------------------------+
|NVIDIA-SMI 570.xx.xx    Driver Version: 570.xx.xx    CUDA Version: 12.x|
...
...

GPU ノードプールごとに kubectl exec コマンドを繰り返して、ノードにインストールされているドライバーのバージョンを確認します。

AMD GPU 対応ノードプールについては、代わりに AMD GPU コンポーネントをデプロイし、ROCm デバイスプラグインポッド内で amd-smi コマンドを実行して、インストールされているドライバーのバージョンを確認します。

GPU 対応ノード上のノード OS イメージを常に最新の状態に更新しておく

AKS 上の GPU ワークロードのパフォーマンス、セキュリティ、互換性を確実に維持するには、推奨される最新のノード OS イメージを GPU ノードプールに適用した状態を常に保つことが不可欠です。以下の理由により、それらの更新プログラムはきわめて重要です。

非推奨バージョンやサポート終了 (EOL) バージョンを置き換える運用グレードの最新 GPU ドライバーが含まれている。
お使いの現行 Kubernetes バージョンとの互換性が完全にテストされている。
GPU ベンダーが確認した既知の脆弱性についての対策が施されている。
OS とコンテナーランタイムの最新の機能強化が組み込みまれ、安定性と効率性が向上している。

自動アップグレードチャネルを設定するか、手動アップグレードを使用して、AKS によってリリースされた最新の推奨ノード OS イメージに GPU ノードプールをアップグレードします。最新のノードイメージリリースの監視と追跡管理は、AKS リリーストラッカーで行うことができます。

ほとんどの運用シナリオでは、既定のベースラインとして AKS Automatic から始めます。 AKS Standard を使用する場合は、アップグレードチャネルとメンテナンス期間を明示的に構成します。

共有クラスターを使う場合の GPU ワークロードの分離

GPU ノードプールを持つ単一の AKS クラスター内で複数種類の GPU ワークロード (例: モデルトレーニング、リアルタイム推論、バッチ処理など) が実行されている場合は、以下の目的のために、それらのワークロードを分離することが重要です。

異なる種類のワークロード間に偶発的な干渉やリソース競合が発生することを避ける。
セキュリティを改善し、コンプライアンスの境界を維持する。
GPU リソース使用量の管理と監視をワークロードカテゴリ別にシンプルに行う。

名前空間とネットワークポリシーを使うと、単一の AKS クラスター内にある GPU ワークロード間を分離することができます。これにより、各種ワークロードに特有のクォータ、制限、ログ記録構成を設定でき、より明確なガバナンスが可能になります。

サンプルシナリオ

例として、相互通信の必要がない 2 種類の GPU ワークロードをホストする AKS クラスターの場合を考えてみましょう。

トレーニングワークロード: リソースを集中的に使用する AI モデルのトレーニングジョブ。
推論ワークロード: 待機時間に依存するリアルタイム推論サービス。

これら 2 つのワークロードを分離するには、以下の手順を実行します。

kubectl create namespace コマンドを使って、ワークロードの種類ごとに専用の名前空間を作成します。
```
kubectl create namespace gpu-training
kubectl create namespace gpu-inference
```
GPU ワークロードポッドに、以下のような種類別のラベルを付けます。
```
metadata:
  namespace: gpu-training
  labels:
    workload: training
```
ネットワークポリシーを適用して、トラフィックをワークロードの種類別に分離します。以下のマニフェストは、gpu-training 名前空間のすべてのイングレスとエグレスを (明示的に許可されたものを除き) ブロックします。
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: gpu-training
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []
```

このポリシー:

これは、gpu-training 名前空間内のすべてのポッドに適用されます。
すべての着信トラフィックと送信トラフィックを既定で拒否し、強力な分離をサポートします。

このモデルには、共有 GPU 環境における明確さ、制御の的確さ、安全性を高める効果があります。特に、ランタイムプロファイル、リスクレベル、運用要件がワークロードの種類によって異なる場合は非常に役立ちます。

GPU ノード上のリソース使用量をマルチインスタンス GPU (MIG) で最適化する

GPU ワークロードによってメモリ要件が異なります。 NVIDIA A100 40 GB などの小規模なデプロイでは、GPU 全体が必要ない場合があります。しかし、既定では、たとえ使用率が低くても個々のワークロードが GPU リソースを占有します。

AKS では、マルチインスタンス GPU (MIG) を使って GPU を小さなスライスに分割し、GPU ノードのリソース使用量を最適化する機能がサポートされており、チームにおいて小規模ジョブのスケジュール設定をより効率的に行うことができます。サポートされている GPU サイズと、AKS でマルチインスタンス GPU の使用を開始する方法についての詳細情報を参照してください。

エフェメラル NVMe データディスクを高パフォーマンスキャッシュとして使用する

AKS の GPU VM で実行されている AI ワークロードでは、トレーニングと推論のパフォーマンスを最大化するために、一時ストレージへの高速で信頼性の高いアクセスが不可欠です。エフェメラル NVMe データディスクは、VM ホストに直接接続された高スループットで待機時間の短いストレージを提供するため、データセットのキャッシュ、中間チェックポイントとモデルの重みの格納、データの前処理と分析のためのスクラッチ領域の提供などのシナリオに最適です。

AI ワークロード用に GPU 対応ノードプールをデプロイする場合は、パフォーマンスの高いキャッシュまたはスクラッチ領域として機能するようにエフェメラル NVMe データディスクを構成します。この方法は、I/O のボトルネックを排除し、データを集中的に使用する操作を高速化し、データを待機している間に GPU リソースがアイドル状態にならないことを保証するのに役立ちます。

Azureでは、さまざまなAZURE GPU VM ファミリにわたるエフェメラル NVMe データディスクがサポートされています。 GPU VM のサイズに応じて、VM には最大 8 つのエフェメラル NVMe データディスクがあり、合計容量は最大 28 TiB です。 VM サイズの詳細な構成については、選択した GPU ファミリの ND H100 v5 シリーズのドキュメントまたは VM サイズのドキュメントを参照してください。

プロビジョニングと管理を簡素化するには、Kubernetes ワークロードのエフェメラル NVMe ディスクを自動的に検出して調整できる Azure Container Storage を使用します。

推奨されるシナリオは次のとおりです。

AI のトレーニングと推論のための大規模なデータセットとモデルチェックポイントのキャッシュ。
AI 推論のモデルの重みをキャッシュする。たとえば、 KAITO ホスティングモデルをローカル NVMe 上の OCI アーティファクトとして使用します。
バッチジョブとデータパイプラインに適した高速スクラッチ領域を提供できます。

Important

エフェメラル NVMe ディスク上のデータは一時的なものであり、VM の割り当てが解除または再デプロイされると失われます。これらのディスクは、重要でない一時的なデータにのみ使用し、永続的な Azure ストレージソリューションに関する重要な情報を格納します。

エフェメラル NVMe データディスクの詳細については、 AKS のエフェメラル NVMe データディスクのベストプラクティスを参照してください。

AKS と GPU ワークロードの詳細については、次の記事を参照してください。

Azure Kubernetes Service (AKS) Automatic の概要
AKS 自動クラスターを作成する
AKS クラスターに GPU 対応ノードプールを作成します。
セルフマネージド NVIDIA DCGM エクスポーターを使って GPU ワークロードを監視します。
一般的な GPU メトリックに基づき、KEDA および DCGM エクスポーターを使って GPU ワークロードを自動スケールします。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-25