23 SLE Micro 上的 NVIDIA GPU #

23.1 简介 #

本指南将演示如何通过预构建的开源驱动程序在 SLE Micro 5.5 上实现主机级别的 NVIDIA GPU 支持。这些驱动程序将植入到操作系统中，而不是由 NVIDIA 的 GPU Operator 动态加载。对于想要将部署所需的所有项目预先植入映像，并且不需要动态选择驱动程序版本（即，由用户通过 Kubernetes 选择驱动程序版本）的客户而言，此配置非常理想。本指南首先介绍如何将其他组件部署到已预先部署的系统，然后使用一个章节介绍如何通过 Edge Image Builder 将此配置嵌入到初始部署中。如果您不想了解基础知识并想要手动完成设置，请直接跳到该章节。

必须指出的是，这些驱动程序的支持工作由 SUSE 和 NVIDIA 在密切合作的前提下提供，而驱动程序由 SUSE 构建并作为软件包储存库的一部分交付。但是，如果您在使用驱动程序期间在这两方面有任何疑虑或问题，请咨询您的 SUSE 或 NVIDIA 客户经理以获得进一步的帮助。如果您打算使用 NVIDIA AI Enterprise (NVAIE)，请确保使用 NVAIE 认证的 GPU，这可能需要使用专有的 NVIDIA 驱动程序。如果您不确定，请咨询您的 NVIDIA 代表。

本指南不会介绍有关 NVIDIA GPU Operator 集成的更多信息。虽然其中不会介绍如何为 Kubernetes 集成 NVIDIA GPU Operator，但您仍然可以按照本指南中的大部分步骤来设置底层操作系统，并通过 NVIDIA GPU Operator Helm chart 中的 driver.enabled=false 标志来让 GPU Operator 使用预安装的驱动程序，在这种情况下，GPU Operator 会直接选择主机上安装的驱动程序。NVIDIA 在此处提供了更详细的说明。SUSE 最近还发布了一份技术参考文档 (TRD)，其中介绍了如何使用 GPU Operator 和 NVIDIA 专有的驱动程序，您可以根据用例的要求参考此文档。

23.2 先决条件 #

如果您要学习本指南，事先需要做好以下准备：

至少一台装有 SLE Micro 5.5 的主机，可以是物理主机，也可以是虚拟主机。
您的主机已附加到某个订阅，只有这样，才能访问软件包 — 可在此处进行评估。
已安装兼容的 NVIDIA GPU（或完全直通到运行 SLE Micro 的虚拟机）。
root 用户访问权限 — 本章中的说明假设您是 root 用户，而不是通过 sudo 提升了的特权。

23.3 手动安装 #

本节介绍如何直接将 NVIDIA 驱动程序安装到 SLE Micro 操作系统上，因为 NVIDIA 开放驱动程序现在包含在核心 SLE Micro 软件包储存库中，因此，只需安装所需的 RPM 软件包就能安装这些驱动程序。无需编译或下载可执行软件包。下面介绍如何部署支持最新 GPU 的第六代 (G06) 驱动程序（有关更多信息，请参见此处），请选择适合您系统中的 NVIDIA GPU 的驱动程序代系。对于新式 GPU，“G06”驱动程序是最常见的选择。

在开始之前，必须知道的是，除了 SUSE 作为 SLE Micro 一部分交付的 NVIDIA 开放驱动程序之外，您可能还需要将其他 NVIDIA 组件用于设置。这些组件可能包括 OpenGL 库、CUDA 工具包、命令行实用程序（例如 nvidia-smi）和容器集成组件（例如 nvidia-container-toolkit）。其中许多组件不是由 SUSE 交付，因为它们是专有的 NVIDIA 软件，或者我们代替 NVIDIA 交付这些软件毫无意义。因此在说明中，我们将配置其他一些用于访问所述组件的储存库，并讲解一些示例来介绍这些工具的用法，以得到一个功能完备的系统。必须能够区分 SUSE 储存库和 NVIDIA 储存库，因为 NVIDIA 提供的软件包版本与 SUSE 构建的版本有时不匹配。这种情况通常发生在 SUSE 推出新的开放驱动程序版本时，需要经过几天时间，NVIDIA 储存库中才会提供匹配的同等软件包。

我们建议您采取以下措施来确保所选驱动程序版本与您的 GPU 兼容并符合现有的任何 CUDA 要求：

查看 CUDA 发行说明
检查您要部署的驱动程序版本是否在 NVIDIA SLE15-SP5 储存库中有匹配的版本，并确保支持组件有可用的同等软件包版本

提示

要查找 NVIDIA 开放驱动程序版本，请在目标计算机上运行 zypper se -s nvidia-open-driver，或者在 SLE Micro 5.5 for x86_64 的 SUSE Customer Center 中搜索“nvidia-open-driver”。

在此处，您会看到四个可用版本，其中 545.29.06 是最新版本：

在确认 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 储存库中有较低的版本，您可以尝试在 install 命令中指定 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：

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) 来进一步修改主机操作系统。首先，打开另一个 transactional-update 外壳，请注意，在上一步骤中我们可能是通过单个事务执行了此操作，后面的章节将介绍如何完全自动地执行此操作：

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-update 外壳并重引导计算机，使更改生效。

重引导计算机后，可以校验系统是否可以使用 NVIDIA Container Toolkit 成功枚举设备。输出应该非常详细，包含 INFO 和 WARN 讯息，但不包含 ERROR 讯息：

nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

这会确保计算机上启动的任何容器都可以采用已发现的 NVIDIA GPU 设备。准备就绪后，可以运行基于 podman 的容器。通过 podman 执行此操作可以方便地从容器内部验证对 NVIDIA 设备的访问，稍后还可以自信地对 Kubernetes 执行同样的操作。根据 SLE BCI，为 podman 授予对上一条命令处理过的带标签 NVIDIA 设备的访问权限，然后直接运行 Bash 命令：

podman run --rm --device nvidia.com/gpu=all --security-opt=label=disable -it registry.suse.com/bci/bci-base:latest bash

现在，您将从临时 podman 容器内部执行命令。该容器无权访问您的底层系统，并且是临时性的，因此我们在此处执行的所有操作都不会保存，并且您无法破坏底层主机上的任何设置。由于我们现在处于容器中，因此可以安装所需的 CUDA 库。请再次对照此页面检查驱动程序的 CUDA 版本是否正确，不过，先前 nvidia-smi 命令的输出应该也会显示所需的 CUDA 版本。以下示例将安装 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 讯息，并注意在以下输出中，系统正确识别了两个 GPU，而您的环境中可能只有一个 GPU：

/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 实现 #

确认已在 SLE Micro 上安装并使用 NVIDIA 开放驱动程序后，我们来了解如何在同一台计算机上配置 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 使用的容器运行时接口）中。这一点可以通过检查 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 服务未重启动。如果需要，请如前所述手动添加这些项。

接下来，我们需要将作为附加 Kubernetes 运行时的 NVIDIA RuntimeClass 配置为默认设置，以确保需要访问 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，该插件会将 Kubernetes 配置为利用 NVIDIA GPU 作为群集中可用的资源，并与 NVIDIA Container Toolkit 配合工作。此工具最初会检测底层主机上的所有功能，包括 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"
}

现在，可以创建一个 NVIDIA Pod 来尝试使用此 GPU。我们来尝试在 CUDA 基准容器上执行此操作：

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 将所有组件融合到一起 #

现在您已展示了您的应用程序和 GPU 在 SLE Micro 上的完整功能，接下来可以使用第 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，则您需要提供自己的 sccRegistrationCode 来解析软件包依赖项并提取 NVIDIA 驱动程序。

除此之外，还需要添加其他组件，供 Kubernetes 在引导时加载。首先需要为 EIB 目录创建 kubernetes 目录，其中包含配置、Helm chart 值和任何其他所需清单的子目录：

mkdir -p kubernetes/config kubernetes/helm/values kubernetes/manifests

现在我们来通过选择 CNI（如果未选择，则默认为 Cilium）并启用 SELinux 来设置（可选的）Kubernetes 配置：

cat << EOF > kubernetes/config/server.yaml
cni: cilium
selinux: true
EOF

现在确保在 Kubernetes 群集上创建 NVIDIA RuntimeClass：

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。我们需要在 chart 的 values 文件中提供运行时类：

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 chart（以及所有引用的映像），这意味着在部署时，系统默认不需要互联网连接。现在您只需从 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

注意：如果您在上述步骤中更改了内核模块配置，则需要重新加载或重引导内核模块才能使更改生效。