Persistent Volumes and Claims: Managing Kubernetes Storage

Previously in this course, we explored Persistent Storage Basics: Using Volumes in Kubernetes, where we touched on ephemeral storage and basic hostPath volumes. While those work for local testing, they are tied to specific nodes and lack the flexibility required for production environments.

In this lesson, we introduce the PersistentVolume (PV) and PersistentVolumeClaim (PVC) pattern. This abstraction layer is the industry standard for managing storage in Kubernetes, allowing developers to request resources without needing to know the underlying infrastructure details—be it AWS EBS, Google Persistent Disk, or an NFS server.

Understanding the PV and PVC Abstraction

In Kubernetes, managing storage is a two-way street:

1. PersistentVolume (PV): A piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster, just like a Node. It exists independently of any individual Pod.
2. PersistentVolumeClaim (PVC): A request for storage by a user. It is similar to a Pod; just as Pods consume node resources (CPU/RAM), PVCs consume PV resources.

This Abstraction allows for a clean separation of concerns. An infrastructure engineer manages the PVs (the "supply"), while a developer creates a PVC (the "demand") to attach storage to their application.

The Lifecycle of Storage

When a developer creates a PVC, Kubernetes searches for a PV that matches the request (size, access mode, etc.). Once a match is found, the PV is "bound" to the PVC. If no PV is available, the PVC stays in a Pending state until a matching volume is created.

Worked Example: Creating a PV and PVC

Let's create a static volume. For this example, we'll define a simple local volume.

Step 1: Create the PersistentVolume

Save this as pv.yaml. This acts as our storage pool.

YAML
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

Apply it with kubectl apply -f pv.yaml. You've now defined the resource.

Step 2: Create the PersistentVolumeClaim

Now, the application developer creates a request. Save this as pvc.yaml.

YAML
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Apply it with kubectl apply -f pvc.yaml.

Check the status with kubectl get pvc. You should see my-pvc in the Bound state, linked to my-pv.

Hands-on Exercise

1. Inspect: Run kubectl get pv and kubectl get pvc. Observe the status and the CAPACITY field.
2. Modify: Change the storage request in your pvc.yaml to 2Gi. Apply it. Notice that the PVC remains in Pending because the PV only provides 1Gi and cannot satisfy the request.
3. Delete: Delete the PVC (kubectl delete pvc my-pvc). Check the status of the PV. Because we set the persistentVolumeReclaimPolicy to Retain, the PV is not deleted; it remains in a Released state, preserving your data.

Common Pitfalls

• Size Mismatch: If your PVC requests more storage than the PV offers, they will never bind.
• Access Mode Conflicts: If your PV is configured as ReadOnlyMany but your Pod attempts to write to it, you will encounter permission errors. Always match the access mode to your application's needs.
• Namespace Scoping: Remember that PVCs are namespaced, while PVs are cluster-wide. You can only use a PVC from the same namespace where it was created.
• Reclaim Policy: Using Delete as a reclaim policy will automatically remove the underlying storage when the PVC is deleted. Be cautious in production; Retain is often safer for critical data.

FAQ

Q: Do I need to manually create a PV every time? A: Not necessarily. In most cloud environments, we use StorageClasses to perform "Dynamic Provisioning," which creates the PV automatically when a PVC is requested. We will cover this in the next lesson.

Q: Can multiple Pods share a PVC? A: Yes, if the access mode is ReadOnlyMany or ReadWriteMany. However, for standard block storage (like most cloud disks), only one Pod can use a ReadWriteOnce volume at a time.

Recap

We have successfully decoupled storage from infrastructure by using the PV/PVC pattern. You’ve learned that the PV represents the physical storage, the PVC represents the claim for that storage, and how to verify their binding status. This abstraction is essential for building portable, resilient applications that can survive Pod restarts and rescheduling.

Up next: Dynamic Provisioning — we will learn how to automate storage creation using StorageClasses so you don't have to manually provision PVs ever again.