Storage in Kubernetes ranges from ephemeral volumes (lost when Pod dies) to persistent volumes (survive Pod restarts). Understanding PersistentVolumes, PersistentVolumeClaims, StorageClasses, and StatefulSets is essential for stateful workloads.
Storage in Kubernetes ranges from ephemeral volumes (lost when Pod dies) to persistent volumes (survive Pod restarts). Understanding PersistentVolumes, PersistentVolumeClaims, StorageClasses, and StatefulSets is essential for stateful workloads.
Lesson outline
emptyDir: Ephemeral storage created when a Pod starts, deleted when the Pod is removed. Shared across containers in a Pod. Useful for temporary caches or sidecar communication.
hostPath: Mounts a file or directory from the host node. Pod can read/write the host filesystem. Dangerous: breaks portability and can expose secrets. Avoid in production.
configMap/secret: Mount configuration files or secrets as files. Read-only by default. Changes to the ConfigMap/Secret are propagated to the mount (with kubelet sync delay).
PersistentVolume (PV): Cluster-wide storage resource managed separately from Pods. Created by cluster admin. Examples: NFS, iSCSI, AWS EBS, Azure Disk, GCP Persistent Disk.
PersistentVolume (PV): A cluster resource representing actual storage (e.g., an NFS share or EBS volume). Created and managed by cluster admin or a storage provisioner.
PersistentVolumeClaim (PVC): A request for storage. Users create PVCs with size and access mode requirements. The controller binds the PVC to a matching PV.
Binding: One PVC binds to one PV. The PVC then gets an underlying storage medium and can be mounted by Pods.
StorageClass is a template that tells the cluster how to dynamically provision PVs when a PVC is created.
Example: StorageClass "fast" might provision AWS EBS gp3 volumes with IOPS settings. Users create a PVC referencing this StorageClass, and the provisioner automatically creates the underlying EBS volume.
Eliminates manual PV creation and simplifies capacity management.
StatefulSet is like a Deployment but for stateful workloads. Each Pod gets a stable, ordinal name (e.g., mysql-0, mysql-1, mysql-2).
Pods are created/deleted in order (0, 1, 2...). If Pod 1 crashes, it is recreated before Pod 2 (ordering guarantee).
Each Pod can have its own PVC, ensuring data persistence and recovery. Useful for databases, message queues, and key-value stores.
Access modes: ReadWriteOnce (only one node can mount), ReadOnlyMany (many nodes, read-only), ReadWriteMany (many nodes, read-write).
Reclaim policy: Retain (keep the PV after PVC deletion), Delete (delete the underlying storage), Recycle (deprecated, wipes data and reuses the PV).
Key takeaways
💡 Analogy
PV/PVC is like a real estate market. The PV is the actual land (created and managed by city planners—cluster admin). The PVC is a person asking to rent land (user request). StorageClass is like a zoning regulation: "residential zones provision 5-bedroom homes automatically." StatefulSet is like assigning apartment numbers to residents: each resident (Pod) keeps their number and apartment (storage) even if they move out and back in.
⚡ Core Idea
PersistentVolumes decouple storage from Pods. PersistentVolumeClaims request storage abstractly. StorageClasses automate provisioning. StatefulSets provide ordered, named Pods with stable storage.
🎯 Why It Matters
Stateful workloads (databases, queues) need reliable storage that survives Pod restarts. Kubernetes separates storage infrastructure from containerized applications, enabling flexible deployment across clusters and cloud providers.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.