> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# About SUNK

> Run Slurm on Kubernetes with SUNK, in the SUNK Standard or SUNK Self-Service operation mode

export const Banner = ({title, highlight, lead, cta, href, cta2, href2, keepTitle, openChat}) => {
  const primary = cta && openChat ? <button type="button" className="cw-cta" data-cw-open-chat="true">
      {cta}
      <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round" aria-hidden="true"><path d="M5 12h14M13 6l6 6-6 6" /></svg>
    </button> : cta && href ? <a className="cw-cta" href={href}>
      {cta}
      <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round" aria-hidden="true"><path d="M5 12h14M13 6l6 6-6 6" /></svg>
    </a> : null;
  const secondary = cta2 && href2 ? <a className="cw-cta cw-cta-secondary" href={href2}>
      {cta2}
      <svg width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" strokeWidth="2" strokeLinecap="round" strokeLinejoin="round" aria-hidden="true"><path d="M5 12h14M13 6l6 6-6 6" /></svg>
    </a> : null;
  return <div className={keepTitle ? "cw-hero cw-keep-title" : "cw-hero"}>
      <div className="cw-hero-grid" />
      <div className="cw-hero-inner">
        <h1 className="cw-h1">{highlight ? <>{title} <span className="cw-grad">{highlight}</span></> : title}</h1>
        {lead ? <div className="cw-lead">{lead}</div> : null}
        {secondary ? <div className="cw-ctas">{primary}{secondary}</div> : primary}
      </div>
    </div>;
};

<Banner keepTitle={true} title="Training and inference on" highlight="one cluster" lead="CoreWeave SUNK runs Slurm on Kubernetes, letting both batch training jobs and Kubernetes inference workloads share the same GPU pool. You get Slurm scheduling with Kubernetes deployment and higher utilization without running two separate stacks." cta="Train a model on SUNK" href="/products/sunk/tutorials/train-on-sunk" />

<Badge stroke shape="pill" color="blue" size="md">[SUNK Standard](/products/sunk)</Badge>

<Badge stroke shape="pill" color="green" size="md">[SUNK Self-Service](/products/sunk/about-self-service-sunk)</Badge>

<img src="https://mintcdn.com/coreweave-dbfa0e8d/lW-m410I_gVGZZCw/products/sunk/_media/SUNK-v4_1.png?fit=max&auto=format&n=lW-m410I_gVGZZCw&q=85&s=bc5e20032bf26efb0b03a7f35027d656" alt="SUNK logo" width="4309" height="1186" data-path="products/sunk/_media/SUNK-v4_1.png" />

SUNK is CoreWeave's system for running [Slurm](https://slurm.schedmd.com/overview.html) on Kubernetes. Slurm nodes run as Kubernetes Pods on CoreWeave Kubernetes Service (CKS), so Slurm jobs and Kubernetes workloads share the same compute. The Slurm cluster also gains the Node lifecycle management, observability, and GitOps tooling that Kubernetes brings.

Without SUNK, a team picks Slurm or Kubernetes, or runs both and splits its GPUs between them. With SUNK, one pool of compute serves batch training jobs through Slurm and long-running or bursty services through Kubernetes. The [SUNK Pod Scheduler](/products/sunk/discover_sunk/scheduler) arbitrates between them on the same Nodes.

<Note>
  In SUNK, Slurm **nodes** run in Kubernetes **Pods**. These aren't the same as Kubernetes Nodes, which are the worker machines that run the Pods. To distinguish between them, this page capitalizes **Kubernetes** Nodes.
</Note>

## Operation modes

SUNK runs in two operation modes. They run the same Slurm, and your users connect to a login node and submit jobs the same way in either.

**SUNK Standard.** You deploy and operate the `sunk` and `slurm` Helm charts, usually through ArgoCD or another GitOps pipeline. You set every chart value and own each upgrade. SUNK Standard runs SUNK 7.x and SUNK 8.0 and later, and it's the mode that runs outside CoreWeave, as [SUNK Anywhere](/products/sunk/sunk_anywhere/about).

**SUNK Self-Service.** CoreWeave provisions and operates the cluster from a single `SunkCluster` resource that you manage through the Cloud Console or `kubectl`. SUNK Self-Service requires SUNK 8.0 or later and is the recommended mode for a new cluster on CKS.

<Columns cols={2}>
  <Card title="Choose a SUNK operation mode" href="/products/sunk/choose-operation-mode" arrow="true">
    What each mode gives you, and which one to pick for what your cluster has to do.
  </Card>

  <Card title="About SUNK Self-Service" href="/products/sunk/about-self-service-sunk" arrow="true">
    What CoreWeave provisions and operates for you, and what stays on your side.
  </Card>
</Columns>

## SUNK Standard in depth

Two Helm charts make up a SUNK Standard deployment. The `sunk` chart installs the SUNK operator and the cluster-wide components it depends on, such as the MOCO MySQL operator. It can also install the NVIDIA device plugin, which is off by default. The `slurm` chart describes one Slurm cluster: its control plane, login Pods, compute node definitions, Slurm configuration, and accounting database.

In SUNK 7.x, the `slurm` chart rendered every component of the cluster directly. In SUNK 8.0 and later, the chart renders a `SlurmCluster` resource for the control plane, login Pods, and accounting, plus the compute NodeSets. The SUNK operator builds the cluster from them. Most keys keep their names, but the defaults you don't set now come from the operator. Upgrading from 7.x to 8.0 isn't a routine `helm upgrade`, so read the [SUNK v8.0.0 release note](/release-notes/sunk-8-0) first.

Start with these pages:

* [Manage a SUNK Standard deployment with CI and GitOps](/products/sunk/deploy_sunk/manage-deployment-with-ci) for the ArgoCD app-of-apps pattern and the `NodeSet` sync customization. Its examples predate SUNK 8.0, so check key names against the release note.
* [Configure compute nodes for SUNK Standard](/products/sunk/deploy_sunk/configure-compute-nodes) for node definitions, partitions, and images.
* [Bind NodeSets to Node Pools for SUNK Standard](/products/sunk/deploy_sunk/bind-nodesets-to-node-pools) to place Slurm nodes on specific CKS Node Pools.
* [SUNK parameter reference](/products/sunk/reference/sunk-parameters) and [Slurm parameter reference](/products/sunk/reference/slurm-parameters) for every chart value.

## How SUNK works

The following pieces make SUNK work:

* **Compute and login nodes are Pods.** Each Slurm compute node is a Pod running `slurmd`, placed one-to-one on a Kubernetes Node. Login nodes are Pods with exposed IP addresses that users connect to over SSH. See [Compute and login nodes](/products/sunk/discover_sunk/compute_and_login_nodes).
* **NodeSets define compute.** A NodeSet declares a group of Slurm nodes: image, resource requests, affinity, and replica count. Its controller creates the Pods and scales the set. See [NodeSet](/products/sunk/discover_sunk/nodeset).
* **The Syncer keeps both sides in agreement.** It mirrors state between Slurm nodes and their Pods in both directions, so a Pod that isn't ready shows as a drained Slurm node. See [Syncer](/products/sunk/discover_sunk/syncer).
* **The SUNK Pod Scheduler shares Nodes.** Pods that name it as their scheduler are placed through Slurm's own scheduling logic, on the same Nodes as Slurm jobs and under Slurm's priority and preemption rules. See [SUNK Pod Scheduler](/products/sunk/discover_sunk/scheduler).
* **SlurmCluster carries cluster-wide Slurm configuration** and generates `topology.conf` from Node labels. See [SlurmCluster](/products/sunk/discover_sunk/slurmcluster).
* **Slurm runs from images CoreWeave publishes.** The `slurmd` images ship per CUDA version, built on NCCL test images. Controller and login images ship per Ubuntu version. See [Slurm images](/products/sunk/reference/slurm-images).

## Key features

SUNK supports the following:

* Containerized jobs through Pyxis and Enroot, including Docker workflows. See [Use Docker in SUNK](/products/sunk/run_workloads/docker-in-docker).
* Topology-aware scheduling with Slurm's tree and block plugins. See [Topology and block scheduling in Slurm](/products/sunk/optimize_workloads/topology-scheduling).
* GPU straggler detection for multi-node training jobs. See [Introduction to GPU straggler detection](/products/sunk/discover_sunk/straggler-detection).
* Prolog and Epilog scripts that prepare a node before a job and clean up after it. See [Run Prolog and Epilog scripts on SUNK](/products/sunk/run_workloads/prolog-epilog).
* s6 scripts that install software and configure Slurm nodes at startup. See [Run custom scripts with s6](/products/sunk/run_workloads/run-scripts-with-s6).
* Task plugins and cgroups for CPU, memory, and GPU binding. See [Manage resource binding with task plugins](/products/sunk/optimize_workloads/task-plugins).
* User provisioning from CoreWeave Identity and Access Management (IAM) through SCIM, so POSIX identities, SSH keys, and Slurm accounts follow your identity provider. See [Provision users in SUNK](/products/sunk/manage_sunk/manage_cluster_access/sunk_user_provisioning).
* On SUNK Standard only: custom images, Lua plugin files, and LDAP directories. [Choose a SUNK operation mode](/products/sunk/choose-operation-mode) has the full list.

## Next steps

* [Choose a SUNK operation mode](/products/sunk/choose-operation-mode) if you haven't picked one yet.
* [Create a SUNK Self-Service cluster](/products/sunk/deploy_sunk/create-sunk-cluster) to start a SUNK Self-Service cluster from the Cloud Console or the `SunkCluster` CR.
* [Manage a SUNK Standard deployment with CI and GitOps](/products/sunk/deploy_sunk/manage-deployment-with-ci) to deploy SUNK Standard with ArgoCD.
* [Train on SUNK](/products/sunk/tutorials/train-on-sunk) to set up a cluster, submit a training job, and monitor it.