Kubernetes Storage PV PVC StorageClass for Exam Preparation

Mastering persistent storage is a critical skill for any Kubernetes professional and a heavily tested area on exams like the CKA and CKAD. You cannot run stateful applications like databases or message queues without a solid grasp of how Kubernetes abstracts physical storage. Core concepts include PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass, with a focus on the static and dynamic provisioning patterns, configuration details, and troubleshooting scenarios you are guaranteed to encounter on certification exams.

Core Concepts: PV, PVC, and the Binding Dance

At the heart of Kubernetes storage are three primary resources. A PersistentVolume (PV) is a cluster resource representing a piece of networked storage that has been provisioned by an administrator or dynamically by a storage class. Think of it as an abstracted "storage shelf" in the cluster. A PersistentVolumeClaim (PVC) is a user's request for storage. It is a declaration of need—specifying size, access mode, and sometimes a specific storage class—that pods use to get access to persistent storage.

The binding process is fundamental. When you create a PVC, the Kubernetes control plane searches for a PV that matches its requirements (size, access modes, storage class, selector labels). If a suitable PV is found, they are bound together in a one-to-one, exclusive relationship. Until a PV is bound, it is available; once bound, it is claimed. A PVC remains unbound if no matching PV exists, which will cause pods using it to remain in a pending state—a classic exam troubleshooting scenario.

Access Modes define how a volume can be mounted. You must know these for the exam:

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
• ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes.
• ReadWriteOncePod (RWOP): A newer mode (Kubernetes v1.22+) where the volume can be mounted by a single pod. This is crucial for ensuring strict single-writer access in secure environments.

Provisioning Models: Static vs. Dynamic

There are two primary ways to make storage available to your pods: static and dynamic provisioning. In static provisioning, a cluster administrator manually creates a set of PV objects representing actual storage assets in the backend. These PVs sit in a pool, waiting for user PVCs to claim them. This model gives administrators maximum control but does not scale efficiently.

Dynamic provisioning is the modern, scalable default. It relies on StorageClass resources. A StorageClass defines a "class" or "tier" of storage (e.g., fast-ssd, slow-hdd) and contains the parameters and provisioner needed to dynamically create a PV when a PVC requests it. When a PVC specifies a storageClassName, it triggers this dynamic workflow: the PVC is created, the appropriate StorageClass controller sees it, and automatically provisions a new PV that precisely matches the claim. This eliminates the need for pre-provisioned PVs.

A key exam concept is the storageClassName field. A PVC can request a specific class. A PV can have a class label to belong to a specific class. If a PVC sets storageClassName: "", it explicitly requests a PV with no storage class (i.e., a statically provisioned one). If the field is omitted entirely, the cluster's default StorageClass is used, if one is defined.

Volume Types, Reclaim Policies, and StatefulSets

Kubernetes supports numerous volume types, from simple local testing to complex cloud integrations. For exams, focus on these common ones:

• hostPath: Mounts a file or directory from the host node's filesystem into the pod. Useful for single-node development/testing but not for production (tied to a specific node, security risks).
• nfs: Mounts an existing NFS share into the pod. A common example of pre-existing storage integrated into Kubernetes.
• csi: The Container Storage Interface is the standard plugin interface for exposing arbitrary storage systems. Cloud provider volumes (like aws-ebs, gce-pd, azure-disk) are typically implemented via CSI drivers.

The Reclaim Policy of a PV (persistentVolumeReclaimPolicy) determines what happens to the underlying storage resource after the PVC that was using it is deleted. The policies are:

• Retain: The default for manually created PVs. The PV becomes Released but the storage asset and its data are kept manually for manual reclamation.
• Delete: Commonly used with dynamically provisioned volumes. The associated storage asset in the external infrastructure (e.g., the AWS EBS volume) is deleted.
• Recycle (Deprecated): A basic rm -rf /volume/* scrub. Do not use; know that it's deprecated.

For stateful applications, you use a StatefulSet. StatefulSets provide stable, unique network identifiers and persistent storage. Each pod in a StatefulSet gets its own, uniquely named PVC template, leading to pod-name-volumeclaimtemplate-name-<ordinal> naming. This ensures that if a pod is rescheduled, it can reattach to its specific, pre-existing persistent volume, maintaining data identity—essential for databases.

Advanced Operations: Expansion, Snapshots, and Troubleshooting

The Kubernetes storage ecosystem supports advanced operations you should be aware of:

• Expanding PVCs: You can resize a PVC if the underlying StorageClass supports it (allowVolumeExpansion: true). You edit the PVC's spec.resources.requests.storage field to a larger value. The PV object updates automatically, but you often need to perform a file system expansion inside the pod (e.g., using resize2fs or xfs_growfs).
• Volume Snapshots: Using the VolumeSnapshot API (via CSI drivers), you can create point-in-time snapshots of a volume, which can then be used to provision a new PVC.

For exam troubleshooting, be methodical:

1. Pod Pending: Check if the PVC is bound (kubectl get pvc). An unbound PVC usually means no matching PV (static) or a misconfigured StorageClass/provisioner (dynamic).
2. Mount Errors: Describe the pod (kubectl describe pod <pod-name>). Look for events indicating "failed mount." This often points to incorrect access modes (e.g., a ReadWriteOnce volume being requested by pods on different nodes) or problems with the underlying storage system (NFS server down, invalid credentials).
3. Permission Issues: Files in a mounted volume may have wrong ownership. Use an initContainer to run chown or chmod on the mount path before the main app container starts.

Common Pitfalls

1. Confusing Access Modes with Reclaim Policies: A classic exam trap. Remember, access modes (RWO, RWX) govern how pods can use the volume now. Reclaim policies (Retain, Delete) govern what happens to the storage after the PVC is gone. Mixing these up will lead to wrong answers.
2. Using hostPath for Multi-Node Scenarios: If an exam question involves a multi-node cluster or data persistence across pod restarts, hostPath is almost always the wrong answer because it is tied to a specific node's filesystem. Look for nfs, csi, or cloud provider volumes instead.
3. Ignoring the Default StorageClass: When a PVC manifest omits the storageClassName field, the cluster's default StorageClass is used. If no default exists and no static PV matches, the PVC will remain pending. You must know how to check (kubectl get storageclass) and set a default StorageClass.
4. Forgetting File System Expansion Inside the Pod: Successfully editing a PVC to request more storage only expands the underlying block device. The file system inside the pod's mounted volume remains the old size. You must typically execute a file system expansion command inside the running pod to utilize the new space—a common two-step process tested in scenarios.

Summary

• PVs are cluster storage resources, PVCs are requests for storage. Binding matches a PVC to a suitable PV based on criteria like size, access mode, and storage class.
• Dynamic provisioning via StorageClass is the scalable, modern standard, automating PV creation. Know the difference between static (manual PVs) and dynamic (PVC-triggered) models.
• Critical configuration details are Access Modes (RWO, RWX, ROX, RWOP) and Reclaim Policies (Retain, Delete). Misunderstanding these is a frequent source of exam errors.
• Use StatefulSets with volumeClaimTemplates for stateful applications to provide stable, unique persistent storage for each pod replica.
• Troubleshoot storage by checking PVC binding status first, then pod events for mount errors. Common issues include unbound PVCs, access mode conflicts, and node-specific volume types like hostPath in multi-node clusters.