When you need storage that survives Pod restarts, rescheduling, and even deletion — you need PersistentVolumes. The PV/PVC system decouples storage provisioning (admin concern) from storage consumption (developer concern), just like Nodes decouple compute provisioning from Pod scheduling.

1. The PV/PVC Model

How Binding Works

1. Developer creates a PVC with requirements (size, access mode, StorageClass)
2. The PV controller finds a matching PV (or dynamic provisioner creates one)
3. PVC and PV are bound (1:1 relationship — a PV can only bind to one PVC)
4. Pod references the PVC by name in its volume spec
5. kubelet mounts the underlying storage into the Pod

2. PersistentVolume Spec

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-ebs-01                  # Cluster-scoped (no namespace)
spec:
  capacity:
    storage: 50Gi                  # Size of the volume
  accessModes:
    - ReadWriteOnce                # How many nodes can mount it
  persistentVolumeReclaimPolicy: Retain   # What happens when released
  storageClassName: gp3            # Links to a StorageClass (for binding)
  csi:                             # Backend-specific (CSI driver)
    driver: ebs.csi.aws.com
    volumeHandle: vol-0abc123def456
    fsType: ext4
  nodeAffinity:                    # Which nodes can access this volume
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: topology.kubernetes.io/zone
              operator: In
              values: [us-east-1a]

Access Modes

Reclaim Policies

3. PersistentVolumeClaim Spec

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3             # Must match PV's storageClassName
  resources:
    requests:
      storage: 50Gi                 # Minimum size needed

Binding Rules

A PVC binds to a PV when all these match:

1. StorageClass — PVC's storageClassName matches PV's (or both empty)
2. Access mode — PV supports at least the modes requested
3. Capacity — PV's capacity ≥ PVC's request
4. Selector — if PVC has a selector, PV must match its labels

# PVC with label selector (static provisioning):
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      environment: production
      tier: database

Using a PVC in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: postgres
spec:
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: db-data          # Reference the PVC by name
  containers:
    - name: postgres
      image: postgres:16
      volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data

4. PV/PVC Lifecycle

The "Released" Problem

When a PVC is deleted and the PV has Retain, the PV enters Released state. It still contains data but cannot be bound to a new PVC automatically. To reuse it:

# Option 1: Remove the claimRef to make it Available again:
kubectl patch pv pv-ebs-01 -p '{"spec":{"claimRef": null}}'
# Now it can bind to a new PVC

# Option 2: Create a PVC that matches exactly (same name, same spec)
# This is how you recover a StatefulSet's data after accidental PVC deletion

5. Static vs Dynamic Provisioning

# Static: Admin creates PV pointing to existing EBS volume
# Dynamic: Developer creates PVC with StorageClass → provisioner creates EBS + PV

# Dynamic provisioning is the norm in production.
# StorageClasses (next lesson) enable it.

6. Volume Expansion (Resize)

# PVC can be expanded (if StorageClass allows it):
kubectl edit pvc db-data
# Change: resources.requests.storage: 50Gi → 100Gi

# Or patch:
kubectl patch pvc db-data -p '{"spec":{"resources":{"requests":{"storage":"100Gi"}}}}'

Requirements for Expansion

• StorageClass must have allowVolumeExpansion: true
• Only growing is supported — you cannot shrink a PVC
• For file-system based volumes: the Pod may need to restart for the filesystem to resize (depends on CSI driver — many support online expansion)

# Check if expansion is supported:
kubectl get sc gp3 -o yaml | grep allowVolumeExpansion
# allowVolumeExpansion: true

# After patching, check PVC conditions:
kubectl get pvc db-data -o yaml | grep -A5 conditions
# - type: FileSystemResizePending
#   status: "True"
# → Pod restart needed to resize filesystem
# (or it happens online if the CSI driver supports it)

Summary