Container filesystems are ephemeral — when a container restarts, any data written to its filesystem is lost. For stateless applications (APIs, web servers) this is fine: no data should be stored locally anyway. But databases, file storage services, and any application that must persist data across container restarts need access to storage that outlives the container. Kubernetes addresses this through a three-layer storage abstraction. PersistentVolumes (PVs) represent actual storage resources — an AWS EBS volume, a GCP persistent disk, an NFS share, or a local disk. PersistentVolumeClaims (PVCs) are requests for storage by a Pod, specifying desired size, access mode, and storage class. StorageClasses enable dynamic provisioning — when a PVC requests storage with a specific StorageClass, Kubernetes automatically provisions a new PersistentVolume to satisfy the claim. This three-layer design decouples what storage exists (PV) from what storage is needed (PVC) from how storage is provisioned (StorageClass).
35 minintermediate
Persistent Volumes and Claims
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 14 of 24
0% complete