NVIDIA DeepOps for Kubernetes and Slurm GPU Clusters

DeepOps GPU cluster deployment scope

NVIDIA DeepOps addresses the administrative work required to turn NVIDIA GPU servers into usable cluster infrastructure. Its documented scope includes provisioning operating systems, installing NVIDIA software, configuring Kubernetes or Slurm, attaching storage, and adding workload services such as KubeFlow in existing Kubernetes environments. The project is therefore aimed at cluster administrators, platform engineers, and data center teams that already have a provisioning system or can establish one.

The README presents several deployment boundaries. A team may use DeepOps for an on-premises data center built around NVIDIA DGX Systems. A team with an existing Kubernetes cluster may use selected scripts to deploy KubeFlow and connect NFS storage. An existing cluster that needs a resource manager may use DeepOps to install Slurm or Kubernetes. A single machine without a scheduler is also within the stated scope, limited to NVIDIA drivers, Docker, and the NVIDIA Container Runtime.

This range makes DeepOps a collection of deployment practices rather than a single application. The repository contains playbooks, roles, scripts, documentation, examples, tests, and submodules. That layout matters because the level of automation depends on which part of the stack the operator selects. The README does not describe DeepOps as a scheduler, a cluster management portal, or a workload application. Its value is in repeatable infrastructure workflows around those systems.

Ansible playbooks, Kubespray, and SchedMD

The documented Kubernetes path uses Kubespray, which runs on bare metal and most clouds and uses Ansible for provisioning and orchestration. Kubespray handles generic configuration management, initial Kubernetes cluster formation, networking plugin configuration, and control plane bootstrapping. DeepOps adds playbooks and roles intended for GPU environment orchestration and optimization.

The Slurm path uses SchedMD rather than reimplementing a batch scheduler. Slurm supplies resource allocation, job execution and monitoring, and queue management for jobs that request compute resources. DeepOps handles the deployment process around Slurm, while the Slurm guide contains the cluster-specific instructions. This separation makes the design understandable: DeepOps coordinates infrastructure and platform components, while Kubernetes and Slurm provide the cluster workloads and scheduling behavior.

The repository also includes a `nvidia-dgx` role for installing NVIDIA DGX platform software on supported DGX systems running Red Hat Enterprise Linux or Rocky Linux 8 or 9. The README gives a separate DGX software stack role guide for installations over vanilla Ubuntu and Red Hat family operating systems. In other words, installing a cluster scheduler and installing NVIDIA platform software are related but distinct operations.

DeepOps does not test or support putting Kubernetes and Slurm on the same physical cluster. It also does not test or support nodes with heterogeneous operating systems. Those exclusions are architectural boundaries, not merely missing examples. Teams that need multiple workload managers on one cluster are directed toward NVIDIA Bright Cluster Manager instead.

Supported operating systems and legacy paths

The current release validation focuses on Ubuntu 22.04 LTS and 24.04 LTS, plus NVIDIA DGX OS 6 and 7 for the corresponding platform. Rocky Linux and Red Hat Enterprise Linux 8 and 9 are listed for installing NVIDIA DGX platform software through the `nvidia-dgx` role. Broader Kubernetes or Slurm deployment on RHEL still requires site-specific validation, which means the repository does not claim that every listed operating system is equally covered by every cluster playbook.

The README also says that DeepOps retains legacy or community-maintained paths for DGX OS 4 and 5, Ubuntu 18.04 and 20.04, CentOS 7 and 8, and the historical DGX EL7 stack. Those paths should be treated as compatibility references unless the deploying organization validates them for the selected release. This distinction matters because the repository can contain automation for an environment without providing current release validation for it.

The README recommends using Ubuntu autoinstall, cloud-init, or MAAS for new Ubuntu 24.04 or DGX OS 7 deployments, followed by DeepOps roles after the operating system is present. Existing sites may instead use MAAS, Foreman, or an established automated OS installation process. The project assumes that infrastructure provisioning is an operational concern separate from the DeepOps roles that configure the cluster stack.

Starting a first DeepOps deployment

The cleaned README does not provide a standalone installation command, package name, port, environment variable, or copy-and-paste first-run example. It directs users to the DeepOps Kubernetes Deployment Guide and the DeepOps Slurm Deployment Guide for deployment instructions. It also points operators and new contributors to `AGENTS.md`, `docs/deepops/validation.md`, and `skills/README.md` for operating rules and step-by-step procedures.

A first real use therefore begins by choosing one cluster target rather than combining both schedulers. For Kubernetes, the documented route is the Kubernetes Deployment Guide, with Kubespray as the underlying provisioning mechanism. For Slurm, the documented route is the Slurm Deployment Guide, with SchedMD providing Slurm installation. In either case, the operator should confirm the provisioning system and node operating systems before applying any role.

The repository is primarily Shell and includes Ansible configuration, playbooks, and roles. The presence of `ansible.cfg`, `playbooks/`, `roles/`, `submodules/`, and validation documentation indicates a repository-based deployment workflow rather than a single executable installer. Since the README excerpt does not give the exact checkout, dependency initialization, inventory, or playbook invocation, those commands are intentionally not reproduced here.

Operational limits for GPU cluster administrators

The clearest limitation is scheduler exclusivity. DeepOps does not test or support Kubernetes and Slurm deployed on the same physical cluster. An organization that needs both workload managers must redesign the cluster or use an enterprise management product that supports that arrangement. NVIDIA identifies Bright Cluster Manager as the recommended option for managing multiple workload managers in one cluster.

The second limitation is operating system uniformity. DeepOps does not support a configuration where nodes have heterogeneous operating systems. A cluster may therefore have to normalize its node images before applying shared roles, or operators need site-specific automation for exceptions. The README is also careful about platform scope: Rocky Linux and RHEL support for the `nvidia-dgx` role does not automatically mean that all Kubernetes or Slurm cluster workflows have been validated on those systems.

The virtual deployment path is intended for trying DeepOps on a single node with Vagrant. The README describes it as useful for learning and local experimentation, but also labels it as a legacy or community path. It should not be treated as evidence that a production cluster can be recreated in a single virtual machine. Likewise, the repository does not document a rollback procedure for a failed cluster deployment, so operators would need to establish their own recovery plan.

DeepOps maintenance and BSD-3-Clause implications

The repository is not archived, and its last push was on 2026-10-15. The recent releases listed include 26.09 on 2026-10-01, 26.07 on 2026-07-15, and 26.05 on 2026-05-26. The README recommends the latest release branch for stable code and says that development occurs on `master`, which is generally functional but may change significantly between releases.

That distinction has a direct upgrade cost. Operators who track `master` may receive new automation before it is represented by a release branch, while operators who select a release branch must decide when to move between releases and validate the result against their own sites. The repository includes tests and machine-readable validation tools, but the README does not claim that every legacy path or site-specific configuration is continuously validated.

The project is distributed under BSD-3-Clause. That license identifies the project's licensing basis, but this review does not provide legal advice. Operators should review the repository's `LICENSE` and `CONTRIBUTING.md` files themselves for their compliance, notice, and contribution requirements.

DeepOps versus a scheduler-first workflow

A real alternative is to install Kubernetes or Slurm directly and manage the surrounding GPU platform with separate site automation. The difference is not that the alternatives schedule different workloads. Both approaches can result in Kubernetes or Slurm managing GPU nodes. The difference is where the deployment logic and validation responsibilities live.

With DeepOps, the repository centralizes NVIDIA-oriented roles, GPU environment orchestration, deployment guides, validation material, and example procedures. Kubespray remains the Kubernetes deployment substrate, and SchedMD remains the Slurm installation route. This suits teams that want a shared NVIDIA deployment baseline or need to adapt a documented cluster pattern across several servers.

A scheduler-first workflow may be simpler for a small site with an established configuration-management platform and only one deployment pattern. It avoids adopting a broader infrastructure repository when the operator already has tested Ansible roles for OS preparation, NVIDIA drivers, storage, and cluster installation. The trade-off is that the organization must assemble and maintain those controls itself. DeepOps is a better fit when its NVIDIA-specific roles and deployment guides match the environment, not merely because it contains Ansible files.

Editorial conclusion

Adopt NVIDIA DeepOps when you operate NVIDIA GPU infrastructure and need documented Ansible workflows for Kubernetes, Slurm, or DGX platform software. Do not treat it as a supported design for one physical cluster running both schedulers, heterogeneous operating systems, or an unvalidated legacy environment. Verify first that your operating systems, NVIDIA platform versions, provisioning system, and intended deployment guide match the current release requirements, then review the repository's AGENTS.md and validation procedures.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. NVIDIA/deepops on GitHub
4. README
5. Releases