Alauda GPU Management
  • 简体中文

    • 配置 Driver 模式

    Alauda GPU Management 支持三种 driver 模式。driver 来源和准备方式会因模式而异。在创建 ClusterPolicy 实例之前，请先选择一种模式；本页记录每种模式的工作机制。关于如何做出选择，请参见 Install 中的模式表。

    目录

    模式 1：预编译 driver（不可变 OS）模式 2：预安装的主机 driver模式 3：上游 driver（可变 OS）配置 toolkit 和 driver 路径支持边界

    模式 1：预编译 driver（不可变 OS）

    对于 SUSE Linux Micro 这类不可变操作系统，请使用此模式，因为主机镜像必须保持不变。operator 会部署一个预编译的 driver 镜像，其 kernel module 是针对目标 node 的确切 kernel 构建的。

    预编译 driver 镜像具有特定 kernel 依赖性：为某个 kernel 构建的镜像无法在其他任何 kernel 上加载。其 tag 编码了 driver 版本（包括 Alauda 修订版本）、完整的 kernel release（SUSE -default flavor 是 kernel release 的一部分，而不是 OS）以及操作系统：

    <driver-version>-<kernel-release>-<os>
# example:
580.126.09.1-5.14.21-150500.55.166-default-sle-micro5.5

    • 产品包随附本版本验证过的 driver tuple：580.126.09.1-5.14.21-150500.55.166-default-sle-micro5.5（R580、SUSE Linux Micro 5.5、kernel 5.14.21-150500.55.166）。为控制包大小，不会捆绑其他 tuple。

    • 其他 tuple 已发布到 Docker Hub：alaudadockerhub/nvidia-driver。对于此 kernel，R570 版本发布为 570.172.08.1-5.14.21-150500.55.166-default-sle-micro5.5。请导入所需版本并将其映射到集群 registry：

      SOURCE_IMAGE=alaudadockerhub/nvidia-driver:580.126.09.1-5.14.21-150500.55.166-default-sle-micro5.5
TARGET_IMAGE=<your-cluster-registry>/mlops/nvidia-driver:580.126.09.1-5.14.21-150500.55.166-default-sle-micro5.5

skopeo copy docker://$SOURCE_IMAGE docker://$TARGET_IMAGE
skopeo inspect docker://$TARGET_IMAGE

      已发布的 tag 只是镜像清单中的一项记录，本身并不代表对你的集群已获得支持或验证。使用前，请确认 driver 版本、kernel 和 OS 与你的 node 匹配。

    • driver 版本由你选择；kernel 和 OS 是 node 的事实。 请提供工作负载所需的 driver 版本——例如 R580（580.126.09.1，随产品包提供）或 R570（570.172.08.1，从 Docker Hub 导入）。tag 中的 kernel 和 OS 部分必须与 node 完全一致，这不是你可以选择的值。如果你的 node kernel 没有已发布的 tuple，请提供 uname -r 和 GPU 型号联系 Alauda Customer Support 申请按需构建；对于未经测试的 kernel，不会预先发布 tuple。

    • 内容：SUSE 签名的开源 kernel module（MIT/GPLv2）以及未修改的 NVIDIA 官方 user-space 包。每个 tuple 镜像都包含 /licenses/，其中提供完整的 NVIDIA driver 许可证和包清单。使用该镜像即表示接受该许可证，包括仅限与 NVIDIA 硬件一起使用。

    • 选择方式：通过 driver spec 配置 driver（ClusterPolicy.spec.driver，或者在 useNvidiaDriverCRD=true 时使用 NVIDIADriver CR；deployDefaultCR=false 表示不会自动部署 driver）。将 repository 设置为你复制镜像到的 registry（例如 <your-cluster-registry>/mlops），将 image 设置为 nvidia-driver，并将 version 设置为 tag 中的 driver-version 部分（例如 580.126.09.1 或 570.172.08.1）。operator 会直接从该 registry 解析并拉取 <repository>/<image>:<version>-<node-kernel>-<node-os>。如果 ACP 实施了镜像白名单策略，也请将导入的 driver tag 添加到 ImageWhiteList 中。

    driver Pod 启动后，请同时验证已准入的 Pod image 和运行时的 imageID。仅重写 Pod image 并不能证明已拉取到预期镜像：

    kubectl get pods -l app=nvidia-driver-daemonset \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\t"}{.status.containerStatuses[0].imageID}{"\n"}{end}'

    模式 2：预安装的主机 driver

    当 GPU driver 在 operator 之外完成安装和升级时，请使用此模式。operator 仅管理运行时集成以及面向 Kubernetes 的组件。

    • 在 ClusterPolicy 中设置 driver.enabled=false。

    • operator 不会创建 driver DaemonSet。在启用 device plugin、runtime integration 或 metrics 之前，请先确认每个 GPU node 上都已安装并健康运行主机 driver：

      nvidia-smi

    • driver 生命周期（安装、升级、kernel 兼容性）遵循安装主机 driver 的系统流程。关于此模式下 operator 负责与不负责的内容，请参见 driver / toolkit boundary。

    模式 3：上游 driver（可变 OS）

    对于可变操作系统（如 Ubuntu），请使用此模式。driver 镜像由 NVIDIA 在 nvcr.io 上提供；Alauda 不会复制或托管该镜像。这与 Red Hat OpenShift certified GPU Operator 使用的模型一致。此模式可配置，但在本版本中未验证。

    在线集群 — 在 ClusterPolicy.spec.driver 上设置 driver 值，以便 operator 拉取上游镜像并在 node 上构建 module：

    usePrecompiled: false
repository: nvcr.io/nvidia
image: driver
version: "580.126.20"   # the operator appends the OS suffix, e.g. -ubuntu22.04

    最终生成的组合（例如 nvcr.io/nvidia/driver:580.126.20-ubuntu22.04）必须存在于 NGC 中。node 会在运行时拉取该镜像；拉取动作即为客户接受 NVIDIA 条款的时点。

    空气隔离集群 — cluster administrator 按照 NVIDIA 的空气隔离文档，从可访问互联网的机器将镜像镜像到私有 registry：

    docker pull nvcr.io/nvidia/driver:580.126.20-ubuntu22.04
docker tag  nvcr.io/nvidia/driver:580.126.20-ubuntu22.04 <private-registry>/nvidia/driver:580.126.20-ubuntu22.04
docker push <private-registry>/nvidia/driver:580.126.20-ubuntu22.04
# then set driver.repository to <private-registry>/nvidia

    请保持镜像后的 tag 与 NVIDIA 原始 tag 完全一致，以便进行版本跟踪和升级。在此模式下，driver 会在 node 上编译 kernel module，因此空气隔离集群还需要将 driver.repoConfig 指向内部 package source，该 source 必须包含目标 kernel headers；否则 driver 无法完成安装。

    配置 toolkit 和 driver 路径

    container toolkit 的安装路径与 driver 的安装路径是相互独立的设置。仅当 node 布局要求的路径与默认值不同时，才需要进行配置。

    spec:
  toolkit:
    # Toolkit binaries, including nvidia-container-runtime.
    installDir: /usr/local/nvidia
  hostPaths:
    # Driver files when the operator manages the driver.
    driverInstallDir: /run/nvidia/driver
    • spec.toolkit.installDir 控制 toolkit binaries 和 containerd runtime 的 BinaryName。在 Ubuntu 这类可变系统上，默认值为 /usr/local/nvidia。在 SUSE Linux Micro 这类不可变系统上，随附的 profile 使用 /run/nvidia/toolkit-install，因为 /usr/local 是只读的。
    • spec.hostPaths.driverInstallDir 指定 operator 管理的 driver 组件的 driver 文件根目录。当 driver.enabled=false 且 driver 已预安装在主机上时，不需要此项。其默认值为 /run/nvidia/driver。
    • 自定义路径必须存在于主机上，且对安装文件的组件可写；如果其中包含会被 operator 或 runtime 调用的程序，则挂载必须具有可执行权限（exec）。诸如 0755 的目录模式无法覆盖 noexec 挂载。

    例如，在 /run 以 noexec 挂载的 Ubuntu node 上，除非 driver 本身存在独立的 /run 执行失败问题，否则请保持 driver 路径不变，并将 toolkit 路径设置为可变文件系统：

    spec:
  driver:
    enabled: false # set true only when the operator installs the driver
  toolkit:
    enabled: true
    installDir: /usr/local/nvidia

    更改路径后，请验证 ClusterPolicy、渲染后的 Toolkit DaemonSet 以及 containerd drop-in。runtime 的 BinaryName 必须引用所选的 toolkit 目录，且目标挂载不能包含 noexec：

    kubectl get clusterpolicy \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.toolkit.installDir}{"\n"}{end}'
findmnt -T /usr/local/nvidia/toolkit/nvidia-container-runtime
grep -n 'BinaryName' /etc/containerd/conf.d/99-nvidia.toml

    支持边界

    • NVIDIA driver software 仅授权用于 NVIDIA 硬件（NVIDIA Driver License）。
    • GeForce/Titan 系列 software 不授权用于数据中心部署（blockchain-processing 场景除外）。受支持的目标 GPU model 遵循发布兼容性矩阵。
    • 预编译 driver 镜像中的 NVIDIA binaries 未作修改。Alauda 不会修改或逆向工程 NVIDIA driver 本身。