KodeKloud Notes

In Kubernetes, storage resources are decoupled from pods using Persistent Volumes (PV) and Persistent Volume Claims (PVC).

A PersistentVolume (PV) is a cluster-level resource representing a piece of storage provisioned by an administrator.
A PersistentVolumeClaim (PVC) is a user’s request for storage, specifying capacity, access modes, and optional selectors.

When a PVC is created, Kubernetes matches it to an available PV that meets its requirements and then binds them.

The image illustrates the concept of Persistent Volume Claims (PVC) and Persistent Volumes (PV) in Kubernetes, showing a mapping between PVCs and PVs with different colors.

How PV-PVC Binding Works

The binding process evaluates several criteria to find a suitable PV for a PVC:

Capacity: PV storage ≥ PVC request
Access Modes: e.g., ReadWriteOnce, ReadOnlyMany
Volume Mode: e.g., Filesystem or Block
Storage Class: must match if specified
Label Selectors (optional): target specific volumes

Using Label Selectors

You can refine binding with labels on both PVC and PV:

# pvc-selector.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  selector:
    matchLabels:
      name: my-pv
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

# pv-with-label.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol1
  labels:
    name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

The image illustrates the concept of "Binding" in Kubernetes, showing various colored blocks labeled "PV" and "PVC" with icons representing storage. It also highlights key factors like "Sufficient Capacity," "Access Modes," "Volume Modes," and "Storage Class."

Note

A PVC binds to only one PV and vice versa. If a PV is larger than the requested size, the leftover space remains unused and cannot be shared.

The image illustrates the concept of binding in Kubernetes, showing the relationship between Persistent Volumes (PV) and Persistent Volume Claims (PVC), with conditions like "Pending" and criteria such as "Sufficient Capacity" and "Access Modes."

Step-by-Step: Creating a PersistentVolumeClaim

Define the PVC
Save the following manifest as pvc-definition.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

Apply the PVC
```
kubectl apply -f pvc-definition.yaml
```

Verify Status

kubectl get pvc myclaim

NAME      STATUS    VOLUME   CAPACITY   ACCESS MODES
myclaim   Pending

Once a matching PV is available, the PVC transitions to Bound:

kubectl get pvc myclaim

NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES
myclaim   Bound    pv-vol1   1Gi        RWO

Note

If your cluster supports dynamic provisioning, you can skip creating a PV manually. Just specify a storageClassName in the PVC.

Reclaim Policies

When a PVC is deleted, the PV’s reclaim policy determines what happens to the underlying storage:

Reclaim Policy	Behavior	Use Case
Retain (default)	PV and data are kept intact	Manual cleanup or data recovery
Delete	PV and its data are deleted automatically	Ephemeral workloads or test environments
Recycle	Data is scrubbed (basic `rm -rf /thevolume/*`) and made available	Shared test space (deprecated in v1.22)

To set a reclaim policy, include it in the PV spec:

spec:
  persistentVolumeReclaimPolicy: Delete

Cleaning Up

Remove the PVC when you no longer need it:

kubectl delete pvc myclaim

Depending on the reclaim policy, the PV will either be deleted, retained, or recycled.

Links and References

Watch Video

Watch video content