Kubernetes Storage: PV vs PVC (and How Binding Works)

Pods are ephemeral — when one is rescheduled, anything written to its container filesystem is gone. To keep data, Kubernetes separates the storage that exists from the request for storage: the PersistentVolume (PV) and the PersistentVolumeClaim (PVC). This guide explains both, how they bind, static vs dynamic provisioning, and the access modes and reclaim policies you'll be asked about.

---

The one-line mental model

• PV = supply. An actual piece of storage in the cluster (an EBS/Azure Disk/NFS export), cluster-scoped, created by an admin or provisioned dynamically.
• PVC = demand. A namespaced request for storage (size, access mode, class) made by a user or app.
• Kubernetes = the matchmaker. It binds a PVC to a suitable PV. Pods mount the PVC, never the PV directly.

Analogy: the PV is a house on the market, the PVC is a request for a house, Kubernetes is the agent that matches them, and the Pod is the person who moves in.

---

Prerequisites

---

Part 1 — The two objects side by side

---

Part 2 — Dynamic provisioning (the common path)

On a cloud cluster you usually don't create PVs by hand. You create a PVC, and a StorageClass provisions the PV automatically.

# pvc.yaml — a request; the StorageClass creates the PV on demand
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard    # omit to use the cluster default
  resources:
    requests:
      storage: 5Gi

kubectl apply -f pvc.yaml
kubectl get pvc demo-pvc          # STATUS should move to Bound
kubectl get pv                    # a PV was auto-created and bound to the claim

The claim starts Pending, the provisioner creates the disk + PV, and the two become Bound.

---

Part 3 — A pod uses the claim

The pod references the PVC in volumes and mounts it — it never names the PV:

apiVersion: v1
kind: Pod
metadata:
  name: storage-pod
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: app-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: app-storage
      persistentVolumeClaim:
        claimName: demo-pvc

Data written under /usr/share/nginx/html now lives on the PV and survives pod restarts and rescheduling.

---

Part 4 — Static provisioning (pre-created PVs)

For pre-existing storage (an NFS export, a specific disk), an admin creates the PV first; PVCs then bind to whatever matches.

# pv.yaml — admin-created storage
apiVersion: v1
kind: PersistentVolume
metadata:
  name: demo-pv
spec:
  capacity:
    storage: 10Gi
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:                       # demo only; use NFS/EBS/etc. in production
    path: /mnt/data

A PVC with a matching storageClassName, size ≤ capacity, and compatible access mode will bind to it.

Static vs dynamic: static = you pre-create a fixed pool of PVs (good for existing hardware/NFS); dynamic = a StorageClass creates storage on demand (the cloud default, far less toil).

---

Part 5 — Access modes and reclaim policy (know these cold)

Access modes — what can mount the volume, and how:

The backend decides what's possible: block storage is usually RWO; you need a shared filesystem (NFS/EFS/Azure Files) for RWX.

Reclaim policy — what happens to the storage when the PVC is deleted (persistentVolumeReclaimPolicy):

• Retain — keep the data; the admin cleans up manually. Safe for databases and anything critical.
• Delete — delete the underlying storage too. Convenient, but destroys data — the default for many dynamic StorageClasses, so double-check it for stateful workloads.
• Recycle — legacy/deprecated; don't rely on it.

---

Common mistakes to avoid

• Mounting the PV in a pod. Pods mount the PVC; that's the whole point of the indirection.
• Assuming RWX everywhere. Block storage (EBS/Azure Disk) is RWO — many pods on many nodes can't write to it. Use a shared filesystem for RWX.
• Ignoring the reclaim policy. A Delete policy on a database PVC will wipe the disk when the claim is removed. Use Retain for stateful/critical data.
• PVC stuck Pending. No matching PV (static) or no/instant StorageClass (dynamic), or an access-mode/size mismatch — check kubectl describe pvc.
• Expecting emptyDir to persist. emptyDir dies with the pod; only PVCs survive rescheduling.

---

Practice: try it yourself

1. Dynamic bind. Apply the PVC from Part 2, watch it go Pending → Bound, and confirm a PV was auto-created (kubectl get pv).
2. Prove persistence. Mount it in the Part 3 pod, write a file, delete the pod, recreate it, and confirm the file is still there.
3. Inspect a stuck claim. Request ReadWriteMany on a block-storage class and read the kubectl describe pvc event to see why it won't bind.
4. Reclaim policy. Check your default StorageClass's reclaim policy (kubectl get storageclass -o yaml) — is it Delete or Retain?

Self-check:

• Who creates a PV vs a PVC, and what scope is each?
• Which object does a pod actually reference?
• Which access mode do you need for two pods on two nodes to both write?
• What does a Delete reclaim policy do when you remove the PVC?
• When would you use static instead of dynamic provisioning?

---

Where to go next

• Practice with the Kubernetes interview questions — several cover PV/PVC, StatefulSets, and storage.
• Related traps: Memory: MB vs MiB and Server-Side Apply.
• Stateful workloads build on this — StatefulSets give each pod its own PVC via volumeClaimTemplates.
• Start from the basics with Kubernetes: Getting Started.

The takeaway: PV supplies storage, PVC requests it, Kubernetes binds them, and pods mount the claim — separating the two is what lets storage outlive ephemeral pods.