Kubernetes's storage model separates the concern of storage provisioning from storage consumption through a three-level abstraction: StorageClasses define how storage is provisioned (which driver, which cloud tier, which performance characteristics); PersistentVolumes represent actual provisioned storage units; and PersistentVolumeClaims are requests for storage that bind to PersistentVolumes matching their requirements. This separation is what allows a developer to request '100 GiB of block storage for a PostgreSQL database' in a PersistentVolumeClaim without knowing whether that storage will be an AWS EBS gp3 volume, a GCP Persistent Disk SSD, or an on-premises Ceph block device — the StorageClass resolves the implementation transparently. Dynamic provisioning, enabled by StorageClasses with a `provisioner` field, eliminates the need to pre-provision PersistentVolumes manually: when a PVC is created, the storage driver (CSI plugin) provisions the underlying storage automatically and creates a matching PV, completing the bind in seconds.
25 minintermediate
PersistentVolumes, PersistentVolumeClaims and StorageClasses
Analogy🏏Cricket
🏏 Think of it like cricket: The Pod-ReplicaSet-Deployment hierarchy maps precisely onto the three levels of IPL franchise team management. A Pod is a single player on the field at a given moment — the smallest unit of participation, carrying its own identity and fulfilling a specific role in the current game. A ReplicaSet is the franchise's match-day playing XI contract — it specifies that exactly eleven players matching a specific profile must always be on the field; if one is injured and leaves, the team management immediately sends a substitute of the same profile to restore the count. A Deployment is the franchise's season-long team strategy — it manages how the playing XI evolves between matches: when a new batting approach is adopted, the Deployment replaces the old XI with the new one in a controlled rolling substitution rather than swapping all eleven players simultaneously and disrupting team cohesion. Just as the franchise director does not manage individual players directly — the playing XI contract (ReplicaSet) handles the count and the season strategy (Deployment) handles the transitions — you never manage Pods directly in production; the Deployment manages the transition and the ReplicaSet maintains the count. This reveals why the three-level hierarchy exists rather than one omnibus 'workload' object: each level solves one specific problem, and composing three focused abstractions produces better separation of concerns than one object that conflates scheduling, scaling, and update management.
Lesson 18 of 33
0% complete