We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Kubernetes Containers
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Kubernetes Containers
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Containers are ephemeral by design. When a container restarts, whether from a crash, an OOM kill, or a rolling update, its filesystem resets to the original image state. Every file written during runtime disappears. Log files, uploaded images, database WAL segments, temporary computation results. All gone.
This is intentional. Ephemeral containers are predictable, reproducible, and disposable. You can kill one and start another in milliseconds with identical behavior. But some workloads need data that outlives the container. A PostgreSQL database cannot lose its data directory on restart. An upload service cannot discard user files. A machine learning pipeline cannot recompute features from scratch every time a pod is rescheduled.
volumes solve this by providing storage that exists independently of the container lifecycle. A volume can be a directory on the host, a cloud block device, a network file share, or even an in-memory tmpfs. The container mounts the volume like any directory, reads and writes normally, and the data persists even when the container is replaced.
The catch: not all volumes are created equal. Some die with the pod. Some die with the node. Some survive everything. Picking the wrong type for your workload means either losing data or paying for storage you do not need.
| Volume Type | Lifetime | Portable? | Use Case |
|---|---|---|---|
| emptyDir | Pod | No | Scratch space, inter-container sharing |
| hostPath | Node | No | Node-level logs, socket, DaemonSet workloads |
| configMap | Pod | N/A | Configuration files injected as read-only files |
| secret | Pod | N/A | TLS certs, API keys, database passwords |
| persistentVolumeClaim | Independent | Yes | Databases, file storage, anything you cannot lose |
| nfs | Independent | Yes | Shared storage across multiple pods |
emptyDir is created when a pod is scheduled and deleted when the pod is removed. All containers in the pod share it. Spotify uses emptyDir with medium: Memory for in-memory caches that need sub-millisecond access, but the data cap counts against the container's memory limit. A 4GB emptyDir on Memory with a 4GB memory limit will OOM-kill your pod the moment the app allocates anything.
hostPath maps a directory from the host node into the pod. It outlives the pod but is locked to one node. If the pod is rescheduled to a different node, the data stays behind. node-exporter uses hostPath to read /proc and /sys from the host. Most security policies (PodSecurityAdmission, OPA Gatekeeper) block hostPath for regular workloads because it breaks container isolation.
persistentVolumeClaim (PVC) is what you use for real data. It requests storage from a PersistentVolume (PV), which is backed by cloud block storage (AWS EBS, GCP Persistent Disk), a network filesystem (NFS, CephFS, EFS), or local SSDs. When the pod dies, the PVC and PV remain. A new pod mounts the same PVC and continues where the old one left off.