> For the complete documentation index, see [llms.txt](https://docs.valohai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.valohai.com/data/kubernetes-volumes.md).

# 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](https://docs.valohai.com/data/data-nfs), 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](/data/data-nfs.md) | 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](/data/data-nfs.md).
* 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.<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.valohai.com/data/kubernetes-volumes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.