KubernetesでAIワークロードを本番運用する手順と要件

2026年5月14日

Contents

1 導入：Kubernetes上でのAIワークロード実装手順の要点
- 1.1 要点サマリ
2 設計と要件定義（SLA・KPI・容量見積り）
- 2.1 SLO／SLA設計と閾値決定の進め方
- 2.2 容量・GPUサイジングの実務計算例
3 プレフライトと互換性チェック（runbook）
4 導入手順：GPUドライバ・Operator・device-pluginの実践
5 ストレージ・ネットワーク・分散学習の実装と最適化
6 運用・監視・SLO・セキュリティのRunbook
7 付録：互換性テンプレート、サンプルYAML、用語集

スポンサードリンク

導入：Kubernetes上でのAIワークロード実装手順の要点

Kubernetes上でのAIワークロード実装手順は、GPU互換性、ストレージ、ネットワーク、監視とSLO設計を整合させることが成功の鍵です。この記事はKubernetes上でのAIワークロード実装手順を、実務で使えるチェックリストとコマンド例、runbook形式の手順で整理します。導入から運用までの優先順と注意点を明示します。

要点サマリ

ここでは実務で最初に押さえるべきポイントを簡潔に示します。

要件定義でSLO/SLA・レイテンシ・スループット・コストを数値化する。
プレフライトでKubernetes・カーネル・ドライバ・CNI・CSIの互換性を必ず確認する。
GPU導入はOperatorを推奨。手動導入はメンテナンスウィンドウとノード単位のローリングを計画する。
監視はDCGM→Prometheusへ、SLOは誤差予算とburn-rateで運用する。
イメージ署名・Secret管理・ランブックを整備して本番リスクを低減する。

設計と要件定義（SLA・KPI・容量見積り）

導入前にSLAやKPIを数値で定義し、容量と検証計画を固めます。ここではSLO設計の考え方、実務的な閾値決定法、GPUサイジングの計算例を示します。

SLO／SLA設計と閾値決定の進め方

SLOを決める際は観測フェーズ→閾値設定→誤差予算設計→アラート設計の順で進めます。理由は実測に基づいた閾値でないと誤検知や過剰対応につながるためです。

観測期間を設定し、現行のp50/p95/p99を計測する（例：7日〜30日）。
目標例：p95 ≤ 200ms、成功率 ≥ 99%。
誤差予算の計算例：月間リクエスト1000万、成功率99%なら許容失敗数は100,000件（月）。
アラート例（Prometheusの概念）：短期アラート（burn-rate増加）と長期アラート（累積誤差予算消費）を分ける。

Prometheusでのp95算出例（メトリクス名は環境に合わせる）：

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

1 2	histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

容量・GPUサイジングの実務計算例

想定負荷から必要GPU数を逆算し、負荷試験で検証します。数式で概算し、必ずロードテストで補正します。

同時処理量（並列度） = 平均リクエスト/秒 × 平均レイテンシ秒
必要GPU数 = ceil( 同時処理量 / GPUあたり同時推論数 )
例：想定200 req/s、目標p95=0.2s → 同時処理量 = 40。GPUあたり同時処理可能 = 10 → 必要GPU = 4。

またトレーニングはGPUメモリ限界・I/O帯域が支配的なので、バッチサイズとI/O帯域を組合せて試験します。

プレフライトと互換性チェック（runbook）

導入前のチェックは一回限りでなく継続的に実施します。ここでは即実行可能なコマンドと互換性確認のテンプレートを示します。

環境確認コマンドと初期チェックリスト

まずは現状を可視化するコマンドを走らせ、必須項目を確認します。結果はテンプレート表に記録します。

Kubernetes クライアント／サーババージョン

kubectl version --short

1 2	kubectl version --short

ノード一覧とAllocatable資源

kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{&quot;\n&quot;}{.status.allocatable}{&quot;\n\n&quot;}{end}'

kubectl get nodes -o wide

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{.status.allocatable}{"\n\n"}{end}'

GPUの有無（ノード上で）

# ノードにSSHして
lspci | grep -i nvidia
uname -r
cat /etc/os-release

# ノードにSSHして

lspci | grep -i nvidia

uname -r

cat /etc/os-release

ドライバ確認（ノード上）

nvidia-smi       # NVIDIA
/opt/rocm/bin/rocminfo  # ROCm

nvidia-smi # NVIDIA

/opt/rocm/bin/rocminfo # ROCm

device-plugin・OperatorのPod状態

kubectl get pods -n gpu-operator
kubectl get ds -n kube-system  # device pluginがDaemonSetなら

kubectl get pods -n gpu-operator

kubectl get ds -n kube-system # device pluginがDaemonSetなら

互換性マトリクス（テンプレート）

下表はコピーして使える互換性チェックのテンプレートです。実際のバージョンは公式互換性表を参照して埋めてください。

項目	確認コマンド（例）	参照（公式）
GPUモデル	lspci / nvidia-smi	https://www.nvidia.com/
NVIDIAドライバ / CUDA	nvidia-smi / nvcc --version	https://docs.nvidia.com/deploy/cuda-compatibility/
GPU Operator	helm list -n gpu-operator / kubectl get pods -n gpu-operator	https://github.com/NVIDIA/gpu-operator
MIG対応	nvidia-smi -q (MIG有無)	https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
ROCm互換性	/opt/rocm/bin/rocminfo	https://rocm.docs.amd.com/
CNI（eBPF）	calicoctl version / cilium status	https://docs.projectcalico.org/ , https://docs.cilium.io/
CSI/ストレージ	kubectl get sc / pv/pvc	CSIベンダー公式

必ず上記を実機で確認し、公式互換性ページの記載に従ってバージョンを固定してください。

CNIとeBPF・RDMAの注意点

CNIの選定はObservabilityや高性能通信の有無に影響します。CalicoはeBPFデータプレーンをサポートするリリースがありますが、eBPF機能はバージョン依存です。CiliumはeBPFを中心に設計されています。RDMAやSR-IOVを使う場合はドライバ、カーネル、CNIの整合を必ず確認してください。

Calicoドキュメント（eBPF）: https://docs.projectcalico.org/about/about-bpf
Ciliumドキュメント: https://docs.cilium.io/en/stable/

導入手順：GPUドライバ・Operator・device-pluginの実践

GPU導入はOperatorによる自動化を推奨します。手動導入はノード再起動や特権操作を伴うため、ローリングでの実施計画が必須です。

GPU Operator導入（推奨）と検証手順

GPU Operatorはドライバ、container toolkit、device plugin 等を統合管理します。まずは小さなノードプールでE2E検証を行ってください。

リポジトリ追加とインストール（Helm例）

helm repo add nvidia https://nvidia.github.io/gpu-operator
helm repo update
kubectl create namespace gpu-operator
helm install gpu-operator nvidia/gpu-operator --namespace gpu-operator -f values.yaml
kubectl -n gpu-operator get pods -w

helm repo add nvidia https://nvidia.github.io/gpu-operator

helm repo update

kubectl create namespace gpu-operator

helm install gpu-operator nvidia/gpu-operator --namespace gpu-operator -f values.yaml

kubectl -n gpu-operator get pods -w

インストール後の基本検証（ノードで）

# GPUが見えるか
kubectl get nodes -o jsonpath='{.items[*].status.allocatable}' | grep gpu || true
# ノード上
nvidia-smi

# GPUが見えるか

kubectl get nodes -o jsonpath='{.items[*].status.allocatable}' | grep gpu || true

# ノード上

nvidia-smi

values.yamlは環境依存です。GPU Operatorの各バージョンがサポートするCUDA/ドライバは公式リリースノートを確認して合わせてください（https://github.com/NVIDIA/gpu-operator）。

手動ドライバ導入とノードのローリング手順（runbook）

手動でドライバを入れる場合は以下手順を推奨します。必ずメンテナンスウィンドウで実行します。

影響範囲を確認し、対象ノードを固定のバッチに分ける。
対象ノードをcordonしてPodを退避。

kubectl cordon &lt;node&gt;
kubectl drain &lt;node&gt; --ignore-daemonsets --delete-emptydir-data

kubectl cordon <node>

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

ノードにSSHし、kubeletを停止（必要時）。

sudo systemctl stop kubelet

1 2	sudo systemctl stop kubelet

既存ドライバのアンインストール（ディストリ依存）。
公式手順でドライバをインストール（apt/yum/.run）。カーネルヘッダが必要な場合あり。
再起動し、nvidia-smi等で動作確認。
ノードをuncordonし、Podが戻ることを確認。

kubectl uncordon &lt;node&gt;

1 2	kubectl uncordon <node>

ノードは少数ずつ処理し、PDBとチェックポイントで可用性を確保します。

device-pluginの導入とリソース名の注意

device-pluginによりKubernetesにGPUリソースが公開されますが、リソース名はプラグイン/環境で異なることがあります。よく使われる例はnvidia.com/gpuですが、MIGやROCmでは別名/拡張名が出る場合があります。必ず以下を確認してください。

ノードのAllocatableに出るリソース名を確認する:

kubectl get nodes -o jsonpath='{.items[*].status.allocatable}'

1 2	kubectl get nodes -o jsonpath='{.items[*].status.allocatable}'

Podのリソース指定では、環境に合わせてリソース名を置き換える（下記YAML参照）。

ストレージ・ネットワーク・分散学習の実装と最適化

データパイプライン、共有ストレージ、低レイテンシ通信は学習と推論それぞれで最適化が必要です。ここでは実運用で効果のある構成と設定例を示します。

S3互換＋NVMeキャッシュの実務設計

トレーニング用データはS3互換ストレージに保管し、ジョブ開始時にノードローカルNVMeへステージングするのが一般的です。理由はオブジェクトストレージ単独ではI/Oレイテンシ/IOPSが不足しがちなためです。

ステージング手順の例
ジョブ開始時にデータを並列でNVMeにフェッチする（マルチスレッド/マルチストリーム）。
チェックポイント・モデルはS3へ定期的に書き出す。
キャッシュのライフサイクルを明文化（job完了時に削除等）。

オンプレではMinIOやCephをS3互換で検討し、S3のリード/ライト性能を事前にベンチマークしてください。

高性能通信（RDMA / SR-IOV / NCCLチューニング）

大規模分散学習ではネットワークがボトルネックになります。RDMAやSR-IOVは有効ですが導入コストが高く、CNIやドライバとの整合が必須です。

必要チェック：NICの対応（Mellanox等）、OFEDドライバ、カーネル、CNIの互換。
NCCLチューニング例（環境変数をPodに設定）
NCCL_SOCKET_IFNAME=eth0
NCCL_IB_DISABLE=0（IBを使う場合）
NCCL_P2P_LEVEL=NVL（設定は環境依存）
SR-IOVを用いる場合はMultusとSR-IOV CNI pluginの導入が必要です。

公式NCCLチューニング: https://developer.nvidia.com/nccl

分散学習の実例（PyTorchJob + checkpoint運用）

KubeflowのPyTorchJob等を使うとKubernetes上で学習ジョブのライフサイクル管理が容易です。チェックポイントはオブジェクトストレージへ書く設計にしてください。

重要項目：shared PVCではI/O競合、S3ステージングでスケールしやすい。
環境変数で通信設定（NCCL等）を渡す。

改良版のPyTorchJobサンプルは付録に掲載します。必ずserviceAccount、nodeSelector、tolerations、restartPolicy、volumeMounts等を明記してください。

運用・監視・SLO・セキュリティのRunbook

本番運用では監視→アラート→Runbookの実装が重要です。ここに示すのはすぐ使えるアラート例と初動手順、セキュリティ運用の実装フローです。

GPUとシステム監視（DCGM → Prometheus）

GPUメトリクスはDCGMで収集し、Prometheusで可視化・アラートに利用します。DCGM exporterをDaemonSetで配布し、PrometheusがServiceMonitorで拾う構成が一般的です。

DCGM exporter: https://github.com/NVIDIA/dcgm-exporter
PrometheusにおけるGPU利用（概念）

avg(rate(dcgm_gpu_utilization[5m])) by (gpu)

1 2	avg(rate(dcgm_gpu_utilization[5m])) by (gpu)

（実際のメトリクス名は環境に依存します。エクスポータの出力を確認してください）

SLOアラートと具体的Runbook例

アラートはSLOに紐づけ、パターン別に初動手順を定義します。例を示します。

レイテンシ悪化（p95上昇）
アラート発報 → 指定チャネルで通知
直近Prometheusグラフでp95/p99、リクエストレートを確認
Podの数・GPU利用率を確認（kubectl top / Prometheus）
キュー長やバックプレッシャーを確認し、スケールアウト/ワーカー追加を実施
根因が判明できない場合はモデルロールバック手順を開始
GPUドライバ障害（nvidia-smiが応答しない）
当該ノードをcordonし、Podを退避
device-plugin/driverのログを収集（kubectl logs / dmesg）
対応ノードでdriver再インストール（runbook参照）
再起動後、nvidia-smiで確認してuncordon

Runbookにはコマンド、ログ取得手順、担当エスカレーション経路、復旧優先度を明記してください（連絡先は社内ドキュメントにて管理）。

セキュリティ：イメージ署名・シークレット管理とKMS

イメージ署名はCIからの一貫運用が効果的です。cosignを用いKMSを鍵ストアにする流れを推奨します。シークレットはKMSやVaultで管理し、KubernetesではCSI-VaultやExternalSecretsを使うと安全です。

画像署名（cosign + KMS、概念）
CIでイメージをビルド → スキャン（Trivy等） → サイン（cosign）
クラスター側でAdmission Controllerにより署名を検証して未署名を拒否
cosign doc: https://github.com/sigstore/cosign
シークレット管理の選択肢
HashiCorp Vault（Kubernetes auth / CSI driver）: https://www.vaultproject.io/docs/platform/k8s
Cloud KMS + External Secrets（クラウド環境）
KubernetesのEncryptionProviderでの静的暗号化（APIレベル）: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

シークレットのローテーション方針、アクセス監査ログ、鍵管理ポリシーを実運用ポリシーに含めてください。

運用保守とメンテナンスのガイドライン

ドライバやカーネルの更新はノード単位のロールアップで実施し、必ずPDB/ジョブのチェックポイントを考慮する。
アップグレードはステージング→Canary→全体の順で実行する。
定期的なコストレビューとrightsizingを実施し、スポット/プリエンプティブルの活用を検討する。

付録：互換性テンプレート、サンプルYAML、用語集

ここでは実際に使えるチェック表、サンプルYAML（注意付き）、および主要略語の定義をまとめます。

互換性チェック（コピーして使える表）

以下は導入判定時に埋めるテンプレート例です。公式ドキュメントへの直接リンクで検証を必須にしてください。

項目	必要条件／備考	公式参照
Kubernetes API バージョン	例: 1.24/1.25 サポート確認	https://kubernetes.io/
NVIDIA Driver	GPUモデルに対応するドライバを指定	https://docs.nvidia.com/
CUDA	アプリで必要なCUDAバージョン	https://docs.nvidia.com/deploy/cuda-compatibility/
GPU Operator	Operatorバージョンと互換性	https://github.com/NVIDIA/gpu-operator
ROCm	サポートGPU/カーネル要件	https://rocm.docs.amd.com/
CNI (eBPF)	Calico/CiliumのeBPF対応を確認	https://docs.projectcalico.org/

サンプルYAML（推論Deploymentの最小例と注意点）

以下は最小構成のサンプルです。運用環境では必ずプレースホルダを置き換え、serviceAccountやVolume、nodeSelector等を適切に設定してください。

事前条件（必読）
GPUリソース名は環境で異なる（例: nvidia.com/gpu、gpu.example.com/gpu 等）。
device-plugin / GPUドライバがノードで稼働していること。
ネームスペース/ServiceAccount/NetworkPolicy等の社内ポリシーに合わせること。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: triton-inference
  namespace: inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: triton
  template:
    metadata:
      labels:
        app: triton
    spec:
      serviceAccountName: inference-sa  # 必要な権限を与えたServiceAccount
      restartPolicy: Always
      nodeSelector:
        accelerator: &quot;gpu&quot;              # 環境に合わせて置換
      tolerations:
      - key: &quot;gpu&quot;
        operator: &quot;Exists&quot;
        effect: &quot;NoSchedule&quot;
      containers:
      - name: triton
        image: &lt;YOUR_REGISTRY&gt;/triton:latest
        securityContext:
          runAsUser: 1000
        resources:
          limits:
            &quot;&lt;YOUR_GPU_RESOURCE_NAME&gt;&quot;: 1  # 例: nvidia.com/gpu へ置換
          requests:
            cpu: &quot;2&quot;
            memory: &quot;8Gi&quot;

apiVersion: apps/v1

kind: Deployment

metadata:

name: triton-inference

namespace: inference

spec:

replicas: 1

selector:

matchLabels:

app: triton

template:

metadata:

labels:

app: triton

spec:

serviceAccountName: inference-sa # 必要な権限を与えたServiceAccount

restartPolicy: Always

nodeSelector:

accelerator: "gpu" # 環境に合わせて置換

tolerations:

- key: "gpu"

operator: "Exists"

effect: "NoSchedule"

containers:

- name: triton

image: <YOUR_REGISTRY>/triton:latest

securityContext:

runAsUser: 1000

resources:

limits:

"<YOUR_GPU_RESOURCE_NAME>": 1 # 例: nvidia.com/gpu へ置換

requests:

cpu: "2"

memory: "8Gi"

PyTorchJob（簡易、注意点あり）

注意: PyTorchJob CRDはKubeflow/環境によってAPIバージョンが異なります。下例は構成イメージです。

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: pytorch-example
  namespace: training
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          serviceAccountName: train-sa
          restartPolicy: Never
          nodeSelector:
            accelerator: &quot;gpu&quot;
          containers:
          - name: pytorch
            image: &lt;YOUR_REGISTRY&gt;/pytorch-train:latest
            env:
            - name: NCCL_SOCKET_IFNAME
              value: &quot;eth0&quot;
            resources:
              limits:
                &quot;&lt;YOUR_GPU_RESOURCE_NAME&gt;&quot;: 1
              requests:
                cpu: &quot;4&quot;
                memory: &quot;16Gi&quot;
    Worker:
      replicas: 3
      template:
        spec:
          serviceAccountName: train-sa
          restartPolicy: Never
          nodeSelector:
            accelerator: &quot;gpu&quot;
          containers:
          - name: pytorch
            image: &lt;YOUR_REGISTRY&gt;/pytorch-train:latest
            resources:
              limits:
                &quot;&lt;YOUR_GPU_RESOURCE_NAME&gt;&quot;: 1

apiVersion: kubeflow.org/v1

kind: PyTorchJob

metadata:

name: pytorch-example

namespace: training

spec:

pytorchReplicaSpecs:

Master:

replicas: 1

template:

spec:

serviceAccountName: train-sa

restartPolicy: Never

nodeSelector:

accelerator: "gpu"

containers:

- name: pytorch

image: <YOUR_REGISTRY>/pytorch-train:latest

env:

- name: NCCL_SOCKET_IFNAME

value: "eth0"

resources:

limits:

"<YOUR_GPU_RESOURCE_NAME>": 1

requests:

cpu: "4"

memory: "16Gi"

Worker:

replicas: 3

template:

spec:

serviceAccountName: train-sa

restartPolicy: Never

nodeSelector:

accelerator: "gpu"

containers:

- name: pytorch

image: <YOUR_REGISTRY>/pytorch-train:latest

resources:

limits:

"<YOUR_GPU_RESOURCE_NAME>": 1

用語集（主要略語と定義）

MIG：Multi-Instance GPU。GPUを論理的に分割するNVIDIA機能。対応GPU/ドライバ依存。
DCGM：Data Center GPU Manager。NVIDIAのGPU監視ツールでPrometheusエクスポータあり。
TFRecord：TensorFlowで使うバイナリデータフォーマットの一つ。
ONNX：モデル交換フォーマット。フレームワーク間の移植に用いる。
ROCm：AMDのGPUコンピューティングソフトウェアスタック。
CNI：Container Network Interface。Kubernetesのネットワークプラグイン仕様。
NCCL：NVIDIAの分散通信ライブラリ（All-Reduce等）。
PDB：PodDisruptionBudget。Kubernetesの障害耐性設定。
HPA/KEDA/Cluster Autoscaler：Pod/イベント/ノードレベルのオートスケール手法。

参考（主要公式ドキュメント）

NVIDIA CUDA互換性: https://docs.nvidia.com/deploy/cuda-compatibility/
NVIDIA GPU Operator: https://github.com/NVIDIA/gpu-operator
NVIDIA MIGガイド: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
NVIDIA DCGM: https://docs.nvidia.com/datacenter/dcgm/
ROCm ドキュメント: https://rocm.docs.amd.com/
Calico ドキュメント: https://docs.projectcalico.org/
Cilium ドキュメント: https://docs.cilium.io/
Kubeflow Training (PyTorchJob): https://www.kubeflow.org/docs/components/training/pytorch/
KServe: https://kserve.github.io/
Triton Inference Server: https://github.com/triton-inference-server/server
Prometheus アラートルール: https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
Cosign（署名ツール）: https://github.com/sigstore/cosign
Vault（Kubernetes連携）: https://www.vaultproject.io/docs/platform/k8s
NCCL ドキュメント: https://developer.nvidia.com/nccl

まとめ（要点整理）

導入と運用の成功は、初期要件定義とプレフライトの厳密な実施にかかっています。SLOを数値化し誤差予算で運用し、GPU周りはOperatorでの管理を基本としてください。CNIやRDMA等の高度機能はバージョン依存性が強いため、公式互換性表で都度検証し、ドライバ更新はローリングかつチェックポイント設計とセットで実施してください。最後に、イメージ署名とKMS連携のシークレット管理をCI/CDに組み込み、Runbookを運用チームで共有しておくことが本番運用の安定性を高めます。

スポンサードリンク

-Kubernetes

comment コメントをキャンセル

: Kubernetes

Kubernetesでの OOMKilled と Linux OOM Killer の仕組み・QoS・Eviction・自動スケール対策

OOMKilled はノード全体のメモリ枯渇かコンテナ cgroup の上限超過で発生し、Linux OOM Killer が対象を選択します。本稿では QoS クラス別の Eviction 順序や AKS/GKE の eviction 設定、Prometheus 監視・アラート、VPA と Cluster Autoscaler の連携まで網羅的に解説します。

: Kubernetes

FinOps と AKS コスト最適化：実践ガイドとツール比較

FinOps と Azure Kubernetes Service (AKS) のコスト最適化手法を実践的にまとめ、主要ツールの比較と導入ポイントを詳しく解説します。

: Kubernetes

Kubernetes コスト最適化手法と2026年主要ツール徹底比較

本稿では、過剰プロビジョニングや可視化不足による予算超過の課題を踏まえ、右サイズ・オートスケーリング・スポット活用など実務的なコスト削減手法と、Kubecost・CAST AI・Spot.io・Harness の最新機能と料金を比較し、ROI 計算フレームワークで導入効果を示します。

: Kubernetes

EKS と AKS を活用したマルチクラウドKubernetes導入ガイド

EKS と AKS を組み合わせた二重クラスタ構成と GitOps 運用で、マルチクラウド環境の高可用性・低コストを実現する方法を解説します。

: Kubernetes

Kubernetes クラスタ構築ガイド：kubeadmでシングルノードからHAまでの手順

CPU2コア、メモリ4GiB以上のサーバーで、Ubuntu24.04上にcontainerdとkubeadmをインストールし、シングルノードからHA構成までの手順を解説します。

VSCO vs Lightroom 徹底比較（2026年）| 機能・価格・AI特徴

MacBook Neo 発売日・予約開始日と手順、価格・割引情報まとめ