GPU OperatorのPod構成要素と役割、ホストにドライバーがなくてもよいのか

ステータス: ドラフト (2026-10-07). Pod名、種類、初期化コンテナーの順序、ノードラベル、インストールオプションの組み合わせは、実際に稼働中の環境で読み取りのみを行って確認した値です。ドライバーをオペレーターがコンテナとして立ち上げる方式はこの環境では使用していないため直接テストできず（実測なし）、公式ドキュメントの記述で確認しました。作成規則: 実測データを基本とし、測定できなかったものは「実測なし」と表記します。

1. インストールすると起動するPod
2. Podはお互いを待機する: 検証チェーン
3. ホストにNVIDIAドライバーがなくてもよいのか
4. PodがGPUを取得するまで
5. 直接確認する読み取り専用コマンド
6. よくある誤解
確認したバージョンと日付、確認できなかったもの
参考文献

GPU Operatorを初めて使うと、 gpu-operator ネームスペースにPodが10個以上起動しますが、名前だけでは何が何だか分かりません。この記事では2つの質問に答えます。

各Podは何をし、どのノードに起動し、ないとどういう症状が出るのか。
ホストにNVIDIAドライバーをインストールしなくてもGPU OperatorだけでGPUを使えるのか。

簡単な答え。 Podは大きく分けてコントローラー（Deployment）、ノードラベラー（NFD）、そしてGPUノードごとに1つずつ起動するデーモンセットの束（ドライバー、ツールキット、デバイスプラグイン、GFD、DCGM Exporter、検証機）に分かれます。ホストにドライバーがなくても問題ありません。オペレーターがデフォルトでドライバーをコンテナとして立ち上げるためです。逆に、ホストにドライバーをすでにインストールしている場合は、オペレーターのドライバーをオフにする構成（driver.enabled=false)が可能であり、実際によく見られます。両方式は「ドライバーのライフサイクルを誰が管理するのか」が異なります。

1. インストールすると起動するPod

実際にGPU Operator（v26.3.3）が稼働中の環境で、 gpu-operator ネームスペースを読み取った結果です。数字（ノード数）は環境ごとに異なるため、種類と役割のみを整理します。

Pod（リソース名）	種類	どこに起動するか	仕事内容	ない場合、または失敗した場合
`gpu-operator`	Deployment	クラスターに1つ	コントローラー。 `ClusterPolicy` を読み取って以下のデーモンセットを作成し、ノードラベル（`nvidia.com/gpu.deploy.*`)を管理します	新しいものが何もデプロイされず、設定変更が反映されません
`gpu-operator-node-feature-discovery-master`, `-gc`	Deployment	クラスターにそれぞれ1つ	NFDの中央コンポーネント。ワーカーが送信したハードウェア情報をラベルとして付与し（master）、消えたノードの古いオブジェクトを整理します（gc）	ノードラベルが更新されません
`gpu-operator-node-feature-discovery-worker`	DaemonSet	すべてのノード	ノードのPCIデバイス、カーネルなどを読み取って報告します。NVIDIAデバイスがある場合、 `feature.node.kubernetes.io/pci-10de.present` ラベルが作成され、オペレーターはこれを見てGPUノードと判断します	GPUノードとして認識されず、以下のデーモンセットの希望数が0になります
`nvidia-driver-daemonset`	DaemonSet	GPUノード	NVIDIAドライバー（カーネルモジュール）をコンテナとしてインストールします。ホストにドライバーがある場合は作成しないように無効化できます（第3節）	`nvidia-smi` が失敗し、他のPodが初期化で待機します
`nvidia-container-toolkit-daemonset`	DaemonSet	GPUノード	コンテナランタイム（containerd）に `nvidia` ランタイムハンドラーを登録し、GPUデバイスとライブラリをコンテナに配置するツールをインストールします	`no runtime for "nvidia" is configured`
`nvidia-device-plugin-daemonset`	DaemonSet	GPUノード	kubeletに登録して `nvidia.com/gpu` の数を広告し、PodがGPUを要求すると `Allocate` でデバイスを割り当てます。デバイスの健康状態（XID）も監視します	ノードの `nvidia.com/gpu` がなくなるか減少します
`gpu-feature-discovery`	DaemonSet	GPUノード	GPUモデル、数、メモリ、ドライバーバージョンなどのGPU専用ラベル（`nvidia.com/gpu.product`, `nvidia.com/gpu.count` など）を付与します	モデル別のスケジューリングラベルがなくなります（GPUの広告自体への影響はありません）
`nvidia-dcgm-exporter`	DaemonSet	GPUノード	GPU使用率、メモリ、温度、電力、エラー指標をPrometheus形式で公開します	観測機能のみが失われます。分離されたDCGMに接続できない場合はCrashLoopBackOffになります
`nvidia-operator-validator`	DaemonSet	GPUノード	正しくインストールされたかを順番に検証します（第2節）	検証段階で停止したPodがどのコンポーネントの問題であるかを教えてくれます
`nvidia-cuda-validator`	短期Pod	検証時に生成され、終了すると完了	実際にCUDAのサンプルを1回実行してみます	検証失敗
`nvidia-mig-manager`	DaemonSet	MIGを有効にしたノード	MIGプロファイルを適用します	MIGを使用できないGPUでは意味がありません（この環境では無効化）
`nvidia-device-plugin-mps-control-daemon`	DaemonSet	MPSを有効にしたノード	MPS制御デーモン。この環境では希望数が0であるためPodはありません	該当機能を使用しない場合は関係ありません

NVSwitchシステム（HGXなど）では、GPU間のファブリックを構成する Fabric Manager が別途必要です。オペレーターのドライバーコンテナはNVSwitchを検出するとこれを一緒にインストールし、ホストドライバーを使用する場合は直接インストールする必要があります（公式ドキュメントの記述であり、この環境にはNVSwitchがないためテストできませんでした、実測なし）。

2. Podはお互いを待機する: 検証チェーン

GPUノードでデーモンセットが一斉に起動しますが、依存関係の順序が存在します。実際のPodの初期化コンテナ名で確認した順序です。

Pod	初期化コンテナ（実際の名前）	意味
`nvidia-operator-validator`	`driver-validation` → `toolkit-validation` → `cuda-validation` → `plugin-validation`	ドライバーがロードされたか、ツールキットがインストールされたか、CUDAサンプルが動作するか、プラグインがデバイスを広告しているかを順番に確認し、すべてを通過した後に本体のコンテナが開始します
`nvidia-container-toolkit-daemonset`	`driver-validation`	ツールキットはドライバーの準備ができるまで待機した後にインストールします
`nvidia-device-plugin-daemonset`, `gpu-feature-discovery`	`toolkit-validation`（と `config-manager-init`)	プラグインとGFDはツールキットの検証が完了した後に開始します
`nvidia-dcgm-exporter`	（なし、本体コンテナのみ）	別途の待機なしで起動します

したがって、1つの段階でブロックされると、後続の段階のPodが Init:0/1 の状態で留まり、問題の根本は最も前でブロックされた段階にあります。診断は ドライバー → ツールキット → プラグイン の順序で前方から行います。

オペレーターは、どのデーモンセットをどのノードに起動するかをノードラベルで決定します。確認してみると、GPUノードごとに nvidia.com/gpu.deploy.driver, .container-toolkit, .device-plugin, .gpu-feature-discovery, .dcgm, .dcgm-exporter, .operator-validator, .node-status-exporter ラベルが "true" として付与されており、各デーモンセットがこのラベルをnodeSelectorとして読み取ります。特定のノードで1つのコンポーネントのみを無効化したい場合は、そのノードの該当ラベルを false に変更すればよいです。

3. ホストにNVIDIAドライバーがなくてもよいのか

よいです。 公式ドキュメントでは driver.enabled のデフォルト値が true, toolkit.enabled のデフォルト値が true であると述べており、オペレーターがドライバーをコンテナ（nvidia-driver-daemonset)としてインストールします。そのため、GPUが挿入されたノードにOSとコンテナランタイムさえあれば、オペレーターが残りの部分を立ち上げます。

3つの構成があります。

構成	Helm 옵션	ドライバー	ツールキット	このようなとき
オペレーターすべて	デフォルト値	オペレーターのドライバーコンテナ	オペレーター	ノードOSが均一であり、アップグレードまでオペレーターに管理してほしいとき
ホストドライバーのみ	`--set driver.enabled=false`	ホストに事前インストール	オペレーター	OSが混在しているか、ドライバーを別途の手順（イメージ、パッケージ）で管理したいとき。この記事の確認環境はこの構成です
ホストに両方	`--set driver.enabled=false --set toolkit.enabled=false`	ホスト	ホスト	DGXなどの事前構成済みシステム。ドキュメントには、この場合デフォルトランタイムが `nvidia` に設定されている必要があると記載されています

確認した環境の ClusterPolicy は driver.enabled=false, toolkit.enabled=true、デバイスプラグインとGFDとDCGM Exporterは有効、MIG Managerは無効であり、その結果 nvidia-driver-daemonset はまったく作成されませんでした。それでも検証機はすべて通過し、GPUノードごとにプラグインが nvidia.com/gpu を広告しました。すなわち 「ホストドライバー＋オペレーターのツールキット、プラグイン、指標」の組み合わせが実際に動作します。 このとき、ツールキットPodはホストのルート（/）とドライバーのインストールパス（/run/nvidia/driver）をマウントし、開始前に driver-validation を使用してホストドライバーが使用可能であるかを確認します（第2節）。

ホストドライバーがすでに存在しているにもかかわらず、 driver.enabled を無効にしなかった場合については、公式ドキュメントに自動検出の記述があります。ドライバーPodの初期化コンテナが事前インストールされたドライバーを検出すると、ノードにラベルを付与してドライバーPodを終了させ、再スケジュールしないとのことです（ドキュメントの記述を読んだものであり、この環境ではテストできていません、実測なし）。それでも意図を明確にするためには、構成を明示する方が望ましいです。

ドライバーコンテナ方式のコスト。

ノードごとにOSのバージョンとカーネルに適合したドライバーイメージが必要です。カーネルがアップデートされるとドライバーを再度適合させる必要があり、事前コンパイル済みイメージはタグが <브랜치>-<커널>-<OS> 形式であるため、その組み合わせが存在しなければなりません。
ドライバーはカーネルモジュールであるため、置き換える前にGPUを使用しているPodをすべて停止する必要があります。オペレーターは cordon、待機、GPU Podの削除、選択的な drain によりこれをステートマシンとして管理するため、アップグレード中は該当ノードのGPUを使用できません。
自動カーネルアップグレード（unattended-upgrades）が有効になっていると、カーネルが変更された後にドライバーが適合しなくなる可能性があるため、公式ドキュメントではこれを無効にすることを推奨しています。

ホストドライバー方式のコスト。 オペレーターはホストドライバーのライフサイクル（アップグレード、置換）を管理しません。その代わり、ノードOSが混在していても問題なく、ドライバーの置換手順をチームの従来の方法（イメージ、パッケージ管理）で統制できます。

4. PodがGPUを取得するまで

インストールが完了した後のフローです。

デバイスプラグインがkubeletに登録し、デバイスのリストを伝達します。
kubeletがノードstatusの capacity と allocatable を更新します（nvidia.com/gpu: N).
スケジューラーはデバイスではなくこの数値のみを見ます（NodeResourcesFit）。GPUは limits にのみ使用し（requests を使用する場合は同じ値である必要がある）整数です。
kubeletが Allocate を呼び出し、応答としてデバイスノード、環境変数、マウント、CDI名を受け取ります。
コンテナランタイムがデバイスを注入します。オペレーター25.10.0以降はCDI（Container Device Interface）がデフォルトであり、通常のワークロードでは runtimeClassName は必要ありません。

プラグインとの接続が切断されると、kubeletはデバイスをunhealthyに戻してallocatableを0に下げ、5分の猶予が過ぎるとリソース名を削除します（kubeletソースの記述）。したがって、「Insufficient nvidia.com/gpu」イベントが同じであっても、原因はプラグイン、ツールキット、ドライバー、スケジューリング制約のどこにでもあり得ます。

5. 直接確認する読み取り専用コマンド

# 오퍼레이터가 올린 파드와 노드별 분포
kubectl -n gpu-operator get deploy,ds
kubectl -n gpu-operator get po -o wide

# 오퍼레이터가 어떤 구성요소를 켰는가(ClusterPolicy)
kubectl get clusterpolicy -o jsonpath='{.items[0].spec.driver.enabled} {.items[0].spec.toolkit.enabled}{"\n"}'

# 노드별 GPU 광고량과 GPU 라벨
kubectl get nodes -o custom-columns=N:.metadata.name,CAP:.status.capacity.nvidia\.com/gpu,ALLOC:.status.allocatable.nvidia\.com/gpu
kubectl get nodes -L nvidia.com/gpu.present,nvidia.com/gpu.product

# 어떤 노드에 어떤 구성요소를 띄우도록 라벨이 붙었는가
kubectl get node <노드> -o json | grep -o 'nvidia.com/gpu.deploy[^,]*'

# 검증기가 막힌 곳(초기화 컨테이너 이름이 막힌 단계)
kubectl -n gpu-operator describe po -l app=nvidia-operator-validator | grep -A2 -i "init containers"

6. よくある誤解

「GPU Operatorはドライバーのインストーラーである。」 ドライバーは構成要素の1つに過ぎません。ホストドライバーを使用する環境でも、ツールキットのインストール、プラグインの登録、ラベル管理、指標、検証のためにオペレーターは引き続き有用です。
「ホストドライバーがあればオペレーターは不要である。」 ドライバー単体では、KubernetesはGPUをリソースとして認識できません。デバイスプラグインとコンテナランタイムの設定があって初めて nvidia.com/gpu が作成されます。オペレーターがこれら2つを自動的に適合させます。
「オペレーターを立ち上げればcontainerdの設定は安全である。」 ツールキットはホストのcontainerd設定ファイル（/etc/containerd)を直接記述します。他の設定ファイルと競合すると、CRIの設定全体が置き換える可能性があります（containerd 1.7の設定マージがプラグインセクション全体を置き換える仕様、ソース確認済み）。第3部の第5節を参照してください。
「ツールキットがcontaineredにSIGHUPを送信すると、設定のみを再読み込みする。」 使い捨て VM の containerd 2.2.1 で SIGHUP を送信してみたところ、プロセスが終了し、systemd が 5 秒後に再起動しました(Restart=always)。ノードを一度にすべて置き換えるのではなく、1 ノードずつ適用する理由がここにあります (パート 03 参照)。
「nvidia.com/gpu.present を見ればインストールが完了したということです。J このラベルは NFD とオペレーターが GPU ハードウェアを検出したという意味であり、ドライバーとプラグインが動作しているという意味ではありません。ノードの allocatable とチェッカーの状態を確認する必要があります。

確認したバージョンと日付、確認できなかったもの

2026-10-07 に閲覧した環境は、GPU Operator v26.3.3、Container Toolkit v1.19.1、デバイスプラグイン v0.19.3、NFD v0.18.3、DCGM Exporter 4.5.3-4.8.2（distroless イメージ）です。公式ドキュメントはインストールガイドと概要ページを開いて確認しました。

オペレーターのドライバーコンテナ方式は、直接検証できていません（未実測）。 確認した環境がホストドライバーを使用しているためです。この方式の動作とコストは、公式ドキュメントの記述に基づいています。
ホストドライバーが存在する場合の自動検出（ドライバーポッドの終了）はドキュメントを読んだものであり、検証できていません。
NVSwitchシステムのFabric Managerの動作、MIG Managerの実適用、MPSはこの環境で使用していないため確認できていません。
ポッドの一覧は特定時点のスナップショットであり、設定によって構成要素が増減します（サンドボックスワークロード用のKubeVirtデバイスプラグイン、vGPUマネージャーなどはこの環境にはありませんでした）。

参考文献

NVIDIA GPU Operator 概要: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html
NVIDIA GPU Operator の開始（プレインストール済みドライバーと Helm オプション）: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html
本シリーズの第3回（GPU Operator スタックの解剖とトラブルシューティング）、第17回（DCGM Exporter メトリクス）、第22回（知識マップ）