こんにちは、ソフトクリエイトでエンジニアをしているＫです。 以前、 こちらのブログ で「AI Challenge Day」へ参加した感想を投稿した以来、久しぶりの投稿になります！ 最近は、主にAIエージェント周りの開発や検証に取り組んでいます。 はじめに

要約 ：Elastic Agent Builder 9.5（Elastic Stack 9.5.4 / 9.5.5）で、AI エージェントの安全対策を、実際に環境を作って試しました。ツールを絞る設定、ロールの権限（DLS / FLS）、実行前の人の承認は、製品の機能で実現できました。一方で、Trace（エージェントの実行の記録）にツールの詳細を記録する設定を ON にすると、顧客データを見る権限の無い人にも、Trace から顧客データが見えました。本文、設定、クエリ、画面へのたどり方は GitHub にまとめています。 ▶ 記事を読む（GitHub）： https://github.com/SIOS-Technology-Inc/elastic-blogs/tree/main/2026-10-agent-builder-security AI エージェントは、ツールを使って実際に操作をします。そのため、従来の LLM 対策だけでは足りません。前半の記事「 AIエージェントはなぜ危険になる？仕組みから考えるセキュリティの4原則 」では、そのための 4 つの原則を紹介しました。後半のこの記事では、4 つの原則を Elastic Agent Builder 9.5 で実際に試しました。 検証の条件 製品：Elastic Stack 9.5.4 / 9.5.5（セルフマネージド、Docker）、Trial ライセンス 検証期間：2026 年 10 月 5 日〜8 日 モデル：主に Elastic Inference Service（EIS）を Cloud Connect 経由で利用 シナリオ：社内マニュアルを検索して答えるエージェントを作り、マニュアルの 1 件に「顧客情報を外へ送れ」という指示を仕込みました データ：すべて架空のデータです。メールは本物を送らず、専用の Index への書き込みを「送信」としました 分かったこと ツールを絞る ：新しいエージェントでは、Elastic capabilities が OFF でも、Tools タブにツールが選ばれていることがありました。使わないツールは、手で外す必要があります。 権限で守る ：今回の ES|QL ツールでは、使う人の Elasticsearch の権限（Index・DLS・FLS）が、エージェント経由でもそのまま効きました。守っているのは LLM ではなく Elasticsearch です。ただし、FLS で隠した項目を ES|QL の KEEP で名指しすると、ツール全体がエラーになりました。 人が承認する ：9.5.5 では、ツールの「Require user confirmation」を Always にすると、人が Allow を押したときだけ送信のツールが動きました。9.5.4 では、Workflow の承認ステップで止められました。ただし、Tools API から直接ツールを実行すると、Agent Builder の確認画面は出ません（公式ドキュメントより）。 記録と検知 ：Trace の初期設定では、自分で作ったツールやエージェントの名前が「custom」と記録されました。Trace を見張る ES|QL のアラートルールで、送信の Workflow の起動を約 28 秒で検知できました。ただし、Workflow の承認画面で Decline した操作でもアラートは鳴りました。今回の設定では、誰が使ったか、本当に送信したかは、Trace だけでは分かりませんでした。 記録と権限がぶつかる ：Trace にツールの詳細を記録すると、顧客 Index を読めないユーザーでも、Trace を読めれば顧客データを読めました。FLS でツールの結果の項目は隠せましたが、同じ顧客データが chat span の入力メッセージ（gen_ai.input.messages）にも入っていて、そこからは読めました。 モデル ：同じエージェント・同じ指示文でも、モデルによって反応が違いました。1 回の質問でも、選んだモデル以外が呼ばれていました。モデルが断ってくれることだけには頼れません。 この記事で分かること（設定の場所と確かめ方） 記事では、検証の結果だけでなく、Agent Builder の安全対策を「どこで設定し、どう確かめるか」も、画面へのたどり方と一緒に載せています。画面の名前や場所は、Elastic Stack 9.5.4 / 9.5.5 で確かめたものです。 Elastic Agent Builder で、エージェントが使えるツールを絞るには？ エージェントの設定の Tools タブで、使わないツールを外します。ツールは、Agent Builder → Manage components → Tools で作ります（2 章）。 エージェントを使える人を決めるには？ エージェントの設定の Access control で、Public / Shared / Private から選びます。今回の環境では、新しいエージェントの初期値は Public でした（2 章）。 ※ Access control はエージェントの公開範囲を制御する設定であり、Agent Builder 自体の利用権限は Kibana のロールでも管理されます。 文書ごと・項目ごとにデータを隠すには（DLS / FLS）？ Stack Management → Security → Roles でロールを開き、Index privileges の行で設定します。DLS は「Grant read privileges to specific documents」、FLS は「Grant access to specific fields」です（3 章）。 送信の前に人が承認するようにするには？ 9.5.5 では、ツールの作成画面で「Require user confirmation」を Always にします。9.5.4 では、Workflow に承認ステップ（waitForApproval）を入れ、承認されたときだけ送信のステップを動かす条件（if）を付けます（4 章）。 エージェントの実行の記録（Trace）を設定するには？ Stack Management → AI → GenAI Settings → Agent Builder Traces で設定します。Advanced privacy settings で、記録する内容（ツールの詳細、本当の名前など 7 つ）を選べます。初期値はすべて OFF です（5 章、7 章）。 危険な操作でアラートを出すには？ Stack Management → Alerts and Insights → Rules → Create rule → Elasticsearch query で、Trace を ES|QL で見張るルールを作ります（6 章）。 どのモデルが使われたかを確かめるには？ Trace の chat span に記録されたモデル ID で確かめます。機能ごとのモデルの割り当ては、Stack Management → Model Management → Feature settings で見られます（8 章）。 設定が効いているかを確かめるには？ 制限したユーザーで、Discover の ES|QL や、Elasticsearch の _search で実際に検索します。今回は、ES|QL で null と表示された項目を、_search では読めました（7 章）。 こんな方におすすめ Elastic Agent Builder の導入を考えている方 AI エージェントの権限、承認、記録のしくみを決める方 Elasticsearch の DLS / FLS をすでに使っている方 検証の結果より、まず設定の場所と確かめ方を知りたい方 関連記事 前半： AIエージェントはなぜ危険になる？仕組みから考えるセキュリティの4原則 Trace の開き方と読み方： AI エージェントの「中で何が起きたか」を見える化する 参考（公式ドキュメント） Permissions and access control in Elastic Agent Builder Tools（Elastic Agent Builder） Collect traces（Elastic Agent Builder） Role management using Kibana ※ 2026 年 10 月時点で、上の環境と今回のシナリオで試した結果です。バージョンや設定によって、動きは変わることがあります。 The post Elastic Agent Builder 9.5 で AI エージェントの安全対策を試した：できたこと、できなかったこと first appeared on Elastic Portal .

はじめに Kubernetes上でLLMの推論などGPUを使うワークロードを動かすには、GPUノードにドライバを入れ、PodからGPUを利用できる状態にしておく必要があります。本記事では、インターネットに接続できないAirGap環境のRKE2クラスタに対して、NVIDIA GPU DriverとNVIDIA GPU Operatorを導入し、Kubernetes上でGPUを使えるようにするまでの手順を紹介します。 SUSE AIのようなKubernetes上のAI基盤を構築する際の前提作業にあたりますが、手順自体は特定のAI基盤に依存しない汎用的な内容です。RKE2以外のKubernetesディストリビューションでも、containerdのソケットや設定ファイルのパスを読み替えれば応用できます。 GPU設定に必要なツール KubernetesでGPUを使うには、ノードのOS側でGPUを動かす「NVIDIA GPU Driver」と、Kubernetes側でGPUをリソースとして扱うためのコンポーネント群をまとめて管理する「NVIDIA GPU Operator」の2つが必要です。 NVIDIA GPU Driver NVIDIA GPU Driverは、OSがGPUを認識・制御するためのソフトウェアです。カーネルモジュール（ nvidia 、 nvidia_uvm など）と、 libnvidia-ml.so や libcuda.so といったユーザー空間ライブラリ、 nvidia-smi などの管理ツールで構成されます。コンテナ内のCUDAアプリケーションも、最終的にはホスト上のこのドライバを経由してGPUを利用します。 Kubernetesで使う場合、ドライバの導入方法は次の2通りです。 ホストOSに直接インストールする ：OSのパッケージ管理でドライバを入れる方法です。 GPU Operatorのドライバコンテナで入れる ：GPU Operatorがドライバ入りのコンテナを各ノードで動かし、カーネルモジュールをロードする方法です。 ホストOSに直接インストールする方法はドライバをOSのパッケージ管理で扱えるため、OSの更新やイメージ管理とあわせてドライバを管理したい場合に向いています。また、Kubernetes以外のプロセスからもGPUを使いやすくなります。 GPU Operatorのドライバコンテナで入れる方法は、OperatorがすべてのGPUノードにドライバを自動で導入し、更新も管理するため、GPUノードが多い場合や頻繁に増減する場合に向いています。 本記事では前者のホストOSへの直接インストールの手順を解説します。 なお、ドライバのバージョンはGPU Operatorのサポート対象から選びます（ Release Notes ）。 NVIDIA GPU Operator NVIDIA GPU Operatorは、KubernetesでGPUを使うために必要なNVIDIAのソフトウェア一式を、Operatorパターンで自動的にデプロイ・管理する仕組みです。本来はノードごとに個別に設定する必要があるコンテナランタイムの設定やDevice Pluginなどを、 ClusterPolicy というカスタムリソースでまとめて宣言的に管理できます。 出典： About the NVIDIA GPU Operator GPU Operatorが管理する主なコンポーネントと、本記事での扱いは次のとおりです。 コンポーネント 役割 本記事での扱い Node Feature Discovery（NFD） ノードのハードウェア情報を検出し、NVIDIA GPU搭載ノードにラベルを付与 有効 GPU Feature Discovery（GFD） GPUの型番・メモリ量・ドライババージョンなどを nvidia.com/* ラベルとして付与 有効 NVIDIA Container Toolkit コンテナランタイム（containerd）を設定し、コンテナからGPUを使えるようにする 有効 NVIDIA Device Plugin GPUを拡張リソース nvidia.com/gpu としてkubeletに登録し、Podへ割り当てる 有効（タイムスライシング設定あり） DCGM Exporter GPUの使用率や温度などのメトリクスをPrometheus形式で公開 有効 Operator Validator ドライバ・Toolkit・Device Pluginが正しく動作しているか検証 有効 NVIDIA Driver（コンテナ） ドライバをコンテナとして導入 無効（ホストに導入済みのため） MIG Manager MIG対応GPUの分割構成を管理 無効（MIG非対応のGPUノードを使うため） 設定手順 設定概要 AirGap環境では、インターネットに接続できる作業用端末で必要な資材を集め、閉域側のノードやレジストリへ運び込んでから設定します。全体の流れは次のとおりです。 作業用端末でNVIDIA GPU Driverのパッケージ（.deb）をダウンロードし、GPUノードへ転送する GPUノードにNVIDIA GPU Driverをインストールし、動作を確認する 必要に応じてGPUノードにラベルとテイントを設定する 作業用端末でGPU OperatorのHelmチャートとコンテナイメージを取得し、閉域内のHelmリポジトリ・コンテナレジストリへ登録する RKE2のHelmChartリソースでGPU OperatorをDownstream Clusterにインストールし、動作を確認する インターネットに接続できるのは作業用端末だけです。Downstream Clusterは、閉域内のHarborからチャートとイメージを取得します。 前提条件 GPUノードのOSが、NVIDIA GPU DriverとGPU Operatorのサポート対象であること（ Platform Support ） SUSE Rancher PrimeのRancher Management Server（以下、RMS）と、RMSから管理されるRKE2のDownstream Clusterが構築済みであること RMSとDownstream ClusterはAirGap環境にあり、インターネットに接続できないこと Downstream ClusterのRKE2がcontainerd 2.x系を同梱していること（GPU Operator v25.10以降のCDIを使う前提） インターネットに接続できる作業用端末があり、GPUノードと同じOS・バージョン（本記事ではUbuntu 24.04）であること 作業用端末に helm 、 skopeo 、 kubectl 、Docker（またはPodman）が導入されていること 作業用端末からGPUノードへSSH接続できること 作業用端末からDownstream Clusterを kubectl で操作できること（RMSから取得したkubeconfigを利用） 作業用端末とDownstream Clusterの両方から接続できる、OCI対応のコンテナレジストリ・Helmリポジトリがあること。また、Downstream Clusterの各ノードがそこからイメージを取得できること（RKE2の registries.yaml 設定など） 構築環境 本記事の検証環境は次のとおりです。GPU Operatorの各コンポーネントは、v26.3.3のデフォルトバージョンを使っています。 項目 バージョン・設定 OS Ubuntu 24.04 RKE2 v1.36.3+rke2r1 Rancher Prime v2.15.2 搭載GPU NVIDIA Tesla T4（AWS g4dn.2xlarge） コンテナレジストリ・Helmリポジトリ Harbor NVIDIA GPU Driver 580.178.04（nvidia-driver-580-server） NVIDIA GPU Operator v26.3.3 NVIDIA Container Toolkit v1.19.1 NVIDIA Device Plugin / GPU Feature Discovery v0.19.3 DCGM Exporter 4.5.3-4.8.2-distroless Node Feature Discovery v0.18.3 NVIDIA GPU Driver 設定手順 最初にGPUノードで、搭載されているGPUの種類とカーネルバージョンを確認します。カーネルバージョンは、後でカーネルヘッダをダウンロードする際に使います。 $ lspci | grep -i nvidia # 出力例 00:1e.0 3D controller: NVIDIA Corporation TU104GL [Tesla T4] (rev a1) $ uname -r # 出力例 7.0.0-1012-aws 次に、作業用端末でドライバのパッケージをダウンロードします。apt-get install –download-onlyは、実行した環境に導入済みのパッケージをダウンロード対象から外します。そこで、GPUノードと同じUbuntu 24.04のクリーンなコンテナを起動し、その中でダウンロードします。こうすると作業用端末の環境に左右されず、依存パッケージを漏れなく集められます。 $ mkdir -p ~/nvidia-driver-pkgs $ docker run --rm -it -v ~/nvidia-driver-pkgs:/pkgs ubuntu:24.04 bash コンテナ内で、利用可能なドライバを確認します。データセンター向けGPUでは、末尾が -server のパッケージを選びます。 # apt-get update # apt-cache search nvidia-driver | grep server # 出力例 nvidia-driver-470-server - NVIDIA Server Driver metapackage ・ ・ ・ nvidia-driver-580-server - NVIDIA Server Driver metapackage 使用するドライバを決めたら、カーネルヘッダとあわせてダウンロードします。ドライバのDKMSモジュールはGPUノード上でビルドされるため、GPUノードのカーネルに対応した linux-headers が必要です。指定できるバージョンは Launchpad で確認できます。 7.0.0-1012-aws のカーネルバージョンで nvidia-driver-580-server をインストールする場合は、コンテナ内で次のように実行します。ダウンロードしたパッケージは、マウントした /pkgs 経由で作業用端末の ~/nvidia-driver-pkgs に保存されます。 # apt-get install --download-only -y \ nvidia-driver-580-server=580.178.04-0ubuntu0.24.04.1 \ linux-headers-<GPUノードのカーネルバージョン> # cp /var/cache/apt/archives/*.deb /pkgs/ # exit クリーンなコンテナでダウンロードするため、GPUノードに導入済みの基本パッケージも含まれます。GPUノードのパッケージが古い場合、インストール時にそれらも更新される点に注意してください。 ダウンロードしたパッケージを、作業用端末からGPUノードに転送します。 $ scp -r -i <SSH鍵> ~/nvidia-driver-pkgs ubuntu@<GPUノードIP>:~/ GPUノード上でパッケージをインストールし、再起動します。 $ cd ~/nvidia-driver-pkgs $ apt-get install -y --no-download ./*.deb $ sudo reboot 動作確認 再起動後、インストールが正常に完了したかをGPUノード上で確認します。まず、 nvidia-smi でGPUの情報とドライババージョンが表示されることを確認します。 $ nvidia-smi # 出力例 Fri Sep 25 06:34:12 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 580.178.04 Driver Version: 580.178.04 CUDA Version: 13.0 | +-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 Tesla T4 Off | 00000000:00:1E.0 Off | 0 | | N/A 32C P0 26W / 70W | 0MiB / 15360MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ +-----------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 次に、NVIDIAのカーネルモジュールがロードされていることを確認します。 $ lsmod | grep nvidia # 出力例 nvidia_uvm 2080768 0 nvidia_drm 139264 0 nvidia_modeset 1687552 1 nvidia_drm nvidia 105373696 3 nvidia_uvm,nvidia_drm,nvidia_modeset drm_ttm_helper 20480 1 nvidia_drm video 77824 1 nvidia_modeset 最後に、GPU Operatorの各コンポーネントがドライバとのやり取りに使う libnvidia-ml.so が存在することも確認しておきます（ RKE2 GPU Operators ）。 $ find /usr/ -iname libnvidia-ml.so* # 出力例 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.580.178.04 /usr/lib/x86_64-linux-gnu/libnvidia-ml.so ノードラベリング・テイント設定 GPUを使うアプリケーションだけをGPUノードに配置したい場合は、ラベルとテイントで管理します。ここからの kubectl は、Downstream Clusterのkubeconfigを設定した作業用端末（またはRancher UIのkubectlシェル）で実行します。 ラベルは、ワークロードの nodeSelector や nodeAffinity でGPUノードを指定するために付与します。GPU Operatorの導入後は nvidia.com/gpu.present=true などのラベルも自動で付与されるため、独自ラベルは運用上の必要に応じて付けてください。 $ kubectl label node <GPUノード名> accelerator=nvidia-gpu テイントは、GPUを使わないPodがGPUノードに配置されるのを防ぐために設定します。 $ kubectl taint nodes <GPUノード名> nvidia.com/gpu=dedicated:NoSchedule GPU OperatorのDaemonSetは、デフォルトで nvidia.com/gpu キーの NoSchedule テイントを許容する設定になっているため、このテイントを先に設定しても導入に影響はありません。一方、GPUを使うワークロード側には同じキーの tolerations を設定する必要があります。 NVIDIA GPU Operator 設定手順 まず、閉域内のHarborに次の2つのプロジェクトを作成します。 nvidia-chart ：GPU OperatorのHelmチャート用 nvidia ：GPU Operatorが使うコンテナイメージ用 プロジェクトを非公開にする場合は、Downstream Cluster側にも認証情報の設定が必要です（イメージは registries.yaml 、チャートはHelmChartリソースの認証用フィールド）。 作業用端末からNVIDIA GPU OperatorのHelmチャートをダウンロードします。 $ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia $ helm repo update $ helm pull nvidia/gpu-operator --version v26.3.3 Helmリポジトリにログインし、チャートをOCI形式で登録します。本記事のHarborは自己署名証明書のためTLS検証をスキップしています。 $ helm registry login <Helmリポジトリのドメイン> \ --username <Helmリポジトリのユーザ名> \ --password <Helmリポジトリのパスワード> \ --insecure $ helm push gpu-operator-v26.3.3.tgz oci://<Helmリポジトリのドメイン>/nvidia-chart --insecure-skip-tls-verify 次に、GPU Operatorが使うコンテナイメージを skopeo でコンテナレジストリへコピーします。 コピー元イメージ 使用するコンポーネント nvcr.io/nvidia/gpu-operator:v26.3.3 GPU Operator本体、Operator Validator nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 NVIDIA Container Toolkit nvcr.io/nvidia/k8s-device-plugin:v0.19.3 NVIDIA Device Plugin、GPU Feature Discovery nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless DCGM Exporter registry.k8s.io/nfd/node-feature-discovery:v0.18.3 Node Feature Discovery ${src#*/} で先頭の nvcr.io/ を取り除き、 <コンテナレジストリのドメイン>/nvidia/... という同じ階層でコピーしています。NFDのみ取得元が異なるため、個別にコピーします。 $ REGISTRY=<コンテナレジストリのドメイン> $ skopeo login --tls-verify=false ${REGISTRY} $ for src in \ nvcr.io/nvidia/gpu-operator:v26.3.3 \ nvcr.io/nvidia/k8s/container-toolkit:v1.19.1 \ nvcr.io/nvidia/k8s-device-plugin:v0.19.3 \ nvcr.io/nvidia/k8s/dcgm-exporter:4.5.3-4.8.2-distroless; do skopeo copy --dest-tls-verify=false docker://${src} docker://${REGISTRY}/${src#*/} done $ skopeo copy --dest-tls-verify=false \ docker://registry.k8s.io/nfd/node-feature-discovery:v0.18.3 \ docker://${REGISTRY}/nvidia/node-feature-discovery:v0.18.3 RKE2のHelmChartリソースとして、GPU Operatorのインストール設定を記載した gpu-operator-helm-chart.yaml を作成します。ポイントは次の3点です。 イメージの参照先 ：各コンポーネントの repository を閉域内のレジストリに向けます。 ホスト導入済みドライバの利用 ： driver.enabled: false とし、使わないコンポーネントも無効にして、ミラーが必要なイメージを減らしています。MIG対応GPUを使う場合は migManager を有効にし、 k8s-mig-manager イメージもコピーしてください。 RKE2固有の設定 ：RKE2のcontainerdはソケットの場所が標準と異なるため、 toolkit.env で CONTAINERD_SOCKET を指定します（ RKE2 GPU Operators ）。 devicePlugin.config はタイムスライシングの設定です。 replicas: 4 により、1枚の物理GPUを4つの nvidia.com/gpu として公開し、複数のPodで時分割共有できます。ただし、Pod間でGPUメモリは分離されないため、不要な場合は config ブロックごと削除してください（ Time-Slicing GPUs ）。 apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: gpu-operator namespace: kube-system spec: chart: oci://<Helmリポジトリのドメイン>/nvidia-chart/gpu-operator version: v26.3.3 targetNamespace: gpu-operator createNamespace: true insecureSkipTLSVerify: true valuesContent: |- validator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 operator: repository: <コンテナレジストリのドメイン>/nvidia image: gpu-operator version: v26.3.3 devicePlugin: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 # タイムスライシングを使わない場合はconfigブロックを削除 config: create: true name: "time-slicing-config" default: "t4-sharing" data: t4-sharing: |- version: v1 flags: migStrategy: none sharing: timeSlicing: resources: - name: nvidia.com/gpu replicas: 4 dcgmExporter: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: dcgm-exporter version: 4.5.3-4.8.2-distroless gfd: repository: <コンテナレジストリのドメイン>/nvidia image: k8s-device-plugin version: v0.19.3 toolkit: repository: <コンテナレジストリのドメイン>/nvidia/k8s image: container-toolkit version: v1.19.1 env: - name: CONTAINERD_SOCKET value: /run/k3s/containerd/containerd.sock node-feature-discovery: image: repository: <コンテナレジストリのドメイン>/nvidia/node-feature-discovery tag: v0.18.3 # ホストにドライバを導入済みのため無効化 driver: enabled: false # 本記事では使わないコンポーネント migManager: enabled: false vgpuDeviceManager: enabled: false vfioManager: enabled: false sandboxDevicePlugin: enabled: false kataSandboxDevicePlugin: enabled: false ccManager: enabled: false 作成したHelmChartリソースをDownstream Clusterに適用します。RKE2のHelm Controllerがチャートを取得し、GPU Operatorをインストールします。 $ kubectl apply -f gpu-operator-helm-chart.yaml Container Toolkitは設定を反映するためにcontainerdへ再読み込みを指示し、その影響でGPUノードのRKE2が再起動します。稼働中のワークロードがある場合は、作業タイミングに注意してください。 動作確認 GPU OperatorのPodがすべて Running または Completed になっていることを確認します。出力例はGPUノード2台の環境のものです。 $ kubectl get pod -n gpu-operator # 出力例 NAME READY STATUS RESTARTS AGE gpu-feature-discovery-8t85l 2/2 Running 0 5m gpu-feature-discovery-kkwbb 2/2 Running 0 5m gpu-operator-7974d8cf9-qq7bh 1/1 Running 0 5m gpu-operator-node-feature-discovery-gc-5c84b6f5c4-tmf9k 1/1 Running 0 5m gpu-operator-node-feature-discovery-master-6db6986c58-bjdsg 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-55v8j 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-b944b 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-cxrxs 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-kmmv2 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-qnz9w 1/1 Running 0 5m gpu-operator-node-feature-discovery-worker-wxln9 1/1 Running 0 5m nvidia-container-toolkit-daemonset-4kkbt 1/1 Running 0 5m nvidia-container-toolkit-daemonset-vbgnc 1/1 Running 0 5m nvidia-cuda-validator-b8grf 0/1 Completed 0 5m nvidia-cuda-validator-z7skc 0/1 Completed 0 5m nvidia-dcgm-exporter-6dhd5 1/1 Running 0 5m nvidia-dcgm-exporter-8mhhp 1/1 Running 0 5m nvidia-device-plugin-daemonset-6v4xz 2/2 Running 0 5m nvidia-device-plugin-daemonset-snx4x 2/2 Running 0 5m nvidia-operator-validator-4ldlj 1/1 Running 0 5m nvidia-operator-validator-kctw6 1/1 Running 0 5m GPU Operator全体の状態を表すClusterPolicyが ready になっていることも確認します。 $ kubectl get clusterpolicy # 出力例 NAME STATUS AGE cluster-policy ready <作成日時> 以下のコマンドを実行し、GPUノードのラベルに nvidia.com/gpu.machine などのGPU関連ラベルが付与されていることを確認します。 $ kubectl get node <GPUノード名> -o jsonpath='{.metadata.labels}' | tr ',' '\n' | grep "nvidia.com" # 出力例 "nvidia.com/cuda.driver-version.full":"580.178.04" "nvidia.com/cuda.driver-version.major":"580" "nvidia.com/cuda.driver-version.minor":"178" "nvidia.com/cuda.driver-version.revision":"04" "nvidia.com/cuda.driver.major":"580" "nvidia.com/cuda.driver.minor":"178" "nvidia.com/cuda.driver.rev":"04" "nvidia.com/cuda.runtime-version.full":"13.0" "nvidia.com/cuda.runtime-version.major":"13" "nvidia.com/cuda.runtime-version.minor":"0" "nvidia.com/cuda.runtime.major":"13" "nvidia.com/cuda.runtime.minor":"0" "nvidia.com/gfd.timestamp":"1790646472" "nvidia.com/gpu.compute.major":"7" "nvidia.com/gpu.compute.minor":"5" "nvidia.com/gpu.count":"1" "nvidia.com/gpu.deploy.container-toolkit":"true" "nvidia.com/gpu.deploy.dcgm":"true" "nvidia.com/gpu.deploy.dcgm-exporter":"true" "nvidia.com/gpu.deploy.device-plugin":"true" "nvidia.com/gpu.deploy.driver":"true" "nvidia.com/gpu.deploy.gpu-feature-discovery":"true" "nvidia.com/gpu.deploy.node-status-exporter":"true" "nvidia.com/gpu.deploy.operator-validator":"true" "nvidia.com/gpu.family":"turing" "nvidia.com/gpu.machine":"g4dn.2xlarge" "nvidia.com/gpu.memory":"15360" "nvidia.com/gpu.mode":"compute" "nvidia.com/gpu.present":"true" "nvidia.com/gpu.product":"Tesla-T4-SHARED" "nvidia.com/gpu.replicas":"4" "nvidia.com/gpu.sharing-strategy":"time-slicing" "nvidia.com/mig.capable":"false" "nvidia.com/mig.strategy":"single" "nvidia.com/mps.capable":"false" "nvidia.com/vgpu.present":"false" ノードの割り当て可能リソースに nvidia.com/gpu が追加されていることを確認します。値は「物理GPUの枚数 × タイムスライシングのreplicas」で、本記事では1 × 4 = 4です。タイムスライシングを使わない場合は物理GPUの枚数と一致します。 $ kubectl get node <GPUノード名> -o jsonpath='{.status.allocatable}' # 出力例 {"cpu":"8","ephemeral-storage":"196555267123","hugepages-1Gi":"0","hugepages-2Mi":"0","memory":"32479456Ki","nvidia.com/gpu":"4","pods":"110"} GPUノード上で、NVIDIAコンテナランタイムのバイナリが配置され、RKE2のcontainerd設定にNVIDIAランタイムが追加されていることを確認します。 $ ls /usr/local/nvidia/toolkit/nvidia-container-runtime # 出力例 /usr/local/nvidia/toolkit/nvidia-container-runtime $ grep nvidia /var/lib/rancher/rke2/agent/etc/containerd/config.toml # 出力例 [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime" [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'] [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.'nvidia-cdi'.options] BinaryName = "/usr/local/nvidia/toolkit/nvidia-container-runtime.cdi" おわりに 本記事では、AirGap環境のRKE2クラスタに対して、ホストへのNVIDIA GPU Driverの導入と、HelmChartリソースによるNVIDIA GPU Operatorの導入を行いました。AirGap環境では、依存パッケージを漏れなく集めることと、イメージの参照先をすべて閉域内のレジストリに向けることが主なポイントです。 これで、GPUを使うAIアプリケーションをクラスタ上で動かす準備が整いました。次回はSUSE AI Factoryのインストール方法について解説したいと思います。 参考 About the NVIDIA GPU Operator Installing the NVIDIA GPU Operator Install NVIDIA GPU Operator in Air-Gapped Environments NVIDIA GPU Operator Release Notes NVIDIA GPU Operator Platform Support Time-Slicing GPUs in Kubernetes RKE2 Documentation – GPU Operators nvidia-graphics-drivers-580-server package in Ubuntu（Launchpad） ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post SUSE RancherでのGPUノード設定方法解説 〜AirGap環境へのNVIDIA GPU Driver・GPU Operator導入〜 first appeared on SIOS Tech Lab .