Pod Volume Model
What is a Pod volume, and why does a file in it outlive the container that wrote it? A volume is declared once under spec.volumes and belongs to the Pod, and each container that wants it lists it in volumeMounts at a path of its own and optionally read-only, the usual way containers of one Pod share files. An init container can write a file and exit, the app can crash and restart, and an emptyDir like this one keeps the data until the Pod leaves its Node.
Play the animation 6 steps, animated, best on a wide screen
Pod Volume Model, step by step
-
The Pod spec names one emptyDir volume, cache, under spec.volumes. It belongs to the Pod, not to a container: it is created empty when the Pod is assigned to a Node, before any container starts. Its bar starts with the Pod bar.
Play from step 1 -
The init container seed runs first, to completion. Its own volumeMounts entry puts cache at /work, where it writes config.json, then it exits. Its bar ends and its mount goes with it, but the file stays in the volume.
Play from step 2 -
Now app and log-shipper start, and each lists cache in a volumeMounts entry of its own: app at /data, log-shipper at /logs with readOnly set. App opens /data/config.json and finds the file seed left, although seed no longer runs.
Play from step 3 -
Both containers see the same bytes under different paths. App writes app.log into /data, and log-shipper reads that very file at /logs through a mount that cannot write. That is the usual way two containers of one Pod share files.
Play from step 4 -
App crashes, and restartPolicy Always, the default, restarts it in the same Pod, so its restart count goes to 1. The new container starts clean outside the volume, yet it mounts the same cache at /data and app.log is still there.
Play from step 5 -
No container bar spans the whole story, and none of them ever owned the volume. The cache bar is the Pod bar: this emptyDir lasts until the Pod leaves its Node, however many containers come and go inside it.
Play from step 6