Fuzzball vs. Red Hat OpenShift
Add the scheduler your workload actually needs
OpenShift is a strong enterprise application platform, built around long-running, loosely coupled services. Tightly coupled HPC jobs and AI training are the opposite shape, so running them on OpenShift means assembling Kueue, Volcano, and JobSet on top of a scheduler designed for something else. Fuzzball schedules that work natively, and it deploys onto the OpenShift cluster you already run.
Get the Fuzzball solution brief
The short answer
OpenShift is a Kubernetes distribution built to ship and govern enterprise applications. Fuzzball is an orchestration platform built to run HPC simulation, AI training, and AI inference. Both use containers, so the difference is what the scheduler was designed to coordinate: OpenShift schedules pods one at a time and adds gang scheduling through Kueue and Volcano, while Fuzzball gang-schedules tightly coupled work natively. Fuzzball Orchestrate can run on OpenShift.
From the team that created Apptainer and Singularity at Lawrence Berkeley National Laboratory, and the founding sponsor of Rocky Linux.
Compare what each one is built for
Red Hat OpenShift
- Microservices, APIs, and web applications, built and shipped through integrated CI/CD
- Hybrid and multi-cloud application governance, with strong RBAC, policy, and audit
- Regulated enterprise IT, where consistency and compliance are the priorities
- Batch and HPC through add-ons: Kueue for admission, Volcano for gang scheduling, JobSet for distributed jobs
Fuzzball
- Tightly coupled MPI simulation and distributed AI training, gang-scheduled from day one
- Persistent inference services defined alongside the training that produced them
- Native InfiniBand awareness, GPU topology awareness, and unprivileged, rootless execution
- One web UI, CLI, and SDK at full parity, with no separate operators to assemble
Understand the real difference
OpenShift’s scheduling model, like upstream Kubernetes, was built around independent, loosely coupled services. If one replica of a microservice is delayed, the rest of the application keeps working. HPC and AI training jobs behave the opposite way. MPI ranks and distributed training workers are tightly coupled, and all of them have to start together or the whole job stalls and burns GPU hours doing nothing.
That is why HPC-style work on OpenShift arrives through add-ons. Kubernetes’ default scheduler places pods one at a time and does not gang-schedule out of the box. Red Hat’s own guidance walks teams through assembling gang autoscaling from the Red Hat build of Kueue plus the ProvisionRequest API, and many teams pair Kueue with Volcano to get pod-level gang scheduling as well. These components work, and Red Hat supports them properly. They are still additions to a platform whose design center is long-running application services.
Fuzzball’s scheduler and workflow engine were designed around coupled, all-or-nothing execution from the start, together with data movement, container image preparation, and DAG-based multi-step workflows. That is one coherent system in place of several assembled projects.
See what Fuzzball 4.2 adds
Let an agent drive the workload, not just the cluster
Let a workflow submit its own work
Share one GPU estate, and account for it
Schedule NVIDIA and AMD from one control plane
Weigh the differences that matter
Jobs and services in one workflow
Bare-metal performance for the whole lifecycle
Data as part of the workload
One interface in place of several
Sovereign AI on infrastructure you govern
Compare Fuzzball and OpenShift at a glance
Red Hat OpenShift | Fuzzball | |
|---|---|---|
| Design center | ||
| Category | Enterprise application platform and Kubernetes distribution | Purpose-built HPC, AI, and inference orchestration |
| Designed to schedule | Long-running, loosely coupled application services | Tightly coupled gang-scheduled jobs, plus on-demand inference |
| Workload unit | Microservice, API, or web application | A workflow: batch job, persistent service, or both |
| Primary applications | Microservices, DevSecOps, hybrid-cloud governance | Simulation, AI training, AI inference, scientific pipelines |
| Scheduling | ||
| Gang scheduling | Added through Kueue, Volcano, and the JobSet operator | Native from day one, no separate operators |
| Interconnect awareness | GPU and device support through operators and plugins | InfiniBand auto-detected, GPUs allocated with topology awareness |
| Execution path | Workloads run as Kubernetes-scheduled pods | Substrate agent executes on-node, close to the hardware |
| Node health | Failed pods are rescheduled individually | Reliability scoring feeds placement, gang restarts on healthy nodes |
| Jobs, services, and data | ||
| Jobs plus inference | Deployments and Services for serving, Kueue and Volcano for batch | Unified in one workflow through Service Endpoints |
| Data management | General-purpose persistent storage classes, used by the application | Ingress, caching, and egress as volume lifecycle steps |
| Model ingress | Scripted or handled by MLOps tooling | Pull from Hugging Face or Ollama as a declared input |
| Accounting | Quotas and RBAC, with chargeback through added tooling | Compute, storage, and network egress per workflow |
| Interface and AI | ||
| User experience | Separate views for cluster health, queueing, and distributed jobs | One web UI, CLI, and SDK at full parity |
| Agent interface | MCP support in OpenShift AI, aimed at cluster and model tooling | MCP server aimed at workflows, with per-action permissions |
| Accelerator support | NVIDIA and AMD through vendor operator stacks | NVIDIA and AMD ROCm discovered and scheduled natively |
| Heritage and relationship | ||
| Container lineage | Standard Docker and OCI, built for enterprise microservices | Same team and design lessons as Apptainer, in a purpose-built runtime |
| To each other | Can host Fuzzball Orchestrate as its Kubernetes layer | Deploys onto OpenShift, and federates it with on-prem, cloud, and edge |
Run Fuzzball on top of OpenShift
Fuzzball Orchestrate is a Kubernetes-native microservice stack, so it deploys on any conformant Kubernetes distribution, OpenShift included. Displacement is not the ask.
Your control plane
Orchestrate handles scheduling, provisioning, storage, and secrets, and deploys directly onto an existing OpenShift cluster rather than requiring a separate Kubernetes environment.
Your compute
Substrate runs on compute nodes provisioned and managed by OpenShift, and executes jobs as close to the hardware as possible.
Beyond one cluster
Federate spans OpenShift-based clusters, on-prem HPC systems, cloud, and edge, and routes each workflow on cost, performance, and data locality.
Match this to your situation
- A distributed training job stalls because pods get admitted a few at a time
- The team maintains Kueue, Volcano, and JobSet configuration to approximate one scheduler
- Watching a single job takes three dashboards and none of them shows the whole run
- MPI codes have to be reshaped to fit a platform built for stateless services
- Training runs on one stack and inference runs on another, with a manual handoff between them
- Enterprise IT standardized on OpenShift, and the research or AI team went and bought its own cluster
Zero
Operators to assemble
Gang scheduling, data movement, and DAGs come with the platform, not from three community projects.
Both
Batch jobs and inference services
Defined in one workflow, at the same bare-metal performance.
One
UI, CLI, and SDK at full parity
A single view of a workflow from submission to completion.
Keep
Your OpenShift investment
Orchestrate deploys onto the cluster you already run, and Federate extends it.
Define the terms
- What is Red Hat OpenShift?
- Red Hat OpenShift is an enterprise Kubernetes distribution and application platform. It provides container orchestration, automated application deployment and scaling, integrated developer and CI/CD tooling, and security and governance controls across hybrid and multi-cloud environments. It is widely adopted in regulated industries for its policy management, multicluster governance, and DevSecOps capabilities.
- What is gang scheduling?
- Gang scheduling is a policy that starts all processes of a tightly coupled parallel job at the same time, or starts none of them. MPI ranks and distributed AI training workers need it, because a job with only some of its workers running makes no progress and holds expensive GPUs idle. Kubernetes does not gang-schedule by default.
- What is Fuzzball?
- Fuzzball is CIQ’s orchestration platform for HPC, AI training, and AI inference. It treats every workload as a containerized workflow, gang-schedules tightly coupled jobs natively, and schedules those workflows across on-premises clusters, cloud, and edge from one API. Fuzzball Orchestrate runs on any conformant Kubernetes distribution, including OpenShift.
Run Fuzzball on your own cluster
Bring one workflow and the cluster you run it on today. A CIQ engineer will walk your team through a run on your own hardware, then the same run in a cloud, unchanged.
Frequently asked questions
Yes. Fuzzball Orchestrate is a Kubernetes-native microservice stack and deploys on any conformant Kubernetes distribution, including OpenShift. Substrate runs on compute nodes that OpenShift provisions and manages, and Fuzzball Federate can span OpenShift-based clusters alongside on-premises HPC systems, cloud, and edge. Fuzzball adds a performance-computing layer rather than displacing the platform.
OpenShift can run HPC workloads with additional components. Kubernetes’ default scheduler places pods one at a time and does not gang-schedule out of the box, so teams add the Red Hat build of Kueue for admission control, the ProvisionRequest API for gang autoscaling, Volcano for pod-level gang scheduling, and the JobSet operator for distributed batch jobs. Fuzzball provides that scheduling behavior natively.
Kubernetes was designed around independent, loosely coupled services, where a delayed replica does not stop the application. Tightly coupled jobs behave the opposite way: every MPI rank or training worker has to start together, and a partial allocation makes no progress while holding GPUs idle. Gang scheduling exists upstream in Kubernetes but ships disabled, which is why batch platforms on Kubernetes add it back.
OpenShift AI is an MLOps platform layered on the same general-purpose Kubernetes foundation, with model development, serving, and now MCP support for agentic workloads. It is a credible enterprise AI platform. Fuzzball is a scheduler and workflow engine designed for tightly coupled computation, where gang scheduling, InfiniBand awareness, data movement, and DAGs are core platform behavior rather than added components.
Yes. Fuzzball 4.2 introduced an MCP server that lets an AI agent inspect a Fuzzball environment and draft, submit, and monitor workflows, with explicit permission required for writes, execution, and destructive actions. Red Hat’s MCP work in OpenShift AI targets cluster objects and model tooling, so the two are adjacent rather than overlapping.
No. MPI, Shmem, and other HPC communication libraries run inside Fuzzball’s containers, and NCCL works the same way for multi-GPU training. InfiniBand is auto-detected and GPUs are allocated with topology awareness, so simulation code and distributed training jobs run unchanged.
Fuzzball deploys to AWS, Google Cloud, Oracle Cloud, Azure, and CoreWeave, to on-premises clusters built with Warewulf, VMware, or bare metal, and onto existing Kubernetes distributions including OpenShift. The same workflow definition runs unchanged in all of them.
Still have questions?