Volumes

Autopilot Standard

This page provides an overview of volumes in Kubernetes, and their use with Google Kubernetes Engine (GKE).

Overview

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 in the following sections. For a complete list of volume types, refer to the Kubernetes Volumes documentation.

emptyDir

An 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 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.

All 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 ephemeral-storage.

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

A 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.

Secret

A 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 of type Secret and then consumed through files running in a Pod.

downwardAPI

A downwardAPI 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.

PersistentVolumeClaim

A PersistentVolumeClaim 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.