23 SLE Micro上のNVIDIA GPU #
23.1 概要 #
このガイドでは、事前構築済みのオープンソースドライバを使用してホストレベルのNVIDIA GPUサポートをSLE Micro 5.5に実装する方法を説明します。これらのドライバは、NVIDIAのGPU Operatorによって動的にロードされるのではなく、オペレーティングシステムにベイクされているドライバです。この設定は、デプロイメントに必要なすべてのアーティファクトをあらかじめイメージにベイクしておき、ドライバのバージョンを動的に選択する必要がない(つまり、ユーザがKubernetesを介してドライバのバージョンを選択する必要がない)お客様に非常に適しています。このガイドでは最初に、すでに事前にデプロイされているシステムに追加コンポーネントをデプロイする方法を説明しますが、その後のセクションでは、Edge Image Builderを使用してこの設定を初期デプロイメントに組み込む方法について説明します。基本的な操作を読む必要がない場合や、手動でセットアップしたくない場合は、スキップしてそちらのセクションに進んでください。
これらのドライバのサポートは、SUSEとNVIDIAの両社が緊密に連携して提供しており、ドライバはパッケージリポジトリの一部としてSUSEによって構築および出荷されている点を強調しておくことが重要です。ただし、ドライバを使用する組み合わせについて不安や質問がある場合は、SUSEまたはNVIDIAのアカウントマネージャに問い合わせてサポートを受けてください。NVIDIA AI Enterprise (NVAIE)を使用する予定の場合は、NVAIE認定GPUを使用していることを確認してください。NVAIE認定GPUでは、独自のNVIDIAドライバを使用する必要がある「場合があります」。不明な点がある場合は、NVIDIAの担当者に問い合わせてください。
NVIDIA GPU
Operatorの統合の詳細は、このガイドでは説明「しません」。Kubernetes用のNVIDIA GPU
Operatorの統合についてはここでは説明しませんが、このガイドのほとんどの手順に従って、基礎となるオペレーティングシステムをセットアップできます。そして、NVIDIA
GPU
OperatorのHelmチャートのdriver.enabled=false
フラグを使用して「プリインストール」されたドライバをGPU
Operatorが使用できるようにするだけで、ホスト上にインストールされたドライバが取得されます。より包括的な手順については、 NVIDIA
(こちら)で参照できます。さらにSUSEは先日、テクニカルリファレンスドキュメント
(TRD)も公開しました。このドキュメントでは、ご自身のユースケースにGPU
OperatorとNVIDIA独自のドライバが必須の場合にこれらを使用する方法を説明しています。
23.2 前提条件 #
このガイドに従って操作を進める場合、以下がすでに用意されていることを想定しています。
SLE Micro 5.5がインストールされたホストが少なくとも1台。このホストは物理でも仮想でも構いません。
パッケージへのアクセスにはサブスクリプションが必要であるため、ホストがサブスクリプションに接続されていること。評価版は こちらから入手できます。
互換性のあるNVIDIA GPUがインストールされていること(またはSLE Microが実行されている仮想マシンに「完全に」 パススルーされていること)。
ルートユーザへのアクセス — 以下の説明では、自身がルートユーザであり、
sudo
を使用して特権を昇格して「いない」ことを想定しています。
23.3 手動インストール #
このセクションでは、NVIDIAドライバをSLE Microオペレーティングシステムに直接インストールします。これはopen版NVIDIAドライバがSLE Microのコアパッケージリポジトリの一部となったためであり、必須のRPMパッケージをインストールするのと同じように簡単にインストールできるようになりました。実行可能パッケージのコンパイルやダウンロードは必要ありません。以下では、最新のGPUをサポートする「G06」世代ドライバのデプロイについて手順を追って説明します(詳細については こちらを参照してください)。ご使用のシステムに搭載されているNVIDIA GPUに適切なドライバ世代を選択してください。最新のGPUでは、「G06」ドライバが最も一般的な選択肢です。
始める前に、SUSEがSLE
Microの一部として出荷するopen版NVIDIAドライバのほかに、ご自身のセットアップに追加のNVIDIAコンポーネントも必要な場合があることを認識しておくことが重要です。たとえば、OpenGLライブラリ、CUDAツールキット、
nvidia-smi
などのコマンドラインユーティリティ、nvidia-container-toolkit
などのコンテナ統合コンポーネントです。これらのコンポーネントの多くはNVIDIA独自のソフトウェアであるため、SUSEからは出荷されません。また、NVIDIAの代わりにSUSEが出荷しても意味がありません。そのため、説明の一環として、これらのコンポーネントにアクセスできるようにする追加のリポジトリを設定し、これらのツールの使用方法の例をいくつか説明し、完全に機能するシステムを作成します。SUSEのリポジトリとNVIDIAのリポジトリを区別することが重要です。これは、NVIDIAが提供するパッケージのバージョンとSUSEが構築したものが一致しない場合があるためです。これは通常、SUSEがopen版ドライバの新バージョンを利用可能にしたときに発生し、NVIDIAのリポジトリで同等のパッケージが利用可能になるまでに数日かかります。
以下をチェックして、選択するドライババージョンがGPUと互換性があり、CUDAの要件を満たしていることを確認することをお勧めします。
デプロイを予定しているドライババージョンと一致するバージョンがNVIDIA SLE15-SP5リポジトリにあり、サポートコンポーネントと同等のパッケージバージョンが利用可能であることを確認する
open版NVIDIAドライバのバージョンを見つけるには、ターゲットマシンでzypper se -s
nvidia-open-driver
を実行するか、「または」SUSE Customer
CenterのSLE
Micro 5.5 x86_64で「nvidia-open-driver」を検索します。
ここでは、4つのバージョンが利用可能で、545.29.064が最新です。
NVIDIAリポジトリで同等のバージョンが利用可能であることを確認したら、ホストオペレーティングシステムにパッケージをインストールできます。そのためには、transactional-update
セッションを開く必要があります。これにより、基礎となるオペレーティング
システムの読み込み/書き込みスナップショットが新しく作成され、イミュータブルプラットフォームに変更を加えることが可能になります(transactional-update
の詳細については、こちらを参照してください)。
transactional-update shell
transactional-update
シェルを起動したら、NVIDIAからパッケージリポジトリを追加します。これにより、nvidia-smi
などの追加ユーティリティをプルできます。
zypper ar https://download.nvidia.com/suse/sle15sp5/ nvidia-sle15sp5-main zypper --gpg-auto-import-keys refresh
その後、ドライバと、追加ユーティリティのnvidia-compute-utils
をインストールできます。ユーティリティが不要の場合は省略できますが、テスト目的の場合は、この段階でインストールする価値があります。
zypper install -y --auto-agree-with-licenses nvidia-open-driver-G06-signed-kmp nvidia-compute-utils-G06
インストールが失敗する場合、選択したドライババージョンとNVIDIAがリポジトリで配布しているバージョンとの間に依存関係の不一致があることを示している可能性があります。前のセクションを参照して、バージョンが一致していることを確認してください。また、別のドライババージョンをインストールしてみてください。たとえば、NVIDIAリポジトリに以前のバージョンがある場合、インストールコマンドにnvidia-open-driver-G06-signed-kmp=545.29.06
を指定して、一致するバージョンを指定してみることができます。
次に、サポートされているGPUを使用して「いない」場合は(こちらでリストを確認できます)、モジュールレベルでサポートを有効にすることで、ドライバが動作するかどうかを確認できますが、結果はユーザによって異なります。「サポートされている」GPUを使用している場合は、この手順はスキップしてください。
sed -i '/NVreg_OpenRmEnableUnsupportedGpus/s/^#//g' /etc/modprobe.d/50-nvidia-default.conf
これらのパッケージをインストールしたので、transactional-update
セッションを終了します。
exit
次に進む前に、transactional-update
セッションを終了していることを確認してください。
ドライバをインストールしたら、再起動します。SLE Microはイミュータブルオペレーティングシステムであるため、前の手順で作成した新しいスナップショットで再起動する必要があります。ドライバはこの新しいスナップショットにのみインストールされるため、この新しいスナップショットで再起動しないとドライバをロードできません(新しいスナップショットでの再起動は自動的に実行されます)。準備ができたらrebootコマンドを発行します。
reboot
システムが正常に再起動したら、ログインし直し、
nvidia-smi
ツールを使用して、ドライバが正常にロードされていて、GPUへのアクセスと列挙をどちらも実行できることを確認します。
nvidia-smi
このコマンドの出力は次のような出力になります。以下の例では、GPUが2つあることに注意してください。
Wed Feb 28 12:31:06 2024 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 545.29.06 Driver Version: 545.29.06 CUDA Version: 12.3 | |-----------------------------------------+----------------------+----------------------+ | 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 NVIDIA A100-PCIE-40GB Off | 00000000:17:00.0 Off | 0 | | N/A 29C P0 35W / 250W | 4MiB / 40960MiB | 0% Default | | | | Disabled | +-----------------------------------------+----------------------+----------------------+ | 1 NVIDIA A100-PCIE-40GB Off | 00000000:CA:00.0 Off | 0 | | N/A 30C P0 33W / 250W | 4MiB / 40960MiB | 0% Default | | | | Disabled | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | No running processes found | +---------------------------------------------------------------------------------------+
これで、SLE MicroシステムへのNVIDIAドライバのインストールと検証プロセスは完了です。
23.4 手動インストールの追加検証 #
この段階で確認できるのは、ホストレベルでNVIDIAデバイスにアクセスできること、およびドライバが正常にロードされていることだけです。ただし、それが機能していることを確認したい場合は、簡単なテストを実施して、GPUがユーザスペースアプリケーションから、理想的にはコンテナ経由で命令を受け取れること、および実際のワークロードが通常使用するものであるCUDAライブラリを通じて命令を受け取れることを検証します。このためには、nvidia-container-toolkit
(NVIDIA
Container
Toolkit)をインストールしてホストOSにさらに変更を加えることができます。まず、別のtransactional-update
シェルを開きます。前の手順ではこれを1つのトランザクションで実行できたことに注目し、後のセクションでこれを完全に自動的に実行する方法を確認します。
transactional-update shell
次に、NVIDIA Container
Toolkitリポジトリからnvidia-container-toolkit
パッケージをインストールします。
次の
nvidia-container-toolkit.repo
には、安定版(nvidia-container-toolkit
)と実験版(nvidia-container-toolkit-experimental
)のリポジトリが含まれています。運用環境での使用には、安定版リポジトリをお勧めします。実験版リポジトリはデフォルトで無効になっています。
zypper ar https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo zypper --gpg-auto-import-keys install -y nvidia-container-toolkit
準備ができたら、transactional-update
シェルを終了できます。
exit
…そして新しいスナップショットでマシンを再起動します。
reboot
前述同様に、変更を有効にするには、必ずtransactional-shell
を終了し、マシンを再起動する必要があります。
マシンが再起動したら、システムがNVIDIA Container Toolkitを使用してデバイスを正常に列挙できることを確認できます。出力は詳細で、INFOとWARNのメッセージがありますが、ERRORのメッセージはありません。
nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
これにより、そのマシンで起動するコンテナはすべて、検出されたNVIDIA
GPUデバイスを使用できることが確認されます。準備ができたら、podmanベースのコンテナを実行できます。これをpodman
を介して行うことで、コンテナ内からNVIDIAデバイスへのアクセスを効果的に検証することができ、後の段階でKubernetesで同じ操作を実行するための自信が得られます。podman
に対し、前のコマンドでSLE
BCIに基づいて処理したラベル付きのNVIDIAデバイスへのアクセス権を与え、バッシュコマンドを実行します。
podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable -it registry.suse.com/bci/bci-base:latest bash
続いて、一時的なpodmanコンテナ内からコマンドを実行します。このコンテナは基盤となるシステムにはアクセスできず一時的であるため、ここで行う操作は永続せず、基盤となるホスト上にあるものを壊すことは一切できないはずです。現在はコンテナ内で作業しているため、必要なCUDAライブラリをインストールできます。ここでもう一度、ご使用のドライバにあったCUDAバージョンをこちらで確認してください。ただし、必要なCUDAバージョンはnvidia-smi
の前の出力に表示されているはずです。以下の例では、CUDA
12.3をインストールして多数の例、デモ、開発キットをプルし、GPUを完全に検証できるようにしています。
zypper ar http://developer.download.nvidia.com/compute/cuda/repos/sles15/x86_64/ cuda-sle15-sp5 zypper in -y cuda-libraries-devel-12-3 cuda-minimal-build-12-3 cuda-demo-suite-12-3
これが正常にインストールされた後にコンテナを終了しないでください。deviceQuery
CUDAの例を実行し、CUDAを介して、およびコンテナ自体からGPUアクセスを包括的に検証します。
/usr/local/cuda-12/extras/demo_suite/deviceQuery
成功すると、次のような出力が表示されます。コマンドの最後にある「Result =
PASS
」というメッセージに注意してください。また、次の出力では2つのGPUが正しく識別されていますが、ご使用の環境では1つしかない場合があることにも注意してください。
/usr/local/cuda-12/extras/demo_suite/deviceQuery Starting... CUDA Device Query (Runtime API) version (CUDART static linking) Detected 2 CUDA Capable device(s) Device 0: "NVIDIA A100-PCIE-40GB" CUDA Driver Version / Runtime Version 12.2 / 12.1 CUDA Capability Major/Minor version number: 8.0 Total amount of global memory: 40339 MBytes (42298834944 bytes) (108) Multiprocessors, ( 64) CUDA Cores/MP: 6912 CUDA Cores GPU Max Clock rate: 1410 MHz (1.41 GHz) Memory Clock rate: 1215 Mhz Memory Bus Width: 5120-bit L2 Cache Size: 41943040 bytes Maximum Texture Dimension Size (x,y,z) 1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384) Maximum Layered 1D Texture Size, (num) layers 1D=(32768), 2048 layers Maximum Layered 2D Texture Size, (num) layers 2D=(32768, 32768), 2048 layers Total amount of constant memory: 65536 bytes Total amount of shared memory per block: 49152 bytes Total number of registers available per block: 65536 Warp size: 32 Maximum number of threads per multiprocessor: 2048 Maximum number of threads per block: 1024 Max dimension size of a thread block (x,y,z): (1024, 1024, 64) Max dimension size of a grid size (x,y,z): (2147483647, 65535, 65535) Maximum memory pitch: 2147483647 bytes Texture alignment: 512 bytes Concurrent copy and kernel execution: Yes with 3 copy engine(s) Run time limit on kernels: No Integrated GPU sharing Host Memory: No Support host page-locked memory mapping: Yes Alignment requirement for Surfaces: Yes Device has ECC support: Enabled Device supports Unified Addressing (UVA): Yes Device supports Compute Preemption: Yes Supports Cooperative Kernel Launch: Yes Supports MultiDevice Co-op Kernel Launch: Yes Device PCI Domain ID / Bus ID / location ID: 0 / 23 / 0 Compute Mode: < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > Device 1: <snip to reduce output for multiple devices> < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) > > Peer access from NVIDIA A100-PCIE-40GB (GPU0) -> NVIDIA A100-PCIE-40GB (GPU1) : Yes > Peer access from NVIDIA A100-PCIE-40GB (GPU1) -> NVIDIA A100-PCIE-40GB (GPU0) : Yes deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 12.3, CUDA Runtime Version = 12.3, NumDevs = 2, Device0 = NVIDIA A100-PCIE-40GB, Device1 = NVIDIA A100-PCIE-40GB Result = PASS
ここから、続いて他のCUDAワークロードを実行できます。コンパイラやCUDAエコシステムの他の側面を使用して、さらにテストを実行できます。完了したら、コンテナを終了できます。コンテナにインストールしたものはすべて一時的なものであるため(したがって失われるため)、基盤となるオペレーティングシステムには影響がないことに注意してください。
exit
23.5 Kubernetesを使用した実装 #
open版NVIDIAドライバをSLE
Microにインストールして使用できることが証明されたので、同じマシンにKubernetesを設定してみましょう。このガイドでは、Kubernetesのデプロイについては説明しませんが、K3sまたはRKE2をインストール済みで、kubeconfigが適宜設定されており、標準のkubectl
コマンドをスーパーユーザとして実行できることを前提としています。ここではノードがシングルノードクラスタを形成していることを想定していますが、中心となる手順はマルチノードクラスタでも同様です。まず、kubectl
のアクセスが機能していることを確認します。
kubectl get nodes
次のような画面が表示されます。
NAME STATUS ROLES AGE VERSION node0001 Ready control-plane,etcd,master 13d v1.28.9+rke2r1
k3s/rke2のインストールによってホスト上のNVIDIA Container
Toolkitが検出され、NVIDIAランタイム統合がcontainerd
(k3s/rke2が使用するContainer Runtime
Interface)に自動設定されていることを確認する必要があります。確認するには、containerdのconfig.toml
ファイルをチェックします。
tail -n8 /var/lib/rancher/rke2/agent/etc/containerd/config.toml
次のような画面が表示される必要があります。K3sの場合に相当する場所は/var/lib/rancher/k3s/agent/etc/containerd/config.toml
です。
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia"] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia".options] BinaryName = "/usr/bin/nvidia-container-runtime"
これらのエントリが存在しない場合は、検出が失敗している可能性があります。この原因として考えられるのは、マシンまたはKubernetesサービスを再起動していないことです。必要に応じて、上記のようにこれらを手動で追加してください。
次に、NVIDIA
RuntimeClass
を追加のKubernetesランタイムとしてデフォルト値に設定する必要があります。これにより、GPUへのアクセスが必要なPodに対するユーザ要求が、
containerd
の設定に従って、NVIDIA Container
Toolkitを使用してnvidia-container-runtime
を介してアクセスできるようにします。
kubectl apply -f - <<EOF apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: nvidia handler: nvidia EOF
次の手順は、NVIDIA Device Pluginを設定することです。これにより、NVIDIA Container Toolkitと連携して、クラスタ内で使用可能なリソースとしてNVIDIA GPUを利用するようにKubernetesを設定します。このツールはまず、基盤となるホスト上のすべての機能(GPU、ドライバ、その他の機能(GLなど)を含む)を検出し、その後、ユーザがGPUリソースを要求してアプリケーションの一部として使用できるようにします。
まず、NVIDIA Device Plugin用のHelmリポジトリを追加して更新する必要があります。
helm repo add nvdp https://nvidia.github.io/k8s-device-plugin helm repo update
これで、NVIDIA Device Pluginをインストールできます。
helm upgrade -i nvdp nvdp/nvidia-device-plugin --namespace nvidia-device-plugin --create-namespace --version 0.14.5 --set runtimeClassName=nvidia
数分後、新しいPodが実行されているのがわかります。これで、利用可能なノード上での検出は完了し、検出されたGPUの数を示すタグがノードに付けられます。
kubectl get pods -n nvidia-device-plugin NAME READY STATUS RESTARTS AGE nvdp-nvidia-device-plugin-jp697 1/1 Running 2 (12h ago) 6d3h kubectl get node node0001 -o json | jq .status.capacity { "cpu": "128", "ephemeral-storage": "466889732Ki", "hugepages-1Gi": "0", "hugepages-2Mi": "0", "memory": "32545636Ki", "nvidia.com/gpu": "1", <---- "pods": "110" }
これで、このGPUを使用するNVIDIA Podを作成する準備ができました。CUDA Benchmarkコンテナで試してみましょう。
kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: nbody-gpu-benchmark namespace: default spec: restartPolicy: OnFailure runtimeClassName: nvidia containers: - name: cuda-container image: nvcr.io/nvidia/k8s/cuda-sample:nbody args: ["nbody", "-gpu", "-benchmark"] resources: limits: nvidia.com/gpu: 1 env: - name: NVIDIA_VISIBLE_DEVICES value: all - name: NVIDIA_DRIVER_CAPABILITIES value: all EOF
すべて問題なければ、ログを見て、ベンチマーク情報を確認できます。
kubectl logs nbody-gpu-benchmark Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance. -fullscreen (run n-body simulation in fullscreen mode) -fp64 (use double precision floating point values for simulation) -hostmem (stores simulation data in host memory) -benchmark (run benchmark to measure performance) -numbodies=<N> (number of bodies (>= 1) to run in simulation) -device=<d> (where d=0,1,2.... for the CUDA device to use) -numdevices=<i> (where i=(number of CUDA devices > 0) to use for simulation) -compare (compares simulation results running once on the default GPU and once on the CPU) -cpu (run n-body simulation on the CPU) -tipsy=<file.bin> (load a tipsy model file for simulation) NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled. > Windowed mode > Simulation data stored in video memory > Single precision floating point simulation > 1 Devices used for simulation GPU Device 0: "Turing" with compute capability 7.5 > Compute 7.5 CUDA device: [Tesla T4] 40960 bodies, total time for 10 iterations: 101.677 ms = 165.005 billion interactions per second = 3300.103 single-precision GFLOP/s at 20 flops per interaction
最後に、アプリケーションでOpenGLが必要な場合は、必要なNVIDIA OpenGLライブラリをホストレベルでインストールし、 NVIDIA Device PluginとNVIDIA Container Toolkitを使用してそのライブラリをコンテナで利用できるようにすることができます。これを行うには、次のようにパッケージをインストールします。
transactional-update pkg install nvidia-gl-G06
このパッケージをアプリケーションで使用できるようにするには再起動が必要です。NVIDIA Device Pluginは、NVIDIA Container Toolkitを介してこれを自動的に再検出します。
23.6 Edge Image Builderを使用した統合 #
さて、SLE Micro上のアプリケーションとGPUの全機能をデモで示したので、 第9章 「Edge Image Builder」を使用してすべてをまとめ、デプロイ可能/使用可能なISOまたはRAWディスクイメージで提供したいと思います。このガイドでは、Edge Image Builderの使用方法は説明せずに、このようなイメージを構築するために必要な設定について説明します。以下に、必要なすべてのコンポーネントを追加設定なしにデプロイするためのイメージ定義の例と、必要なKubernetes設定ファイルを示します。以下に示す例では、Edge Image Builderディレクトリは次のようなディレクトリ構造になっています。
. ├── base-images │ └── SLE-Micro.x86_64-5.5.0-Default-SelfInstall-GM2.install.iso ├── eib-config-iso.yaml ├── kubernetes │ ├── config │ │ └── server.yaml │ ├── helm │ │ └── values │ │ └── nvidia-device-plugin.yaml │ └── manifests │ └── nvidia-runtime-class.yaml └── rpms └── gpg-keys └── nvidia-container-toolkit.key
これらのファイルを調べてみましょう。まず、K3sを実行するシングルノードクラスタのサンプルイメージ定義を次に示します。このイメージ定義では、ユーティリティとOpenGLパッケージもデプロイします(eib-config-iso.yaml
)。
apiVersion: 1.0
image:
arch: x86_64
imageType: iso
baseImage: SLE-Micro.x86_64-5.5.0-Default-SelfInstall-GM2.install.iso
outputImageName: deployimage.iso
operatingSystem:
time:
timezone: Europe/London
ntp:
pools:
- 2.suse.pool.ntp.org
isoConfiguration:
installDevice: /dev/sda
users:
- username: root
encryptedPassword: $6$XcQN1xkuQKjWEtQG$WbhV80rbveDLJDz1c93K5Ga9JDjt3mF.ZUnhYtsS7uE52FR8mmT8Cnii/JPeFk9jzQO6eapESYZesZHO9EslD1
packages:
packageList:
- nvidia-open-driver-G06-signed-kmp-default
- nvidia-compute-utils-G06
- nvidia-gl-G06
- nvidia-container-toolkit
additionalRepos:
- url: https://download.nvidia.com/suse/sle15sp5/
- url: https://nvidia.github.io/libnvidia-container/stable/rpm/x86_64
sccRegistrationCode: <snip>
kubernetes:
version: v1.28.9+k3s1
helm:
charts:
- name: nvidia-device-plugin
version: v0.14.5
installationNamespace: kube-system
targetNamespace: nvidia-device-plugin
createNamespace: true
valuesFile: nvidia-device-plugin.yaml
repositoryName: nvidia
repositories:
- name: nvidia
url: https://nvidia.github.io/k8s-device-plugin
これは単なる例です。要件や期待に合うようにカスタマイズする必要がある場合があります。また、SLE
Microを使用する場合は、パッケージの依存関係を解決してNVIDIAドライバをプルするために、独自の
sccRegistrationCode
を指定する必要があります。
これに加えて、他のコンポーネントを追加して、ブート時にKubernetesによってロードされるようにする必要があります。EIBディレクトリにはまずkubernetes
ディレクトリが必要で、その下に設定、Helmチャート値、必要な追加のマニフェスト用のサブディレクトリが必要です。
mkdir -p kubernetes/config kubernetes/helm/values kubernetes/manifests
CNIを選択し(選択しない場合はデフォルトでCiliumになります)、SELinuxを有効にして、(オプションの)Kubernetes設定を行いましょう。
cat << EOF > kubernetes/config/server.yaml cni: cilium selinux: true EOF
続いて、NVIDIA RuntimeClassがKubernetesクラスタ上に作成されていることを確認します。
cat << EOF > kubernetes/manifests/nvidia-runtime-class.yaml apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: nvidia handler: nvidia EOF
ビルトインHelmコントローラを使用して、Kubernetes自体を使用してNVIDIA Device Pluginをデプロイします。チャートの値ファイルでランタイムクラスを指定しましょう。
cat << EOF > kubernetes/helm/values/nvidia-device-plugin.yaml runtimeClassName: nvidia EOF
次に進む前に、NVIDIA Container Toolkit RPMの公開鍵を取得する必要があります。
mkdir -p rpms/gpg-keys curl -o rpms/gpg-keys/nvidia-container-toolkit.key https://nvidia.github.io/libnvidia-container/gpgkey
Kubernetesバイナリ、コンテナイメージ、Helmチャート(および参照イメージ)など、必要なアーティファクトがすべて自動的にエアギャップ化されます。つまり、デプロイ時のシステムにはデフォルトでインターネット接続は不要です。ここで必要なのはSUSEダウンロードページからSLE
Micro
ISOを取得する(そしてそれをbase-images
ディレクトリに配置する)ことだけです。そうすれば、Edge
Image Builderツールを呼び出してISOを生成できます。この例を完了するために、イメージの構築に使用したコマンドを次に示します。
podman run --rm --privileged -it -v /path/to/eib-files/:/eib \ registry.suse.com/edge/edge-image-builder:1.0.2 \ build --definition-file eib-config-iso.yaml
Edge Image Builderの詳細については、ドキュメントを参照してください。
23.7 問題の解決 #
23.7.1 nvidia-smiでGPUが検出されない #
dmesg
を使用してカーネルメッセージを確認します。NvKMSKapDevice
を割り当てることができないことを示している場合は、サポート対象外のGPUの回避策を適用します。
sed -i '/NVreg_OpenRmEnableUnsupportedGpus/s/^#//g' /etc/modprobe.d/50-nvidia-default.conf
メモ: 上記の手順でカーネルモジュールの設定を変更した場合は、変更を有効にするために、カーネルモジュールを再ロードするか、再起動する必要があります。