Ephemeral Volumes [page]deterministic

This document describes _ephemeral volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested, in particular PersistentVolumeClaim and PersistentVolume.

Some applications need additional storage but don't care whether that data is stored persistently across restarts. For example, caching services are often limited by memory size and can move infrequently used data into storage that is slower than memory with little impact on overall performance.

Other applications expect some read-only input data to be present in files, like configuration data or secret keys.

_Ephemeral volumes_ are designed for these use cases. Because volumes follow the Pod's lifetime and get created and deleted along with the Pod, Pods can be stopped and restarted without being limited to where some persistent volume is available.

Ephemeral volumes are specified _inline_ in the Pod spec, which simplifies application deployment and management.

### Types of ephemeral volumes

Kubernetes supports several different kinds of ephemeral volumes for different purposes: - [emptyDir](/docs/concepts/storage/volumes/#emptydir): empty at Pod startup, with storage coming locally from the kubelet base directory (usually the root disk) or RAM - [configMap](/docs/concepts/storage/volumes/#configmap), [downwardAPI](/docs/concepts/storage/volumes/#downwardapi), [secret](/docs/concepts/storage/volumes/#secret): inject different kinds of Kubernetes data into a Pod - [image](/docs/concepts/storage/volumes/#image): allows mounting container image files or artifacts, directly to a Pod. - [CSI ephemeral volumes](#csi-ephemeral-volumes): similar to the previous volume kinds, but provided by special [CSI](#gloss:csi) drivers which specifically [support this feature](https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html) - [generic ephemeral volumes](#generic-ephemeral-volumes), which can be provided by all storage drivers that also support persistent volumes

`emptyDir`, `configMap`, `downwardAPI`, `secret` are provided as [local ephemeral storage](/docs/concepts/storage/ephemeral-storage/). They are managed by kubelet on each node.

CSI ephemeral volumes *must* be provided by third-party CSI storage drivers.

Generic ephemeral volumes *can* be provided by third-party CSI storage drivers, but also by any other storage driver that supports dynamic provisioning. Some CSI drivers are written specifically for CSI ephemeral volumes and do not support dynamic provisioning: those then cannot be used for generic ephemeral volumes.

The advantage of using third-party drivers is that they can offer functionality that Kubernetes itself does not support, for example storage with different performance characteristics than the disk that is managed by kubelet, or injecting different data.

### CSI ephemeral volumes

> Note: CSI ephemeral volumes are only supported by a subset of CSI drivers. The Kubernetes CSI [Drivers list](https://kubernetes-csi.github.io/docs/drivers.html) shows which drivers support ephemeral volumes.

Conceptually, CSI ephemeral volumes are similar to `configMap`, `downwardAPI` and `secret` volume types: the storage is managed locally on each node and is created together with other local resources after a Pod has been scheduled onto a node. Kubernetes has no concept of rescheduling Pods anymore at this stage. Volume creation has to be unlikely to fail, otherwise Pod startup gets stuck. In particular, [storage capacity aware Pod scheduling](/docs/concepts/storage/storage-capacity/) is *not* supported for these volumes. They are currently also not covered by the storage resource usage limits of a Pod, because that is something that kubelet can only enforce for storage that it manages itself.

Here's an example manifest for a Pod that uses CSI ephemeral storage:

```yaml kind: Pod apiVersion: v1 metadata: name: my-csi-app spec: containers: - name: my-frontend image: busybox:1.28 …(trimmed)