Manage persistent volumes and persistent volume claims
5 minutes
5 Questions
In the context of the Certified Kubernetes Administrator (CKA) exam, managing storage revolves around decoupling the physical storage infrastructure from the applications that consume it. This is achieved through two primary API objects: Persistent Volumes (PV) and Persistent Volume Claims (PVC).
…In the context of the Certified Kubernetes Administrator (CKA) exam, managing storage revolves around decoupling the physical storage infrastructure from the applications that consume it. This is achieved through two primary API objects: Persistent Volumes (PV) and Persistent Volume Claims (PVC).
A Persistent Volume (PV) is a cluster-resource representing a piece of storage in the cluster. It is provisioned either statically by an administrator or dynamically using a StorageClass. A PV exists independently of any Pod lifecycle and captures the details of the implementation, such as NFS, iSCSI, or cloud-specific storage systems (e.g., AWS EBS). Key configuration parameters include capacity, access modes (ReadWriteOnce, ReadWriteMany, ReadOnlyMany), and the Reclaim Policy (Retain, Recycle, Delete), which determines what happens to the volume when the claim is released.
A Persistent Volume Claim (PVC) is a request for storage by a user or developer. Similar to how a Pod consumes node resources like CPU and memory, a PVC consumes PV resources. The PVC specifies the desired capacity, access modes, and optionally a StorageClass.
The interaction between them is called 'binding'. The Kubernetes control plane watches for new PVCs and looks for a matching PV. If a PV satisfies the PVC's requirements (size and access mode), they are bound together one-to-one. If no static PV matches, dynamic provisioning can create one automatically if a StorageClass is defined. Finally, Pods access this storage by referencing the PVC in their `volumes` section, mounting it into the container's file system. For the exam, you must be proficient in writing these YAML manifests and troubleshooting binding failures, often caused by mismatched access modes or capacity.
Managing Persistent Volumes (PV) and Persistent Volume Claims (PVC)
Why is it important? In Kubernetes, Containers are ephemeral by design. When a container crashes or is restarted, the data stored inside its filesystem is lost. For stateful applications (like databases or logging systems) to retain data beyond the lifecycle of a pod, Kubernetes uses a storage abstraction layer. This system decouples the request for storage (PVC) from the actual provisioning of storage (PV), allowing developers to request storage without knowing the details of the underlying infrastructure.
What is it? There are two main resources involved: 1. Persistent Volume (PV): This is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioning using Storage Classes. It is a cluster-level resource (non-namespaced) representing the actual physical storage (e.g., NFS, AWS EBS, HostPath). 2. Persistent Volume Claim (PVC): This is a request for storage by a user. It is a namespaced resource. A PVC consumes PV resources much like a Pod consumes Node resources. PVCs request specific size and access modes.
How it works: The lifecycle involves four stages: 1. Provisioning: A PV is created (statically by admin or dynamically via StorageClass). 2. Binding: A user creates a PVC. The Kubernetes control plane loops to find a PV that matches the PVC's requirements (Capacity, Access Mode, Storage Class). If a match is found, the PV and PVC get bound together exclusively (1-to-1 mapping). 3. Using: A Pod is created that references the PVC in its volumes section. The cluster mounts the bound PV to the container. 4. Reclaiming: When the user is done with the volume, they delete the PVC. The persistentVolumeReclaimPolicy of the PV determines what happens to the data (Retain, Delete, or Recycle).
How to answer questions regarding Managing PVs and PVCs in an exam? In the CKA exam, you will typically be asked to create a persistent storage solution for a Pod. Follow these steps:
1. Create the PV: If the exam provides a specific backend (like hostPath), create the PV YAML. Define the capacity, accessModes, and storageClassName explicitly. 2. Create the PVC: Create a claim that matches the PV's criteria. Ensure the requested storage is less than or equal to the PV size, and the access modes match. 3. Mount to Pod: Edit or create the Pod YAML. Under spec.volumes, add the persistent volume claim by name. Under spec.containers.volumeMounts, specify the path inside the container where the data should exist.
Exam Tips: Answering Questions on Manage persistent volumes and persistent volume claims 1. Capacity Matching: A PVC will stick in the Pending state if no PV has enough capacity to satisfy it. A 5Gi PVC cannot bind to a 2Gi PV. 2. Access Modes matter: Memorize the abbreviations. RWO (ReadWriteOnce), ROX (ReadOnlyMany), RWX (ReadWriteMany). The PVC must request an access mode supported by the PV. 3. Storage Class Name: This is the most common reason for binding failures in the exam. If a PV has storageClassName: manual, the PVC must request storageClassName: manual. If the PV has storageClassName: "" (empty string), the PVC must also have it set to an empty string to bind. 4. Troubleshooting: If a Pod is stuck in ContainerCreating, describe the pod (kubectl describe pod <name>). It often indicates the PVC is not found or not bound. Check the PVC status with kubectl get pvc and kubectl get pv. 5. Reclaim Policy: Be careful if asked to ensure data survives PVC deletion. You may need to edit the PV to set persistentVolumeReclaimPolicy: Retain.