Container storage covers everything from Docker's basic writable layer and volume mounts up through Kubernetes' cluster-wide Persistent Volume system. At the Docker level, volumes, bind mounts, and tmpfs mounts are the three ways to keep or discard data outside a container's ephemeral filesystem. Kubernetes builds on the same core idea at cluster scale: Persistent Volumes (PVs) abstract storage resources from the underlying infrastructure, Persistent Volume Claims (PVCs) let users request storage without knowing implementation details, StorageClasses enable dynamic provisioning, and CSI (Container Storage Interface) drivers standardize how storage providers integrate with Kubernetes. Understanding both layers, plain container storage and cluster-wide orchestrated storage, is essential for running stateful workloads — databases, message queues, file servers — that need data to survive container restarts, pod rescheduling, and cluster failures.
What This Cheat Sheet Covers
This topic spans 22 focused tables and 138 indexed concepts, 119 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Container Storage Fundamentals (Docker)
A container's writable layer disappears the moment the container is removed, so anything that must outlive a restart needs one of Docker's three mount types: volumes, bind mounts, or tmpfs. These are the direct ancestors of the Kubernetes volume model covered later in this sheet, and understanding them first makes every Kubernetes concept below easier to place.
| Type | Example | Description | |
|---|---|---|---|
docker inspect app --format '{{.GraphDriver}}' | • Default location for anything a container creates • unique per container, discarded on docker rm• not meant for write-heavy workloads. | ||
docker run -v data:/app/data nginx | • Docker-managed storage under /var/lib/docker/volumes/• persists independent of any container • preferred choice for databases and app state. | ||
docker run -v /host/path:/container/path nginx | • Maps an absolute host path straight into the container • both sides can edit the same files in real time • standard for local development, not for production data. | ||
docker run --tmpfs /app/cache nginx | • Keeps data in host memory only, never touches disk • lost on stop, restart, or reboot • ideal for secrets or short-lived caches; Linux hosts only. | ||
docker run -v /app/data nginx | • Created automatically with a random name when no source is given • persists after the container exits unless started with --rm. | ||
docker run --mount type=bind,src=/host,dst=/app nginx | • --mount is the explicit, key-value syntax and errors if a bind source is missing instead of silently creating a directory• -v is shorter but more permissive. | ||
docker run -v data:/app:ro nginx | • ro (or readonly with --mount) blocks writes from inside the container• the host can still modify the underlying files. |