Skip to main content
Self-Service SUNK is CoreWeave’s managed product for running SUNK on CoreWeave Kubernetes Service (CKS). You declare a Slurm cluster as a single Kubernetes resource, and CoreWeave provisions and operates it for you, including compute nodes, the Slurm control plane, login pods, shared storage, and user access. Self-Service SUNK is for teams that want SUNK without taking on the operational burden of installing the SUNK Helm chart, wiring up node pools, and keeping component versions in sync. If you’re evaluating SUNK, or are new to running Slurm on Kubernetes, Self-Service SUNK is the recommended entry point. For an introduction to the underlying technology, see About SUNK.
Self-Service SUNK is in limited availability. To request access for your account, contact your CoreWeave Solutions Architect.

​
What Self-Service SUNK provisions

When you create a Self-Service SUNK cluster, CoreWeave sets up the following:
  • A CKS cluster, when you choose to provision a new one through the Cloud Console.
  • One node pool and one node set for each entry in your cluster’s nodes list, kept in sync automatically as you scale.
  • The Slurm control plane, including its MySQL database, running as Kubernetes Pods.
  • Login pods that your users SSH into, sized per user or per group.
  • Shared storage volumes for home directories and additional mounts.
  • The supporting cluster components that Slurm needs, such as GPU device scheduling, deployed and managed for you. You don’t assemble or maintain these yourself.
  • User provisioning through SCIM and an Identity and Access Management (IAM) group for cluster access, when you use the Cloud Console path.
You configure all of this with a single SunkCluster Kubernetes resource. CoreWeave keeps the underlying components reconciled, scales the cluster when you change node counts, and reports overall progress with status conditions that you can inspect with kubectl.

​
What stays on your side

Self-Service SUNK provisions and maintains the cluster. The following remain your responsibility:
  • Submitting and managing Slurm jobs through sbatch, srun, and the rest of the Slurm CLI.
  • Building or selecting the container images that your Slurm jobs run through Pyxis and enroot, separate from the slurmd, login, and control plane images that CoreWeave provides.
  • Designing your Slurm partition layout and quality-of-service policies beyond the defaults.
  • Managing the data you store in the shared volumes and the lifecycle of that data.
  • Adding users to the IAM groups that grant cluster access, and making sure each user has an SSH public key on their CoreWeave profile.
  • Monitoring and acting on job-level observability data, even though cluster-level health is reported through SunkCluster status conditions.

​
Self-Service SUNK compared to SUNK

SUNK is CoreWeave’s technology for running Slurm on Kubernetes. It consists of a Helm chart, a set of CRDs, and a Kubernetes operator that runs inside a cluster to schedule Slurm jobs alongside Kubernetes workloads. Self-Service SUNK is the managed product built on top of SUNK. It adds:
  • A single, higher-level resource (SunkCluster) that captures the full cluster definition. You don’t manage the SUNK Helm chart, node pool configuration, or individual SUNK CRDs by hand.
  • A CoreWeave-managed control plane that provisions and maintains those underlying components.
  • Optional integration with the Cloud Console for guided cluster creation and user provisioning.
You can think of SunkCluster as the entry point and SUNK as the runtime. When you change a SunkCluster, CoreWeave reconciles the change into the SUNK components that actually run Slurm.

​
Architecture at a glance

Self-Service SUNK is built around a CoreWeave-managed control plane that operates outside your CKS cluster:
  • CoreWeave-managed control plane. This control plane watches SunkCluster resources and reconciles them into the underlying SUNK components. CoreWeave operates and upgrades it. You don’t install or maintain it yourself.
  • Your CKS cluster. The Slurm control plane, login pods, compute nodes, and SUNK CRDs all run inside your CKS cluster. This is where Slurm jobs execute and where your users connect.
When you submit a SunkCluster resource, the managed control plane creates and updates the node pools, node sets, the SlurmCluster resource, shared storage, and supporting components in your cluster. Your day-to-day workflow stays in kubectl against your CKS cluster. The managed control plane runs out of band, so cluster upgrades and operator maintenance don’t require any action on your side.

​
Two ways to manage your cluster

You can create and manage Self-Service SUNK clusters in two ways:
  • Cloud Console: a guided form with a live YAML preview. The Console can also create a new CKS cluster, enable the SCIM API for user provisioning, and create an IAM group during cluster creation.
  • SunkCluster resource: apply YAML directly to your CKS cluster. This is the GitOps-friendly path. CKS cluster creation, SCIM setup, and IAM group creation are separate manual steps.
Both paths submit the same SunkCluster resource. The Console emits YAML that you can copy into source control, and a cluster created in the Console can be edited later with kubectl. For step-by-step instructions and a full prerequisites list, see Create a SUNK cluster.

​
Next steps

Last modified on July 14, 2026