Skip to main content
This page shows SUNK administrators how to provision shared storage for Slurm compute and login nodes by mounting Persistent Volume Claims (PVCs). Use shared storage when you need to share job inputs and outputs across nodes, host user home directories, or give multiple users access to a common dataset. In Kubernetes, to ensure that data persists beyond the lifecycle of a given Pod, you can use Persistent Volume Claims (PVCs). A PVC is a request for storage by a user that you can provision from a Persistent Volume (PV). This mechanism lets you abstract the details of how the storage is provided and how it’s consumed. In SUNK, each Slurm node is deployed in a Kubernetes Pod, which can mount shared PVCs in the normal manner. SUNK provides a mechanism to map the Kubernetes Pod’s PVC to a specified mount location within the Slurm node. Multiple Slurm nodes can mount the same PVC. This is particularly useful when managing jobs that require sharing access between developers or researchers, storing user home directories, and saving job output for further processing.

​
Create shared storage

This section walks through provisioning the PVCs that the compute nodes mount. In this example, three PVCs are mounted to the Slurm compute nodes. To get started, create three PVCs in the cluster with a Container Storage Interface (CSI) driver that supports the ReadWriteMany access mode, which is required so multiple nodes can mount the same volume simultaneously. For more information about creating PVCs, see the Kubernetes documentation on Persistent Volumes. Use the following names so they match the references in the mount configuration that follows:
  • data-root
  • data-nvme
  • data-hdd

​
Mount PVCs

With the PVCs in place, configure the Slurm compute nodes to mount them. Mount the PVCs to the Slurm nodes by adding the volumeMounts and volumes keys in the compute section of values.yaml: 
compute:
  volumeMounts:
    - name: root-nvme # root home dir, useful if not using LDAP and connecting with `kubectl exec`
      mountPath: /root
    - name: data-nvme # Mount for high-speed storage
      mountPath: /mnt/nvme
    - name: data-hdd # Mount for high-capacity bulk storage
      mountPath: /mnt/hdd
  volumes:
    - name: root-nvme # This is useful if not using ldap
      persistentVolumeClaim:
        claimName: root-nvme
    - name: data-nvme # The high-speed storage PVC
      persistentVolumeClaim:
        claimName: data-nvme
    - name: data-hdd # The high-capacity bulk storage PVC
      persistentVolumeClaim:
        claimName: data-hdd
See compute.volumeMounts and compute.volumes in the Slurm Parameter Reference for a link to a full values.yaml example. After you apply this configuration, the three PVCs are available at the specified mount paths on every Slurm compute node.

​
Login node

This section explains how shared storage is exposed on the login node. For convenience, the login node automatically receives any volumeMounts and volumes specified for the compute nodes in values.yaml. You don’t need to specify these again for the login node.

​
Use shared storage

The following examples illustrate common patterns for working with the mounted PVCs from a login node. After you mount the PVCs, you can use them as you would any other storage. For example, you can create a directory in the PVC and use it to store job output, as shown in the following example: 
# On the login node
mkdir /mnt/nvme/job-output
# Mount is accessible on all compute nodes
srun -N 1 -n 1 hostname > /mnt/nvme/job-output/$(hostname).txt
You can also use the PVCs to share data between users. For example, you can create a directory in the PVC and use it to store data that multiple users can access: 
# On the login node
mkdir /mnt/nvme/shared-data
# Mount is accessible on all compute nodes
srun -N 1 -n 1 hostname > /mnt/nvme/shared-data/$(hostname).txt
Storing user home directories in a PVC is also useful. This lets users access their home directories from any compute node. In this example, the root home directory is mounted to the PVC named data-root. This is useful if you aren’t using LDAP and you connect with kubectl exec, and you have helper scripts or other files in the root home directory.
Last modified on May 27, 2026