Skip to content
Published on

NVIDIA GPU Operator入門 — もともと手で入れていた六つの部品

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — GPUノードを手で作るとしたら

CPUだけのワークロードなら、Kubernetesのノードを増やす作業は退屈なほど単純です。ノードを繋ぎ、kubeletが登録され、Podが載ります。GPUが絡むとその単純さが消えます。カードは挿さっていてkubeletも正常なのに、Podはずっとpendingで、ノードのallocatableのどこにもGPUという語がありません。

理由は単純です。KubernetesはGPUを知りません。GPUをリソースとして認識させるにはノードごとに最低六つの部品を噛み合わせる必要があり、その部品同士のバージョンも合っていなければなりません。GPU Operatorはその部品を消してくれる道具ではなく、部品を一つのコントローラの下へ移す道具です。この違いを理解して始めるかどうかで、障害時の所要時間が大きく変わります。

メトリクス名と設定は2026-08-12に公式ドキュメント・リポジトリで確認しました。バージョンによって異なる場合があるため、使用中のバージョンで再確認してください。

手で入れていたもの

Operatorなしでノードを準備すると、手順はおおよそ次のようになります。各段が前の段に依存するため、順序を入れ替えることはできません。

まずカーネルモジュールとユーザ空間ライブラリを含むNVIDIAドライバをノードに入れます。カーネルが上がれば再ビルドか再インストールです。次にNVIDIA Container Toolkitを入れ、containerdやCRI-Oにnvidiaランタイムハンドラを登録します。これがないとドライバが健全でもコンテナ内からデバイスファイルが見えません。

その次がデバイスプラグインです。kubeletに登録し、nvidia.com/gpuという拡張リソースをノードに広告する役割です。ここまで来て初めてスケジューラがGPUをリソースとして扱います。そして狙ったノードへ載せるにはどのカードが何枚あるかのラベルが要り、それがGPU Feature Discovery、その下にある汎用ラベラがNode Feature Discoveryです。最後に温度、電力、エラーといったテレメトリを取り出すにはDCGMとその前段のexporterが必要です。

六つの部品にノード数を掛け、さらにカーネル更新とドライバ更新を掛ければ、なぜこれがオペレータに包まれたのかは明らかです。

GPU Operatorがまとめるもの

公式の概要ページは、管理対象としてNVIDIAドライバ、GPU用Kubernetesデバイスプラグイン、NVIDIA Container Toolkit、自動ノードラベリングを担うGPU Feature Discovery、モニタリングのためのNVIDIA DCGM、NVIDIA MIG Manager for Kubernetes、Validator、NVIDIA DCGM Exporter、NVIDIA Driver Manager for Kubernetesを挙げています。さらにKubeVirt GPU Device Plugin、vGPU Device Manager、GDS Driver、Kata Manager、GDRCopy Driverといった選択的な部品が重なります。

これら全ての望ましい状態はclusterpolicies.nvidia.comというカスタムリソース一つに集約されます。ここから実務上の規則が出ます。DaemonSetを直接編集するとオペレータが元に戻します。直す場所は常にClusterPolicyかHelm値です。

チャートの既定値を見ると各部品のスイッチがそのまま現れます。リポジトリのdeployments/gpu-operator/values.yamlで確認した値です。

# deployments/gpu-operator/values.yaml (抜粋、2026-08-12確認)
mig:
  strategy: single

driver:
  enabled: true
  kernelModuleType: 'auto'
  usePrecompiled: false

toolkit:
  enabled: true
  image: container-toolkit
  installDir: '/usr/local/nvidia'

devicePlugin:
  enabled: true
  image: k8s-device-plugin

dcgm:
  # disabled by default to use embedded nv-hostengine by exporter
  enabled: false

dcgmExporter:
  enabled: true
  enablePodLabels: false
  enablePodUID: false
  serviceMonitor:
    enabled: true
    interval: 15s

gfd:
  enabled: true

migManager:
  enabled: true

dcgm.enabledが既定で無効なのは注目に値します。コメントが理由をそのまま述べています。exporterに内蔵されたnv-hostengineを使うためです。別途DCGMのDaemonSetを立てるのは、リモートhostengineを使いたいときの選択肢です。

一覧の中では目立ちませんが、障害対応で最も頻繁に出会うのがValidatorです。チャートにはvalidatorセクションとして入っており、クラスタではnvidia-operator-validatorという名前のPodとして動きます。この Pod の仕事は、前段が実際に成功したかを順に検証することです。ドライバが上がったか、ツールキットがランタイムに登録されたか、デバイスプラグインがリソースを広告しているかを順に確認し、一つでも失敗すると後続のコンポーネントが起動段階で止まります。そのためGPU関連のPodが初期化段階で止まっているとき、原因は大抵そのPod自身ではなく前段にあります。この一点を知っているだけで診断の順序が大きく短くなります。

インストールはどう見えるか

公式のスタートページが示すインストールはHelm二行です。

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

helm install --wait --generate-name \
    -n gpu-operator --create-namespace \
    nvidia/gpu-operator \
    --version=v26.3.3

すでにドライバがノードに入っている、あるいはコンテナツールキットが構成済みのクラスタなら、該当部品を切って入れます。

helm install --wait --generate-name \
    -n gpu-operator --create-namespace \
    nvidia/gpu-operator \
    --version=v26.3.3 \
    --set driver.enabled=false \
    --set toolkit.enabled=false

導入後の確認はPod一覧とClusterPolicyの状態、そして実際のallocatableです。

kubectl get pods -n gpu-operator
kubectl get clusterpolicy

# ノードがGPUをリソースとして広告しているか確認
kubectl get nodes -o json \
  | jq '.items[] | select(.status.allocatable["nvidia.com/gpu"] != null)
        | {node: .metadata.name, gpu: .status.allocatable["nvidia.com/gpu"]}'

最後に実際のワークロードを一つ流します。公式ドキュメントのサンプルがそのまま使えます。

apiVersion: v1
kind: Pod
metadata:
  name: cuda-vectoradd
spec:
  restartPolicy: OnFailure
  containers:
    - name: cuda-vectoradd
      image: 'nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04'
      resources:
        limits:
          nvidia.com/gpu: 1

インストール前に確認すること

ドキュメントが挙げる前提条件のうち、実際に人を止めるのは四つです。

第一に、ワーカーノードのOSバージョンが揃っていること、揃っていないならドライバが事前導入されていることです。オペレータはドライバをコンテナとして配るため、カーネルとOSの組み合わせごとにイメージが分かれます。

第二に、CRI-Oやcontainerdのようなコンテナエンジンが構成済みであることです。ツールキットがランタイムハンドラを登録する相手を必要とします。

第三に、クラスタがPod Security AdmissionでPodの挙動を制限しているなら、オペレータの名前空間のenforcementポリシーをprivilegedにラベル付けする必要があります。ドライバコンテナがカーネルモジュールを扱うため回避できません。

第四に、Node Feature Discoveryが必要です。 チャートは既定で同梱しますが、既にクラスタにNFDがあるなら二重導入を避ける必要があります。ここで衝突すると症状がGPUと無関係に見えるため、原因究明に時間がかかります。

おわりに — Operatorはインストールを消さず移すだけ

GPU Operatorを使ってもドライバのバージョンやカーネル互換性の問題は消えません。消えるのはノードごとに人が入って同じ作業を繰り返す部分で、代わりに現れるのはオペレータという新しい層です。障害時にはノードより先にgpu-operator名前空間のPodログを読むことになります。

そこでこのシリーズは層の順にたどります。次回はその六部品のうちスケジューリングを実際に左右するデバイスプラグインを開きます。nvidia.com/gpuという名前がどこで作られ、なぜその数を小数で割れないのかが次の主題です。

試してみる

  • K8s 実習ラボ — マニフェストを直接いじって、リソース要求がスケジューリングにどう効くか確かめてください。
  • kubectlコマンド検索 — 上で使った確認コマンドを状況別に探せます。
  • Kubestronautクイズ — オペレータとカスタムリソースの理解を問題で点検してください。

シリーズ

参考資料

Discuss on Twitter • View on GitHub