SunkCluster resource. In both modes, Slurm nodes run as Kubernetes Pods, and your users connect to a login node and submit jobs with the same Slurm commands.
This page helps you pick a mode for a new cluster. For what SUNK is and how it works, see About SUNK. For the Self-Service product in depth, see About SUNK Self-Service.
SUNK Self-Service
CoreWeave provisions and operates the cluster from oneSunkCluster resource: the compute nodes, the Slurm control plane, login pods, shared storage, and user access. You declare the cluster you want, and CoreWeave’s managed control plane keeps the running cluster reconciled to it, including when you change node counts or upgrade the SUNK version.
You can create and manage a Self-Service cluster in two ways. The Cloud Console is a guided form that can also create the CoreWeave Kubernetes Service (CKS) cluster, enable the SCIM API for user provisioning, and create the Identity and Access Management (IAM) group that grants cluster access. The SunkCluster custom resource (CR) path applies the same resource with kubectl, which fits a GitOps workflow. Both paths submit the same resource.
SUNK Self-Service requires SUNK 8.0 or later. It’s the recommended mode for a new cluster on CKS.
SUNK Standard
You deploy and operate thesunk and slurm Helm charts, usually through ArgoCD or another GitOps pipeline. Every chart value is yours to set, and you own each upgrade between SUNK releases.
SUNK Standard runs SUNK 7.x and SUNK 8.0 and later. It’s also the only mode that runs outside CoreWeave. SUNK Anywhere is SUNK Standard on a Kubernetes cluster that CoreWeave doesn’t operate.
Compare the modes at a glance
Choose based on what you need
Start from what your cluster has to do. Either mode meets most requirements, so the following lists name only the ones that decide it. Migration between modes isn’t supported, so if you expect to need a Standard-only capability later, start on SUNK Standard.When to pick SUNK Standard
Pick SUNK Standard if you need any of the following:- Custom controller, login, or
slurmdimages. A Self-Service cluster runs the images CoreWeave publishes. You choose the SUNK, Slurm, CUDA, and Ubuntu versions, not the image. See Create custom images. - An LDAP directory for user identity. Self-Service provisions users through SCIM only. See Manage users with a directory service.
- Custom Slurm plugin files, such as a
job_submit.luascript or any other file you have to mount into/etc/slurmyourself. Slurm configuration keys aren’t a reason to pick Standard, becausespec.slurmConfigcarries them in Self-Service. A file you have to place on disk is. See Customize cluster behavior with Lua plugins. - Node affinity and tolerations on each compute node group, for example, to bind a NodeSet to a specific Node Pool. In Self-Service, each entry in
spec.nodessets a name, an instance type, a node count, and whether the group hosts the control plane. See Bind NodeSets to Node Pools and Configure compute nodes. - An existing Helm or ArgoCD pipeline that you want to keep as the source of truth for the cluster. See Manage deployments with CI and GitOps.
- SUNK 7.x. Self-Service starts at SUNK 8.0.
- A Kubernetes cluster outside CoreWeave. SUNK Anywhere is SUNK Standard.
When to pick SUNK Self-Service
Pick SUNK Self-Service if you want any of the following:- CoreWeave to operate the Slurm control plane, login pods, shared storage, and user provisioning, and to keep component versions aligned when you upgrade.
- A guided path to a first cluster. If you’re new to SUNK, or to running Slurm on Kubernetes, start with Self-Service.
- The Cloud Console to create the cluster, including the CKS cluster, SCIM setup, and the IAM group.
- A GitOps flow that applies one resource instead of two charts and their values files.
The following are available in both modes, so they aren’t a reason to pick SUNK Standard: the SUNK Pod Scheduler, Pyxis and enroot containers, Docker and privileged containers, custom s6 scripts, custom Prolog and Epilog scripts, the Slurm REST API, GPU straggler detection, and Slurm configuration keys.
SUNK versions by mode
Each SUNK release pairs with one Slurm version. See SUNK to Slurm version mapping.
Next steps
- To create a SUNK Self-Service cluster, see Create a SUNK cluster. For an end-to-end walkthrough of the CR path, see Get started with SUNK using the SunkCluster CR.
- To deploy SUNK Standard, see Manage deployments with CI and GitOps for the ArgoCD app-of-apps pattern, then Configure compute nodes. Both pages predate SUNK 8.0, so check their key names against the SUNK v8.0.0 release note.
- For every configurable field in either mode, see the SunkCluster CR reference or the Slurm parameter reference.