8.11 Kubernetes Pod Volume Usage

Kubernetes Pod Volume Usage is the manifest-authoring practice of declaring storage resources within a Pod's spec.volumes array and attaching them into one or more containers through volumeMounts, covering the range of volume source types available, how they are mounted, and the practical patterns manifest authors use to share data between containers or persist it beyond a single container's lifetime.

Declaring a Volume at the Pod Level

The volumes Array as a Source Catalog

Each entry in spec.volumes gives a volume a name and specifies exactly one source type, an emptyDir, a configMap, a secret, a persistentVolumeClaim, a downwardAPI, or a projected combination among others, defining where that volume's actual content comes from before any container mounts it.

Volumes Exist Independently of Any Single Container

Because volumes are declared at the Pod level rather than within an individual container, the same named volume can be referenced and mounted by multiple containers within the Pod simultaneously, each potentially mounting it at a different path or with different read-only settings.

Common Volume Source Types in Practice

emptyDir for Ephemeral Shared Scratch Space

An emptyDir volume provides empty, writable storage created fresh when the Pod starts and deleted when the Pod is removed, commonly used as shared scratch space between containers in a Pod, such as a main application writing files that a sidecar container processes.

configMap and secret for Configuration Injection

configMap and secret volumes expose the referenced object's data as files within the container's filesystem, one file per key by default, a common alternative to environment variable injection particularly suited to configuration an application expects to read from disk rather than from its environment.

persistentVolumeClaim for Durable Storage

A persistentVolumeClaim volume attaches storage that persists independently of the Pod's own lifecycle, surviving Pod restarts and rescheduling, appropriate for workloads such as databases that need their data to outlive any single Pod instance.

projected for Combining Multiple Sources

A projected volume combines content from multiple sources, such as a ConfigMap, a Secret, and Downward API fields, into a single mounted directory, reducing the number of separate volume mounts a container needs when it requires files from several distinct sources at once.

Mounting Volumes Into Containers

The volumeMounts Array

Within an individual container's spec, volumeMounts references a Pod-level volume by name and specifies the mountPath where its content should appear inside that container's filesystem, with each container free to mount only the volumes it actually needs, at whatever paths make sense for its own application.

subPath for Mounting a Portion of a Volume

The subPath field allows a container to mount only a specific file or subdirectory from within a larger volume, rather than the volume's entire content, useful when a single ConfigMap or Secret volume contains data relevant to multiple different mount locations across different containers.

readOnly Mounts

Setting readOnly: true on a volume mount prevents the container from writing to that mount, appropriate for configuration data, such as ConfigMap and Secret volumes, that a container should only ever read and never modify, reducing the risk of a misbehaving container corrupting shared configuration.

Mount Propagation Considerations

Controlling Visibility of Mount Changes

The mountPropagation field, with values including None, HostToContainer, and Bidirectional, controls whether mounts created on the host after the container started become visible inside the container, or vice versa, a specialized setting relevant primarily to certain storage-related workloads rather than typical application containers.

Practical Patterns Combining Multiple Volumes

Layering Configuration and Scratch Space Together

A typical Pod might combine a configMap volume mounted read-only for application configuration, a secret volume mounted read-only for credentials, and an emptyDir volume mounted read-write for temporary working files, each serving a distinct purpose within the same Pod's overall volume usage.

Consistency Between Init Containers and Main Containers

When an init container populates a shared emptyDir volume for a main container to later consume, both the init container and the main container must independently declare a matching volumeMounts entry referencing the same Pod-level volume name, since volume declarations at the Pod level do not automatically imply any particular container will mount them.