CKA Day 29: Kubernetes Volume Simplified — Persistent Volume, Persistent Volume Claim & Storage Class

Day 29/40 — Kubernetes Volume Simplified: Persistent Volume, Persistent Volume Claim & Storage Class

Overview

Day 29 of the 40-day CKA course dives into Kubernetes storage after the Docker storage prerequisite covered in Day 28. The video explains how Kubernetes manages ephemeral and persistent data through a layered abstraction: emptyDir for temporary Pod-scoped scratch space, hostPath for node-local mounts, and the PersistentVolume / PersistentVolumeClaim / StorageClass triad for true cluster-wide persistence.

Key Concepts

EmptyDir: Pod-Scoped Ephemeral Storage

An emptyDir volume is created when a Pod is assigned to a node and exists as long as the Pod lives there. It survives container restarts (because the Pod is still running) but is permanently deleted when the Pod itself is removed. The Day 29 demo spins up a Redis Pod with an emptyDir mounted at /data/redis, writes a file, kills the Redis process to force a container restart, and confirms the file persists. Deleting and recreating the Pod removes the data entirely.

hostPath: Node-Local Directories

hostPath mounts a directory from the host node’s filesystem into a container. It is the Kubernetes equivalent of a Docker bind mount. The video explicitly warns that hostPath is not recommended for multi-node clusters because other nodes will not have the same host directory. The demo uses nodeName: master to pin the Pod to the control plane node where the host path exists — a single-node hack that illustrates the concept but should not be used in production.

PersistentVolume (PV): Cluster-Scoped Storage Pool

A PersistentVolume is a cluster-level resource that represents a piece of provisioned storage (NFS, iSCSI, cloud block disk, or even a local host path for testing). The storage administrator provisions the PV with a fixed capacity, access modes, and reclaim policy. Once a PVC binds to a PV, that capacity is consumed and subtracted from the available pool.

PersistentVolumeClaim (PVC): Namespace-Scoped Request

A PVC is a user-level request for storage. The user specifies how much capacity they need, the required access mode, and optionally a StorageClass. Kubernetes matches the PVC against available PVs. If no PV satisfies the request (insufficient capacity or mismatched access mode), the PVC remains in Pending and the dependent Pod cannot schedule.

Access Modes

The video catalogs four access modes that define how a volume can be mounted:

• ReadWriteOnce (RWO) — mounted read-write by a single node
• ReadOnlyMany (ROX) — mounted read-only by multiple nodes
• ReadWriteMany (RWX) — mounted read-write by multiple nodes
• ReadWriteOncePod (RWXOPOD) — mounted read-write by a single Pod

Binding requires an exact match between the PVC’s requested access mode and one of the PV’s declared modes. A mismatch is a common cause of stuck Pending claims.

Reclaim Policies

Reclaim policies define what happens to a PV after its bound PVC is deleted:

• Retain — the PV and its data survive, but the PV enters a Released state and cannot be re-claimed by a new PVC without manual intervention.
• Delete — the PV and its underlying storage asset are destroyed automatically.
• Recycle — the PV is scrubbed and returned to the Available pool. This is deprecated in favor of dynamic provisioning.

StorageClasses and Dynamic Provisioning

A StorageClass links Kubernetes to an external storage provider via a provisioner (e.g., kubernetes.io/aws-ebs, kubernetes.io/gce-pd, kubernetes.io/azure-file, NFS, Portworx). With dynamic provisioning, users only create a PVC that names a StorageClass; the provisioner automatically creates the PV and the backing cloud disk. If no StorageClass is specified, the cluster’s default StorageClass is used. Static provisioning (admin manually creates PVs) is the older pattern still relevant for on-premise or pre-allocated storage.

Practical Workflow

1. Admin provisions a PV (or defines a StorageClass for dynamic provisioning).
2. User creates a PVC requesting a slice of storage with matching access modes.
3. Kubernetes binds the PVC to a suitable PV.
4. User creates a Pod that mounts the PVC via volumeMounts and volumes.
5. Data written by the application persists beyond Pod restarts, reschedules, and even node failures (when cloud-backed).

Course Context

This video is part of the 40DaysOfKubernetes challenge led by Tech Tutorials with Piyush, aligned with the CKA 2024 curriculum and using Kubernetes 1.30.2. Hands-on tasks and YAML manifests are available in the course GitHub repository.

See Also

Wiki Concepts

• Kubernetes Storage — deep-dive on PVs, PVCs, StorageClasses, access modes, and reclaim policies
• Docker Storage — prerequisite covering layered architecture, named volumes, bind mounts, and the K8s storage bridge
• Pod Fundamentals — volumeMounts, emptyDir, and the Pod lifecycle
• Kubernetes Manual Scheduling — nodeName used in the hostPath demo to pin Pods to a specific node
• Kubernetes Taints and Tolerations — why the demo Pod could land on a control-plane node
• Kubernetes Namespaces — PVCs are namespace-scoped; PVs are cluster-scoped
• Kubernetes ConfigMaps and Secrets — another category of volume-mounted cluster data
• Kubernetes Architecture — kube-controller-manager and the PV controller
• CKA Certification — exam structure and the ~10% Storage domain
• CKA Study Roadmap — Day 29 in the 40-day learning plan

Related Sources

• CKA Day 28: Docker Volume Explained — Docker Bind Mount & Docker Persistent Storage — prerequisite for this video

Creator / Entity

• Tech Tutorials with Piyush — course creator and Kubernetes educator