How do I run GPU workloads on Red Hat OpenShift?

You run GPU workloads on Red Hat OpenShift primarily through the NVIDIA GPU Operator, which is certified and distributed via the OpenShift OperatorHub, giving you the same driver, container toolkit, device plugin, and DCGM monitoring stack as upstream Kubernetes but packaged and validated specifically for OpenShift's security and operator lifecycle model. Install it through the OperatorHub console or the command-line client, selecting the appropriate channel for your OpenShift version, and the operator will detect GPU nodes and deploy the driver as a container respecting OpenShift's stricter default security context constraints, which sometimes requires adjusting those constraints for the operator's namespace to run privileged driver containers. For a more complete AI platform experience, Red Hat OpenShift AI layers notebook environments, model serving through KServe, and pipeline tooling on top of the base GPU Operator setup, suiting organizations that want a supported, opinionated MLOps platform rather than assembling one from separate open-source projects. MIG and time-slicing configuration work the same way as upstream Kubernetes once the operator is installed, through its ConfigMap-based strategy settings. Organizations choosing OpenShift over vanilla Kubernetes are usually doing so for Red Hat's support contract and existing enterprise Linux standardization rather than any GPU-specific capability difference. Nanobase AI deploys GPU workloads on both OpenShift and upstream Kubernetes depending on a customer's existing platform standard.

OpenShift adds process, not a different GPU stack

Under the hood, OpenShift GPU support runs the same driver, container toolkit, device plugin, and DCGM monitoring stack as upstream Kubernetes, packaged as the NVIDIA GPU Operator. What differs is the installation path and security model: OpenShift's stricter default security context constraints and its OperatorHub-based lifecycle management require extra steps that a vanilla Kubernetes install does not, even though the end result is functionally the same GPU stack.

Installation steps

1. Install the Node Feature Discovery Operator first, since the GPU Operator depends on it to label nodes with detected GPU hardware.
2. Install the NVIDIA GPU Operator through the OperatorHub console or the oc command-line client, selecting the release channel matching your OpenShift version.
3. Adjust security context constraints for the GPU Operator's namespace, since its driver containers require privileged access that OpenShift's default SCCs deny more aggressively than a stock Kubernetes cluster.
4. Confirm the operator detects GPU nodes and completes driver container deployment, checking operator status through the OpenShift console or oc get pods in the operator namespace.
5. Configure MIG or time-slicing through the same ConfigMap-based strategy used on upstream Kubernetes, since this behavior is unchanged once the operator is running.
6. Validate with a test GPU workload and nvidia-smi inside a pod before onboarding production jobs.

OpenShift vs vanilla Kubernetes for GPU workloads

The GPU-facing behavior is identical in every row except the top three; OpenShift changes how the stack is installed and governed, not what it does once running.

When OpenShift AI is worth adding

Red Hat OpenShift AI layers notebook environments, model serving through KServe, and pipeline tooling on top of the base GPU Operator setup, aimed at organizations that want a supported, opinionated MLOps platform rather than assembling equivalent capability from separate open-source projects like Kubeflow, JupyterHub, and a custom serving layer. This suits teams that value having one vendor accountable for the full stack over teams that want maximum flexibility in choosing each component independently.

Why organizations pick OpenShift at all

Organizations choosing OpenShift over vanilla Kubernetes for GPU workloads are usually doing so for Red Hat's support contract and because their infrastructure is already standardized on Red Hat Enterprise Linux, rather than for any GPU-specific capability difference, since the underlying GPU stack functions the same either way. The security context constraint adjustments and operator-based lifecycle add real but manageable overhead in exchange for that commercial support relationship.

Frequently asked questions

Does the GPU Operator need special permissions on OpenShift that it doesn't need on Kubernetes?

Yes, OpenShift's default security context constraints are stricter than a typical Kubernetes pod security policy, so the GPU Operator's namespace typically needs an adjusted SCC to allow the privileged driver container to run, a step not usually required on a permissive vanilla Kubernetes cluster.

Can MIG be configured the same way on OpenShift as on Kubernetes?

Yes, once the GPU Operator is running, MIG and time-slicing configuration through its ConfigMap works identically to upstream Kubernetes, since this behavior lives in the operator itself rather than the underlying platform.

Is OpenShift AI required to run GPU workloads on OpenShift?

No, the base GPU Operator install is sufficient to run GPU-enabled pods and jobs on OpenShift. OpenShift AI is an additional, optional layer for teams wanting a bundled notebook, training, and serving platform rather than assembling those pieces separately.

How Nanobase AI helps

Nanobase AI deploys GPU workloads on both OpenShift and upstream Kubernetes depending on a customer's existing platform standard, handling the security context constraint adjustments and operator installation details that differ from a vanilla Kubernetes deployment.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.