9 Adding Volumes for Storage, Configuration, and Metadata

This chapter explains how Kubernetes volumes complement containers inside a pod to handle data persistence, file sharing, configuration, and metadata. It clarifies that containers have ephemeral filesystems, so volumes are defined at the pod level and mounted into containers to persist selected files across container restarts, share data between sidecars, or expose configuration and pod details as files. You learn when and why to use different volume types, how mounts behave, and what trade-offs exist for security, performance, and lifecycle. The chapter focuses on ephemeral volumes such as emptyDir, hostPath, configMap, secret, downwardAPI, projected, and the new image volume, while pointing to persistent storage via PersistentVolumeClaim in the next chapter.

Through hands-on examples, you add an emptyDir volume to a quiz service pod so MongoDB data survives container restarts, then initialize it with data via an init container and, later, more simply via an image volume that mounts an OCI image’s files read-only (feature-gated). You also see how one volume can be mounted in multiple containers to share files (for example, a quote writer and nginx), how mount options like readOnly and recursiveReadOnly improve safety, and how subPath mounts target a single file without hiding an existing directory. The chapter covers performance and security nuances—using tmpfs (emptyDir.medium: Memory) for speed or sensitive data, applying size limits, and remembering that emptyDir data is lost when the pod is deleted.

The chapter then shows how hostPath exposes the node’s filesystem into a pod and why it’s powerful but dangerous and typically reserved for privileged/system workloads. You project configuration and sensitive material as files with configMap and secret volumes, mark them optional, and understand their atomic, symlink-based update mechanism; moreover, you learn file permission and ownership controls (defaultMode, per-item mode, and fsGroup) to make applications like Envoy read keys securely. Pod metadata and resource values can be surfaced as files via downwardAPI, and multiple sources can be merged into a single directory with projected volumes—mirroring how every pod gets a built-in kube-api-access projected volume for API authentication. Overall, you gain practical patterns and guardrails for storage, configuration, and metadata within pod lifecycles, setting the stage for persistent storage in the following chapter.

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 that’s 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

• 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, but this is explained in the next chapter.

FAQ