Available with limitations in:  CSE Lite (1.73), CSE Pro (1.73)

Available without limitations in:  EE

The module lifecycle stage: General Availability

The module has requirements for installation

Before enabling the module, make sure your cluster meets the requirements.

Disabling the module requires confirmation, because it removes GPU support from the cluster and may reconfigure hardware.

Before disabling, remove GPU workloads from the nodes. On uninstall, a pre-delete hook deletes every PhysicalGPU object in the cluster and waits up to 600 seconds so that gpu-controller can clear its finalizers before the CRD is removed. If the hook times out, check for objects with stuck finalizers:

d8 k get physicalgpus -A

DRA mode is in Preview: it is available for use, but its parameters and behaviour may still change in future releases.

By default, DRA mode is disabled for the module and the module runs in Device Plugin mode. We recommend running the module in DRA mode: to do that, enable it explicitly in the dra parameter when you apply the ModuleConfig. Before enabling it, make sure the cluster meets the prerequisites for DRA mode.

Example of enabling the module in DRA mode:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: gpu
spec:
  enabled: true
  version: 1
  settings:
    dra:
      enabled: true

How to explicitly enable the module…

You may explicitly enable or disable the module in one of the following ways:

  • Via Deckhouse web UI. In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the gpu module and enable (or disable) the “Module enabled” toggle. Save changes.

    Example:

    Module enable/disable interface

  • Via Deckhouse CLI (d8).

    Use the d8 system module enable command for enabling, or d8 system module disable command for disabling the module (you need Deckhouse CLI (d8), configured to work with the cluster).

    Example of enabling the module:

    d8 system module enable gpu

  • Using ModuleConfig gpu.

    Set spec.enabled to true or false in ModuleConfig gpu (create it if necessary);

    Example of a manifest to enable module gpu:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: gpu
spec:
  enabled: true

How to configure the module…

You can configure the module in one of the following ways:

  • Via Deckhouse web UI.

    In the “System” → “System Management” → “Deckhouse” → “Modules” section, open the gpu module and enable the “Advanced Settings” switch. Fill in the required fields in the “Configuration” tab or specify the module settings in YAML format on the “YAML” tab, excluding the settings section. Save the changes.

    Example:

    Module Setup Interface

    You can also edit the ModuleConfig object gpu on the “YAML” tab in the module settings window (“System” → “System Management” → “Deckhouse” → “Modules”, open the module gpu) by specifying the schema version in the spec.version parameter and the necessary module parameters in the spec.settings section.

  • Via Deckhouse CLI (d8) (requires Deckhouse CLI (d8) configured to work with the cluster).

    Edit the existing ModuleConfig gpu (for more details on configuring Deckhouse, see the documentation) by executing the following command:

    d8 k edit mc gpu

    Make the necessary changes in the spec.settings section. If necessary, specify the schema version in the spec.version parameter. Save the changes.

    You can also create a file with manifest for ModuleConfig gpu using the example below. Fill in the spec.settings section with the required module parameters. If necessary, specify the schema version in the spec.version parameter.

    Apply the manifest using the following command (indicate the manifest file name):

    d8 k apply -f <FILENAME>

    Example of a manifest for ModuleConfig gpu:

    apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: gpu
spec:
  version: 1
  enabled: true
  settings: # Module parameters from the "Parameters" section below.

How to change the module release channel…

To change the module release channel, follow the instruction.

Requirements

To the Kubernetes version: 1.33 and above.

To the Deckhouse version: 1.75 and above.

Parameters

Schema version: 1

  • settings
    object
    • settings.dra
      object
      DRA (Dynamic Resource Allocation) mode settings.

      Default: {}

      • settings.dra.allowCrossNamespaceSharing
        boolean

        Allow MPS and time-slicing to share a single GPU between workloads from different namespaces.

        Disabled by default: co-tenants of one shared device share an MPS server and an unquota’d memory pool, so a fault or a runaway allocation reaches everyone on that device. The boundary is a tenancy and blast-radius boundary, not a memory-protection one — for enforced isolation use MIG partitions or whole-card passthrough.

        The restriction applies per placement, so different MIG partitions of one GPU stay available to different namespaces.

        Enforced on the node: the pre-bind conflict predicate rejects the allocation before bind, and the vendor adapter re-checks at prepare. A rejection surfaces as condition BindingFailed=True with reason NamespaceConflict in ResourceClaim.status.devices.

        Default: false

      • settings.dra.enabled
        boolean

        Enable DRA (Dynamic Resource Allocation) mode for GPU management.

        DRA mode is in Preview: it is available for use, but its parameters and behaviour may still change in future releases.

        DRA is the recommended way to manage GPUs with this module, and the mode is enabled explicitly: by default the module runs in Device Plugin mode. In DRA mode a workload requests GPUs, MIG partitions, and shared GPU slices through the Kubernetes ResourceClaim API instead of the nvidia.com/gpu extended resource.

        Switches the GPU management stack from Device Plugin mode (NFD/GFD, nvidia-device-plugin) to DRA, and disables the Device Plugin/NFD/GFD stack.

        Requires Kubernetes >= 1.34 and a Deckhouse version that enables the required DRA feature gates. The module never enables feature gates itself: if they are missing, the DRA stack is not deployed and the module reports it through the FeatureGatesReady condition. See the module architecture documentation for details.

        Default: false

    • settings.logLevel
      string
      Operator logging level.

      Default: Info

      Allowed values: Trace, Debug, Info, Error

      Example: 

      logLevel: Info