This page provides an overview of volumes in Kubernetes, and their use with Google Kubernetes Engine (GKE).
On-disk files in a container are the simplest place for an application to write data, but this approach has drawbacks. The files are lost when the container crashes or stops for any other reason. Furthermore, files within a container are inaccessible to other containers running in the same Pod. The Kubernetes Volume abstraction addresses both of these issues.
Conceptually, a volume is a directory which is accessible to all of the containers in a Pod. The volume source declared in the Pod specification determines how the directory is created, the storage medium used, and the directory's initial contents. A Pod specifies what volumes it contains and the path where containers mount the volume.
Ephemeral volume types have the same lifetimes as their enclosing Pods. These volumes are created when the Pod is created, and they persist through container restarts. When the Pod terminates or is deleted, its volumes go with it.
Other volume types are interfaces to durable storage that exist independently
of a Pod. Unlike ephemeral volumes, data in a volume backed by durable storage
is preserved when the Pod is removed. The volume is merely unmounted and the
data can be handed off to another Pod. You should use
resources to manage the lifecycle of durable storage types, rather than directly
Types of volumes
Volumes differ in their storage implementation and their initial contents. You can choose the volume source that best fits your use case. Several common volume sources are described in the following sections. For a complete list of volume types, refer to the Kubernetes Volumes documentation.
volume provides an empty directory that containers in the Pod can read
and write from. When the Pod is removed from a node for any reason, the data in
emptyDir is deleted forever. An
emptyDir volume is stored on whatever
medium is backing the node, which might be a disk, SSD, or network storage
depending on your environment.
emptyDir volumes are useful for scratch space
and sharing data between multiple containers in a Pod.
emptyDir mounts are part of node ephemeral storage, which also includes
the container writable layer and logs. By default, GKE
Autopilot sets the ephemeral storage to 1 GiB to give your app a little
room to create some files. If you need more or less, you can tune your ephemeral
storage in your Deployment by setting a resource request for
If you are using containers with Linux node pools, you can set the
emptyDir.medium field to
Memory to tell Kubernetes to mount a tmpfs
(RAM-backed filesystem). However, this is not supported in Windows Server containers.
resource provides a
way to inject configuration data into Pods. The data stored in a
object can be referenced in a volume of type
ConfigMap and then consumed
through files running in a Pod. The files in a
ConfigMap volume are specified
volume is used to make sensitive data, such as passwords, OAuth tokens, and SSH
keys, available to applications. The data stored in a
Secret object can be
referenced in a volume of type
Secret and then consumed through files running
in a Pod.
volume makes Downward API
data available to applications. This data includes information about the Pod and
container in which an application is running in. For example, a Pod can be
configured to expose a
DownwardAPIVolumeFile to applications that includes the
Pod's namespace and IP address. For a complete list of the types of data you can
add, see Capabilities of the Downward API.
volume can be used by cluster operators to provision durable storage to be used
by applications. A Pod uses a
PersistentVolumeClaim to mount a volume that is
backed by this durable storage.
- Learn how to reference volumes in a Pod.
- Learn about PersistentVolumes, PersistentVolumeClaims, and dynamic storage provisioning.
- Configure a Pod to use a volume for storage.
- Add ConfigMap data to a volume.