9 Adding volumes for storage, configuration, and metadata
This chapter explains how Kubernetes volumes extend pods beyond their containers’ ephemeral filesystems to store data, share files, and surface configuration and metadata. Volumes are defined at the pod level and mounted into one or more containers, surviving container restarts and enabling patterns such as sidecars that read or write shared files. Depending on the backing, volumes can persist only for the pod’s lifetime (for example, emptyDir) or map to external storage that outlives the pod and can be reattached across pod instances. A single pod may use multiple volumes with different performance and access characteristics, mounted read/write or read-only as needed.
The chapter demonstrates practical patterns and trade-offs. With emptyDir, data survives container restarts and can be shared between containers; it can live on disk or in memory (tmpfs) and can be prepopulated via init containers or simple inline scripts. A newer image volume type can expose files directly from an OCI image to other containers without a copier init step. Accessing the node’s filesystem via hostPath is supported but risky and typically reserved for privileged, system-level workloads due to its broad access. The text also covers sharing data across pods using external storage and highlights how storage technology dictates concurrency and access modes.
The chapter then shows how to project configuration and metadata as files with configMap, secret, and downwardAPI volumes, and how to merge them with projected volumes so one mount can hold multiple sources (including a pod’s ServiceAccount token). It details atomic updates via symlinks, the subPath caveat (which disables live updates), and how to set ownership and permissions with defaultMode, per-file mode, and fsGroup so applications can read sensitive files safely. Finally, it notes the kube-api-access projected volume that Kubernetes injects into most pods by default and closes by contrasting ephemeral volumes with persistent storage, leading into the next chapter on PersistentVolumes and PersistentVolumeClaims.
Mounting a filesystem into the file tree
How the Quiz service fits into the architecture of the Kiada Suite
The Quiz API and the MongoDB database run in the same pod
Volumes are defined at the pod level and mounted in the pod’s containers.
Volumes ensure that part of the container’s filesystem is persisted across restarts.
A pod can contain multiple volumes, and a container can mount multiple volumes.
A volume can be mounted into more than one container.
Pod volumes can also map to storage volumes that persist across pod restarts.
Using volumes to share data between pods
The quiz pod with an emptyDir volume for storing MongoDB data files
The emptyDir is a normal file directory in the node’s filesystem mounted into the container.
Using an init container to initialize an emptyDir volume
The new version of the Quote service uses two containers and a shared volume.
A hostPath volume mounts a file or directory from the worker node’s filesystem into the container.
Using subPath to mount a single file from the volume
Projecting a Secret’s entries into the container’s filesystem via a secret volume
Using a projected volume with several sources
Summary
- Pods consist of containers and volumes. Each volume can be mounted at the desired location in the container’s filesystem.
- Volumes are used to persist data across container restarts, share data between the containers in the pod, and even share data between the pods.
- An emptyDir volume is used to store data for the lifetime of the pod. It starts as an empty directory that’s created just before the pod’s containers are started and is deleted when the pod terminates.
- An init container can be used to add files to the emptyDir volume before the pod’s regular containers are started. Regular containers can then add additional files or modify existing files in the volume.
- An image volume can be used to mount an Open Container Initiative (OCI) image or artifact into a container. This is used for static, possibly large files that the container needs for its operation.
- The hostPath volume allows a pod to access any path in the file system of the host node. This volume type is dangerous because it allows users to make changes to the configuration of the host node and run any process on the node.
- The configMap, secret, and downwardAPI volumes are used to project ConfigMap and Secret entries as well as pod metadata into a container. Alternatively, the same can be done with a single projected volume.
- Many other volume types are no longer meant to be directly configured in pods. Instead, a persistentVolumeClaim, ephemeral, or csi volume must be used, which is explained in the next chapter.
Kubernetes in Action, Second Edition ebook for free
