nvidia/gpu-operator Helm chart · ConfigHub Workshop

What it is. nvidia/gpu-operator v26.7.1, as 27 Kubernetes objects in its default preset.

Install it. curl -fsSL -o try-objects.sh https://confighub.github.io/helm-expt/site/sh/nvidia-gpu-operator-v26-7-1/default/try-objects.sh && bash try-objects.sh

OCI bundle. oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-nvidia-gpu-operator-v26-7-1-default:r001@sha256:e62fa1a183616cf7c7274d40abb043e1c6aee34eceb9061763b75d3b3d501872

Needs first. Nothing. The script applies any CRDs first.

Step by step. Deploy the GPU Operator from the Catalog.

How it works. How the model works, and Helm in the Catalog.

Pick a version and a base

Versions are listed newest first. Each row is one base, and every cell is read from that base's listing. A base marked watch has a checked result with a limit to review.

v26.7.1 newest

7 bases. The installer package is published and signed. Open the page for v26.7.1.

Base	Objects	Flattening verdict	Published as OCI	Flag	Open
default default	27	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-580.105.08	27	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-580.126.20	27	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver	27	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver-and-toolkit	27	flatten-with-routes, plan recorded	Published	None	exact objects · listing
external-nfd	12	flatten-with-routes, plan recorded	Published	None	exact objects · listing
aicr-eks-training	13	flatten-with-routes, plan recorded	Published	None	exact objects · listing

v26.3.3

7 bases. The installer package is published and signed. Open the page for v26.3.3.

Base	Objects	Flattening verdict	Published as OCI	Flag	Open
default default	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-580.105.08	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-595.91.07	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver-and-toolkit	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
external-nfd	9	flatten-with-routes, plan recorded	Published	None	exact objects · listing
aicr-eks-training	10	flatten-with-routes, plan recorded	Published	None	exact objects · listing

v26.3.2

6 bases. The installer package is published and signed. Open the page for v26.3.2.

Base	Objects	Flattening verdict	Published as OCI	Flag	Open
default default	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-580.105.08	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-595.91.07	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver-and-toolkit	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
external-nfd	9	flatten-with-routes, plan recorded	Published	None	exact objects · listing

v25.10.1

6 bases. The installer package is published and signed. Open the page for v25.10.1.

Base	Objects	Flattening verdict	Published as OCI	Flag	Open
default default	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-580.126.20	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
driver-595.91.07	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
preinstalled-driver-and-toolkit	24	flatten-with-routes, plan recorded	Published	None	exact objects · listing
external-nfd	9	flatten-with-routes, plan recorded	Published	None	exact objects · listing

See what changes

Choose two versions or two bases, then press Compare. The page fetches the two retained files and checks each file's SHA-256 against the digest its listing records. It then computes the diff on demand, in your browser, with the code that cub config diff runs. Nothing is precomputed or stored.

Run the same diff yourself

These commands fetch the same two files and compare them on your machine, with no account. They follow the pair you choose above. cub plugin install confighub/cub-workshop@v0.6.61 adds cub config diff.

# fetch the first retained file
$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/default/r001/rendered/release-objects.yaml

# fetch the second retained file
$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml

# check the bytes against the two listings
$ shasum -a 256 nvidia-gpu-operator-v26-3-3-default.yaml nvidia-gpu-operator-v26-7-1-default.yaml
73ebb5f6de3d1f010330d266db11b99b508be84dfc92b9d5deb01a39b66fee7c  nvidia-gpu-operator-v26-3-3-default.yaml
a3d4cab291e48e0d0e667ef49116c6d7ecff91600cd13c1e9c4c23290fcd78dd  nvidia-gpu-operator-v26-7-1-default.yaml

# count what changes
$ cub config diff nvidia-gpu-operator-v26-3-3-default.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary

# list every changed field
$ cub config diff nvidia-gpu-operator-v26-3-3-default.yaml nvidia-gpu-operator-v26-7-1-default.yaml

Read one line for each version step

These lines are the only diff content this page stores. Each one was computed when the site was generated, by the same code, on the default base of both versions.

From v26.3.3 to v26.7.1 on the default base, 21 of 24 objects change and 3 are added. Compute this diff.
From v26.3.2 to v26.3.3 on the default base, 7 of 24 objects change. Compute this diff.
From v25.10.1 to v26.3.2 on the default base, 21 of 24 objects change. Compute this diff.

Use this entry in ConfigHub

Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.

Steps 1 and 2 need no account. Install the cub CLI before any cub command. Step 2 uses cub config diff, which cub plugin install confighub/cub-workshop@v0.6.61 adds. A live walk on 2026-10-08 ran steps 3 to 5 for bitnami-nginx-24-0-2-http-clusterip and nvidia-gpu-operator-v26-3-3-default. These commands carry the changes that walk needed. It is a dated log and no receipt, so no state on this page rests on it. These are the steps for v26.7.1, the newest version, on its default base.

What is fixed, and what you supply

Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.

chart is nvidia/gpu-operator
version is v26.7.1
base is default
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}

Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.

gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.

This entry's plan, and how to test it

These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.

When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.

Test the install steps yourself. This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog ran it on a local cluster, and the log has every line.

Test the plain objects. A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.

Upgrade and delete. The Catalog carried out this entry's upgrade and delete steps by hand on a local cluster, and the log has every line.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 27 objects in one file.

An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.

Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.

# fetch the retained objects for this entry
$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 nvidia-gpu-operator-v26-7-1-default.yaml
a3d4cab291e48e0d0e667ef49116c6d7ecff91600cd13c1e9c4c23290fcd78dd  nvidia-gpu-operator-v26-7-1-default.yaml

# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base default --work-dir ./nvidia-gpu-operator-v26-7-1-default --non-interactive --namespace gpu-operator

2. Compare with another version or base Not run for this entry

The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, driver-580.105.08, driver-580.126.20, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.

# fetch the aicr-eks-training base of the same version
$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/aicr-eks-training/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff nvidia-gpu-operator-v26-7-1-default.yaml nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml --summary

# fetch the default base at version v26.3.3
$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/default/r001/rendered/release-objects.yaml

# list what changed from v26.3.3 to v26.7.1
$ cub config diff nvidia-gpu-operator-v26-3-3-default.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary

3. Upload it as a variant Not run for this entry

The Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.

Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.

In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.

The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.

# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login

# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-default --space <your-space> --component <your-component>

# list the Units the upload created
$ cub unit list --space <your-space>

4. Deploy it Not run for this entry

No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.

Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.

Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.

ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.

The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.

Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.

# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"

# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev

# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record

# publish again without it
$ cub release publish <your-space>-dev

5. Promote a change Not run for this entry

No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.

The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.

The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.

# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations

# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"

# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record

# publish the Release that carries the change
$ cub release publish <your-space>-dev

For agentsThese steps are the nextSteps array of nvidia-gpu-operator-v26-7-1-default.json. Each state was read from flattened.retainedObjects, flattened.inventory, source.ociRef, oci.bundles, oci.runtimes, lifecycle.promotion, lifecycle.coverage and variants.known in the same listing. A command marked needsAccount there contacts ConfigHub. A step's notes hold its cautions, carries lists the CRDs the base brings, and liveWalk links the dated log that ran its commands.

Use another version or base

Every other base carries the same five steps, with its own states and commands, on the page of its version.

The same five steps on the page for v26.7.1 cover the bases driver-580.105.08, driver-580.126.20, preinstalled-driver, preinstalled-driver-and-toolkit, external-nfd, aicr-eks-training.
The same five steps on the page for v26.3.3 cover the bases default, driver-580.105.08, driver-595.91.07, preinstalled-driver, preinstalled-driver-and-toolkit, external-nfd, aicr-eks-training.
The same five steps on the page for v26.3.2 cover the bases default, driver-580.105.08, driver-595.91.07, preinstalled-driver, preinstalled-driver-and-toolkit, external-nfd.
The same five steps on the page for v25.10.1 cover the bases default, driver-580.126.20, driver-595.91.07, preinstalled-driver, preinstalled-driver-and-toolkit, external-nfd.

Open a live example in ConfigHub

The example lives in the helm-catalog organization on hub.confighub.com. A reader needs access to that organization to open the links. It was observed on 2026-10-08.

It holds one component, gpu-operator, with four Spaces of 24 Units each. Three Spaces hold chart v25.10.1, v26.3.2 and v26.3.3. The fourth Space, gpu-operator-prod, was installed at chart v26.3.2 and upgraded to v26.3.3, which changed 7 of 24 Units. Its driver then changed from 580.126.20 to 595.91.07 with the Catalog base driver-595.91.07. That changed 1 of 24 Units, in the ClusterPolicy field spec.driver.version.

The component was uploaded with cub v0.8.7 from the Catalog's retained objects, on the default base with hooks excluded. The uploads were then compared with cub variant diff. Nothing was deployed to a cluster, and no Target is attached. The example is not a run for any Catalog entry, so it changes no listing state.

To reach a diff by hand, open the Unit, open its Revisions tab, click a revision, then tick the one before it. The Diff panel compares the two field by field.

These commands made it. They need a ConfigHub account, and they write to the organization you are signed in to.

$ cub variant upload --component gpu-operator --variant <name> --namespace gpu-operator --change-desc "<text>" <file>

$ cub variant diff gpu-operator-prod Before:ChangeSet:<upload> ChangeSet:<upload> -o mutations

Read this page as data

One file holds everything on this page in a form a program can read.

Technical notes and disclaimers

The plain-objects script applies the objects and ends. It does not wait for the workloads to start. Neither script runs the steps the plan names for an upgrade or a delete. A cluster with no GPUs shows that the objects apply. It does not show the workload using a GPU.