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 come and go. Pods get rescheduled. Nodes get replaced. If storage is tied to any of these, data is lost. A PostgreSQL database running in a pod needs its data to survive everything: pod crashes, rolling updates, node failures, even cluster migrations.
The core insight behind storage is separating the storage resource (the actual disk) from the storage request (what the application needs). This separation means a developer can say "I need 50GB of fast storage" without knowing whether it comes from an AWS EBS volume, a GCP Persistent Disk, or an NFS share on bare metal.
Think of it like renting an apartment. The apartment (PersistentVolume) exists whether or not you live in it. Your lease (PersistentVolumeClaim) connects you to the apartment. If you move out (pod deleted), the apartment still exists with your furniture (data). A new tenant (new pod) can move in and find everything intact.
This separation also gives cluster administrators control over storage policies (encryption, backup, ) without involving application developers. The admin sets up StorageClasses. The developer writes a PVC. Kubernetes does the rest.
Three objects work together to provide persistent storage:
PersistentVolume (PV): A cluster-scoped resource representing a real piece of storage. It could be an EBS volume, a Persistent Disk, an NFS export, or a local SSD. Each PV has a capacity (100Gi), access modes (ReadWriteOnce), and a reclaim policy (Retain or Delete).
PersistentVolumeClaim (PVC): A namespaced request for storage. A developer writes: "I need 10Gi of gp3 storage with ReadWriteOnce access." Kubernetes finds or creates a PV that matches.
StorageClass: A cluster-scoped template that defines how to dynamically provision PVs. Instead of an admin manually creating PVs, the StorageClass tells Kubernetes how to create them on demand. Every major managed Kubernetes service (EKS, GKE, AKS) ships with default StorageClasses.
| Access Mode | Abbreviation | Meaning |
|---|---|---|
| ReadWriteOnce | RWO | One node can mount read-write. Standard for block storage. |
| ReadOnlyMany | ROX | Many nodes can mount read-only. Good for shared config or pre-built datasets. |
| ReadWriteMany | RWX | Many nodes can mount read-write. Requires NFS, EFS, CephFS, or similar. |
| ReadWriteOncePod | RWOP | Only one pod can mount read-write (K8s 1.27+). Stricter than RWO. |