What's the difference between a PersistentVolume and a PersistentVolumeClaim?

The separation of concerns: PV (supply) vs. PVC (demand)

# PersistentVolume: an actual piece of storage, typically created by an admin
# or dynamically by a StorageClass provisioner -- represents SUPPLY
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-database-1
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: vol-0abc123

# PersistentVolumeClaim: a request for storage, created by an application
# developer -- represents DEMAND, with no knowledge of the underlying implementation
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

# The Pod only references the PVC by name -- never the PV directly
spec:
  containers:
    - name: db
      volumeMounts:
        - name: data
          mountPath: /var/lib/data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: database-pvc

Kubernetes's PV controller binds the PVC to a PV that satisfies its requested size and access mode (in this example, pv-database-1 matches database-pvc's request exactly) — once bound, that specific PV is reserved exclusively for that PVC and can't be claimed by any other PVC.

Why this indirection is genuinely useful

An application developer writing a Deployment or StatefulSet manifest shouldn't need to know (or care) whether the underlying storage is an AWS EBS volume, a GCP persistent disk, or an on-prem NFS share — they just declare "I need 20Gi, ReadWriteOnce" via a PVC, and the actual storage implementation detail is handled entirely by whoever manages PVs (or, far more commonly today, by dynamic provisioning via a StorageClass — see that question). This mirrors the same "declare what you want, let something else figure out how" philosophy that runs through Kubernetes generally (see the reconciliation-loop question).

Static vs. dynamic provisioning

• Static provisioning: a cluster administrator manually creates PV objects ahead of time, representing real storage they've already set up, and PVCs bind to whichever pre-existing PV matches.
• Dynamic provisioning (the overwhelmingly more common approach today): a PVC references a StorageClass, and if no existing PV matches, the StorageClass's provisioner automatically creates a brand-new PV (and the underlying real storage — e.g., actually calling the cloud API to create an EBS volume) on demand, with no administrator needing to pre-provision anything.

The lifecycle and reclaim policy

When a PVC is deleted, what happens to its bound PV (and the real underlying storage) depends on the PV's reclaim policy: Delete (the PV and underlying storage are deleted too — common for dynamically-provisioned PVs) or Retain (the PV and its data survive, but move to a "released" state, no longer available to be bound automatically, requiring manual admin action to reuse or clean it up) — an important setting to check deliberately for any PV holding genuinely important data, since the default behavior for dynamically-provisioned volumes is frequently Delete, which can be a nasty surprise if a PVC is deleted accidentally.

A strong answer emphasizes the separation of concerns this design achieves — developers declare storage needs abstractly via PVCs, while the actual storage implementation (PVs, and typically dynamic provisioning via StorageClasses) is a cluster/infrastructure-level concern — rather than just describing PV and PVC as two similarly-named objects without explaining why the split exists.