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 PersistentVolume resources to manage the lifecycle of durable storage types, rather than directly specifying them.
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 below:
An ephemeral volume type that 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. emptyDir volumes are stored on whatever medium is backing the node. This might be a disk, SSD, or network storage depending on your environment. emptyDirs 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
Memoryto tell Kubernetes to mount a tmpfs (RAM- backed filesystem). However, this is not supported in Windows Server containers.
The ConfigMap resource provides a way to inject configuration data into Pods. The data stored in a ConfigMap 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 by a ConfigMap resource.
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.
Used to make 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.
Cluster operators can provision durable storage to be used by applications. A Pod uses a PersistentVolumeClaim to mount a volume that is backed by this durable storage.
For a complete list of volume types, refer to the Kubernetes Volumes documentation.
- 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.