Kubernetes Volumes

Valohai workloads that run on Kubernetes write to the disk of the node they are scheduled on. That disk is shared with every other pod on the node, and its size is whatever the node was built with. When that is not enough, or not fast enough, you can attach volumes to the workload.

This section covers the volume types you can configure, what each one is for, and how to set them up. Volumes are configured on Kubernetes environments and Kubernetes deployment targets. They do not apply to VM or cloud worker environments.

The volume types

A workspace volume is provisioned by Valohai, belongs to one workload and starts empty every time. A cache volume, a shared volume and an NFS mount all point at storage that exists before the workload starts and stays after it ends. NFS mounts are documented in NFS mounts, because they also apply to VM workers.

Workspace volume	Executions and endpoints	A disk Valohai provisions for the workload, empty at the start	One execution, or one endpoint replica
Cache volume	Executions	An existing claim used as an input cache that fills up as executions download data	Until you delete the claim
Shared volume	Endpoints	An existing claim mounted into every replica, optionally read only	Until you delete the claim
NFS mount	Executions	An NFS export mounted into the execution	Until you remove the mount

Which one do I want

• My execution runs out of disk space, or needs faster disk. Use a workspace volume.

• My executions download the same inputs over and over. Use a cache volume.

• My endpoint downloads a model at startup and has nowhere to put it. Use a workspace volume.

• My endpoint replicas need to read the same model files, and I do not want each replica to fetch them. Use a shared volume.

• My data already sits on an NFS server. Use an NFS mount.

• I need data to survive from one execution to the next. Use outputs and inputs, which is what Valohai data management is for. Volumes are not the answer.

Related settings that are not volumes

Ephemeral storage requests and limits on endpoints control how much of the disk of the node a replica may use. They do not add a disk, they only bound the use of the one that is already there. The same applies to the shared memory size of an execution, which is served from memory rather than from a disk.