NVIDIA Container Toolkit

repository·main·Indexed 26 days ago

https://github.com/nvidia/nvidia-container-toolkit

A set of tools and libraries that allow container runtimes to access and utilize NVIDIA GPUs for GPU-accelerated workloads. Includes the nvidia-container-runtime for OCI container management, nvidia-ctk for generating CDI specification files, and nvidia-cdi-hook for preparing container environments. Supports configuration of GPU visibility via NVIDIA_VISIBLE_DEVICES, driver capabilities via NVIDIA_DRIVER_CAPABILITIES, and hardware constraints via NVIDIA_REQUIRE_* variables.

Tokens
15.5K
Snippets
15
Records
116
Agent score
89%

What's inside nvidia-container-toolkit

  1. Overview of NVIDIA Container Toolkit

    main
    The NVIDIA Container Toolkit enables the building and execution of GPU-accelerated containers. It provides a container runtime library (libnvidia-container) and various utilities designed to automatically configure containers so they can leverage NVIDIA GPUs.
  2. Understand the role of nvidia-cdi-hook in CDI workflows

    main

    The nvidia-cdi-hook CLI is a tool designed to be called by a container runtime as part of the Container Device Interface (CDI) specification. It provides runtime hook capabilities to prepare the container environment (files, permissions, symlinks, etc.) before a container starts.

    Note that nvidia-cdi-hook is not typically invoked manually by users to manage devices; instead, it is invoked by the container runtime based on instructions found in a CDI specification file. The CDI specification file itself is generated using the nvidia-ctk cdi generate command.

  3. Use NVIDIA Container Runtime with Docker

    main

    If the runtime is not in legacy mode, the docker --gpus flag will fail. To use the NVIDIA Container Runtime with Docker, you have two options:

    1. Explicitly specify the runtime in your command:

      docker run --rm --gpus all --runtime=nvidia ubuntu:18.04
    2. Set it as the default runtime by modifying /etc/docker/daemon.json:

      {
          "default-runtime": "nvidia",
          "runtimes": {
              "nvidia": {
                  "path": "nvidia-container-runtime",
                  "runtimeArgs": []
              }
          }
      }
    {
        "default-runtime": "nvidia",
        "runtimes": {
            "nvidia": {
                "path": "nvidia-container-runtime",
                "runtimeArgs": []
            }
        }
    }
  4. Generate CDI specifications for NVIDIA GPUs

    main

    The NVIDIA Container Toolkit can generate Container Device Interface (CDI) specifications to make NVIDIA devices accessible in vendor-agnostic container environments (like podman, containerd, or cri-o).

    To generate the specification, use nvidia-ctk cdi generate. You can specify a destination file using the --output flag. To write to system directories like /etc/cdi/, you must use sudo.

    The generated specification includes the following device names:

    • nvidia.com/gpu=gpu{INDEX}: For non-MIG-enabled full GPUs.
    • nvidia.com/gpu=mig{GPU_INDEX}:{MIG_INDEX}: For MIG-enabled devices.
    • nvidia.com/gpu=all: Represents all available NVIDIA devices.
  5. Generate a CDI specification file

    main

    To enable NVIDIA device support via CDI, you must first generate a CDI specification file (in YAML format) for your NVIDIA-capable devices. This is done using the nvidia-ctk tool. The resulting YAML file contains the instructions that the container runtime will use to set up devices and execute hooks like nvidia-cdi-hook.

    nvidia-ctk cdi generate
  6. Release packages using release-packages.sh

    main

    Use the scripts/release-packages.sh utility to automate the release process. This script pulls package images from the staging registry based on a git SHA, copies them to the package repository, and signs them with GPG keys.

    Arguments:

    • REPO: Either stable or experimental.
    • PACKAGE_REPO_ROOT: The local path to the libnvidia-container repository (checked out to the gh-pages branch).
    • REFERENCE (optional): The git SHA to be released. Defaults to HEAD if not provided.

    Required Environment Variables:

    • GPG_LOCAL_USER: The GPG user ID.
    • MASTER_KEY_PATH: Path to the GPG master key.
    • SUB_KEY_PATH: Path to the GPG subkey.
    GPG_LOCAL_USER="GPG_USER" \
    MASTER_KEY_PATH=/path/to/gpg-master.key \
    SUB_KEY_PATH=/path/to/gpg-subkey.key \
        ./scripts/release-packages.sh REPO PACKAGE_REPO_ROOT [REFERENCE]
  7. Build NVIDIA Container Toolkit packages

    main

    To build the components of the NVIDIA container stack, use the build-packages.sh script. You can specify a specific TARGET to build a particular platform, or omit it to build all valid release targets. Generated packages are placed in the dist folder.

    Supported targets include:

    • ubuntu18.04-amd64
    • centos7-x86_64
    ./scripts/build-packages.sh TARGET
  8. Prerequisites for NVIDIA Container Toolkit

    main

    Before installing or using the NVIDIA Container Toolkit, ensure the following requirement is met:

    • NVIDIA Driver: You must have the NVIDIA driver installed on your Linux distribution.

    Note: You do not need to install the CUDA Toolkit on the host system; only the NVIDIA driver is required on the host.

  9. Override component locations for local testing

    main

    When testing local changes, you can override the default locations of the individual components by setting the following environment variables to point to your local directories:

    • LIBNVIDIA_CONTAINER_ROOT
    • NVIDIA_CONTAINER_TOOLKIT_ROOT
    • NVIDIA_CONTAINER_RUNTIME_ROOT
    • NVIDIA_DOCKER_ROOT
  10. Configure Containerd to use NVIDIA Container Toolkit

    main

    Use the containerd setup command to configure the nvidia-container-runtime as a containerd runtime class. You must provide the path to the toolkit (typically /run/nvidia/toolkit).

    If the --runtime-class flag is not specified, the runtime class will be named nvidia. Use --set-as-default to make the specified runtime class the default.

    containerd setup \
        --runtime-class NAME \
            /run/nvidia/toolkit
  11. Configure Docker to use NVIDIA Container Toolkit

    main

    Use the docker setup command to configure the nvidia-container-runtime as a Docker runtime. You must provide the path to the toolkit (typically /run/nvidia/toolkit).

    By default, the toolkit is installed with the name nvidia and is set as the default Docker runtime. You can customize the runtime name using --runtime-name and control whether it becomes the default using --set-as-default.

    docker setup \
        --runtime-name NAME \
            /run/nvidia/toolkit
  12. Toolkit Executables and Installation Behavior

    main

    The nvidia-ctk-installer manages several key executables required for the NVIDIA Container Toolkit to function. Most executables are installed via a shell wrapper that ensures specific environment variables are set and, where necessary, verifies that NVIDIA kernel modules are loaded before execution.

    Managed Executables

    • nvidia-ctk: The primary CLI tool.
    • nvidia-cdi-hook: Installed directly as a file without a shell wrapper.
    • nvidia-container-cli: Installed with LD_LIBRARY_PATH updated to include the destination directory.
    • nvidia-container-runtime-hook: Installed with a symlink named nvidia-container-toolkit.
    • Container Runtimes: Various runtimes (retrieved via operator.GetRuntimes()) are installed with the config.FilePathOverrideEnvVar environment variable pointing to the toolkit's configuration file.

    Wrapper Logic

    For most executables, the installer creates a shell wrapper that:

    1. Checks Kernel Modules: If requiresKernelModule is true, the wrapper checks /proc/modules for nvidia. If modules are missing, it falls back to executing the DefaultRuntimeExecutablePath (defaulting to runc) directly.
    2. Sets Environment Variables: Injects PATH (including the destination directory) and other specific variables like LD_LIBRARY_PATH or configuration file overrides.
    3. Executes the Real Binary: The actual binary is renamed with a .real suffix (e.g., executable.real) and invoked by the wrapper.