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.
emptyDir 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 the
emptyDir is deleted forever. An
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.
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.
ConfigMap 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
Secret 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
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.