Topic 16

Volumes

StorageCore

A container's filesystem is ephemeral: when the container restarts, anything written to it is gone. A Volume is storage attached to a Pod that outlives an individual container restart and can be shared between containers in the Pod. It is the first layer of the storage story, before persistence enters the picture.

Volumes range from throwaway scratch space to mounted configuration to durable disks. This topic covers the non-persistent ones and the model; the durable kind — PersistentVolumes — is the next topic.

Why the Container Filesystem Isn't Enough

Each container starts from its image with a fresh, writable layer that is discarded when the container is removed. That is fine for stateless processing but useless for anything that must survive a restart, be shared between containers, or hold real data. A Volume is defined at the Pod level and mounted into containers, so its lifetime is tied to the Pod (or to external storage), not to a single container's life.

emptyDir: Scratch Space

An emptyDir volume is created empty when the Pod is assigned to a node and lives as long as the Pod runs on that node. It survives container restarts within the Pod but is deleted when the Pod is removed or rescheduled. It is for scratch space, caches, and sharing files between containers in the same Pod. Backed by node disk by default, it can be memory-backed with medium: Memory for speed — at the cost of counting against the Pod's memory.

An emptyDir shared between two containers

spec:
  containers:
    - name: app
      image: my-app:1.0
      volumeMounts:
        - name: cache
          mountPath: /cache
    - name: sidecar
      image: helper:1.0
      volumeMounts:
        - name: cache
          mountPath: /data
  volumes:
    - name: cache
      emptyDir: {}

hostPath and Its Dangers

A hostPath volume mounts a file or directory from the node's own filesystem into the Pod. It is occasionally necessary for node-level agents (a log collector reading /var/log), but it is dangerous for ordinary workloads: it ties the Pod to a specific node's contents, breaks when the Pod reschedules elsewhere, and can be a serious security hole — a Pod with the wrong hostPath can read or write the host. Treat hostPath as a node-agent tool, not application storage.

Projected Volumes

Some volumes exist to surface Kubernetes data into a Pod as files. A configMap or secret volume mounts that object's keys as files; a downwardAPI volume exposes Pod metadata (labels, resource limits); a projected service-account token volume mounts a short-lived API token. A projected volume combines several of these sources into one directory. These are how configuration and identity reach a container as files rather than environment variables (Topic 10).

emptyDir vs hostPath vs persistent

emptyDir — node-local scratch, lives with the Pod. Lost on reschedule. For caches and intra-Pod sharing.

hostPath — a path on the node itself. Node-bound and risky — for node agents only.

PersistentVolume — durable storage that survives the Pod and follows it across nodes (Topic 17).

Common Mistakes

Using hostPath for application data, tying the Pod to one node and opening a security hole.
Expecting emptyDir to survive a reschedule — it is deleted when the Pod moves to another node.
Forgetting that a memory-backed emptyDir counts against the Pod's memory and can trigger OOM.
Mounting secrets via hostPath instead of a secret volume, defeating Kubernetes' handling of them.
Letting an emptyDir fill the node's disk because no size limit was set.

Best Practices

Use emptyDir for scratch and intra-Pod sharing; never assume it persists past the Pod.
Restrict hostPath to node-level agents that genuinely need host access, and scope it tightly.
Surface config, secrets, and identity through configMap/secret/projected volumes, not ad-hoc paths.
Set size limits on emptyDir to keep a runaway Pod from filling node disk.
For anything that must survive the Pod, use a PersistentVolumeClaim, not a node-local volume.

RelatedPersistentVolumes — durable storage that outlives the Pod (Topic 17)ConfigMaps & Secrets — consumed via projected volumes (Topic 10)Ephemeral container storage — the writable image layer a Volume supplements

Knowledge Check

What happens to an emptyDir volume when its Pod is rescheduled to another node?

It is deleted — emptyDir lives only as long as the Pod runs on its node
It moves with the Pod to the new node and keeps all of its existing data intact
It is automatically converted to a PersistentVolume on reschedule
It is backed up to the container image registry first

Why is hostPath dangerous for ordinary application workloads?

It ties the Pod to one node's filesystem and can expose or modify host contents
It is slower than every other Kubernetes volume type, even on a local SSD-backed disk
It cannot be mounted read-only under any circumstance
It requires cluster-admin privileges to create or mount

How does configuration from a ConfigMap reach a container as files?

Through a configMap (or projected) volume mounted into the container
Through a hostPath volume mounting the node's own directory
Only as environment variables injected at container startup, never as files
Through a read-only layer baked into the container image

You got correct