Skip to content
In this Guide

In this Guide

Deep Dives

AI: Claude and Codex patterns

ConfigHub: Deploy and manage

More in this Guide

Deploy the GPU Operator from the Catalog

Install NVIDIA's GPU Operator on a Kubernetes cluster in two commands. Then keep it up to date across your environments, and test it on a GPU node. You can also view this as a markdown file.

Three terms

TermMeaning
RecipeA chart, its version, and one set of values.
OCI bundleThe Kubernetes objects that a recipe produces, in one OCI artifact, with a plan if they need one.
VariantYour copy of a bundle for one environment, such as dev or QA.

What you need

  • Steps 1 and 2: kubectl and a cluster.
  • Steps 3 and 4: a ConfigHub account and the cub CLI.
  • Step 5: a node with an NVIDIA GPU.

Step 1. Install it

The Catalog gives each bundle a script. It downloads the objects, checks their SHA-256, applies the CRDs, and then applies the rest.

curl -fsSL -o try-objects.sh https://confighub.github.io/helm-expt/site/sh/nvidia-gpu-operator-v26-3-3/default/try-objects.sh
bash try-objects.sh
>> Check the file against the SHA-256 in the listing
The file matches: sha256 73ebb5f6de3d1f010330d266db11b99b508be84dfc92b9d5deb01a39b66fee7c
>> A CRD is missing, so apply the file's CRDs first
>> Apply the other 19 objects
>> Done. The 5 CRDs were applied first. kubectl applied the other 19 objects of this entry's retained file.

Step 2. Check that it is running

kubectl -n gpu-operator rollout status deployment/gpu-operator --timeout=300s
deployment "gpu-operator" successfully rolled out

The operator's ClusterPolicy reported ready about a minute later.

Step 3. Store it in ConfigHub and make a variant for each environment

Upload the bundle. ConfigHub makes one Unit for each object and keeps the plan beside them. This example starts one version back, at v26.3.2, so that step 4 has a new version to take.

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

BUNDLE=oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-nvidia-gpu-operator-v26-3-2-default:r001@sha256:0f6f399365cb045906854c9b568afa8dcb960d7898db5e5b47a317a3eed10484
cub variant upload --component gpu-operator --variant base --namespace gpu-operator "$BUNDLE"
Space gpu-operator-base (Create)
  Create    gpu-operator
  Create    cluster-policy-clusterpolicy
  ... (25 more Units)

Make a variant for dev, and one for QA that follows dev.

cub variant create dev gpu-operator-base --environment Dev
cub variant create qa gpu-operator-dev --environment QA
Created variant space gpu-operator-dev
Bulk create operation completed:
  Success: 27 unit(s)

Step 4. Take a new version and promote it

Upload v26.3.3 over the base. ConfigHub lists what changes.

BUNDLE=oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-nvidia-gpu-operator-v26-3-3-default:r001@sha256:408cfa607e699388f62c1859f3f0daeecc99b8110f8cee076f06855be2d8ea1e
cub variant upload --yes --component gpu-operator --variant base --namespace gpu-operator "$BUNDLE"
Space gpu-operator-base (Update)
  Update    gpu-operator-serviceaccount
  Update    gpu-operator-clusterrole
  Update    gpu-operator-clusterrolebinding
  Update    gpu-operator-role
  Update    gpu-operator-rolebinding
  Update    gpu-operator
  Update    cluster-policy-clusterpolicy
  ... (6 lines for the plan documents)
  Unchanged 17 Unit(s)

Seven objects changed and 17 did not. Dev and QA still hold the old version. Preview the promotion, then promote dev, then QA.

cub variant promote gpu-operator-dev --dry-run
cub variant promote gpu-operator-dev
cub variant promote gpu-operator-qa
Would upgrade 10 unit(s) behind their upstream
Upgraded 10 unit(s) behind their upstream

Each environment now holds v26.3.3, and each change is recorded.

Step 5. Test it on a GPU node

This step needs a node with an NVIDIA GPU. It is NVIDIA's own check, from the GPU Operator documentation.

Check that the operator's pods are up. All of them should be Running or Completed.

kubectl get pods -n gpu-operator
kubectl get clusterpolicy

Run NVIDIA's sample workload, which asks for one GPU.

cat > cuda-vectoradd.yaml <<'YAML'
apiVersion: v1
kind: Pod
metadata:
  name: cuda-vectoradd
spec:
  restartPolicy: OnFailure
  containers:
    - name: cuda-vectoradd
      image: "nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda12.5.0-ubuntu22.04"
      resources:
        limits:
          nvidia.com/gpu: 1
YAML
kubectl apply -f cuda-vectoradd.yaml
kubectl logs pod/cuda-vectoradd

The log ends with Test PASSED when the pod has used the GPU.

Where to go next

Technical notes and disclaimers

  • UNOFFICIAL/EXPERIMENTAL.
  • Steps 1 to 4 were run, and each output block is what the command printed, shortened. A line that starts with ... marks a cut.
  • Steps 1 and 2 ran on a local kind cluster with no GPUs, on 11 October 2026. The log has every line.
  • Steps 3 and 4 ran in a ConfigHub organization on 9 October 2026, under the name cwwalk-1009-gpu-operator and with a description on each change. The log has every line.
  • Step 5 has not been run by the Catalog, which has no GPU. The commands and the sample pod are NVIDIA's.
  • The plan has two more steps, one before an upgrade and one after a delete. The script in step 1 does not run them. The entry page lists them.