Persistent Volumes

Learn Persistent Volumes as cluster storage resources for durable data, lifecycle, reclaim policies, and storage backend abstraction.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A PersistentVolume is cluster storage made available to workloads. It represents real storage such as cloud disks, NFS, or CSI-backed volumes.

🔍 What Is It?

A PersistentVolume is a cluster-scoped storage resource.

It abstracts physical or cloud-backed storage so workloads can claim durable capacity without knowing every backend detail.

🎯 Why Do We Need It?

Some workloads need data that survives Pod restarts, rescheduling, or replacement.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A logging platform may use PersistentVolumes backed by cloud block disks. Platform teams define storage classes and reclaim policies, while app teams request storage through PVCs.

⚙️ How It Works

A PV has capacity, access modes, volume mode, reclaim policy, storage class, and backend details. A PVC binds to a suitable PV, either pre-provisioned or dynamically created by a CSI driver.

💻 Example

PersistentVolume concept — A static PV example for shared storage.

yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-data-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-retain
  nfs:
    server: nfs.company.local
    path: /exports/shared-data

🤔 Common Confusions

❓ Is a PV namespaced?

No. PersistentVolumes are cluster-scoped.

❓ Do Pods usually use PVs directly?

No. Pods normally use PVCs, which bind to PVs.

❓ Does persistent storage make a stateful app easy?

No. Backups, consistency, failover, and operational procedures still matter.

🚨 Common Production Issues

**Wrong reclaim policy** deletes or retains data unexpectedly.

**Backend access mode mismatch** prevents Pods from mounting storage.

**No backup strategy** leaves durable data vulnerable.

**Zonal volumes** block rescheduling across zones.

✅ Best Practices

Use dynamic provisioning through StorageClasses where possible

Choose reclaim policy deliberately

Document access modes and topology limits

Back up important persistent data

Prefer managed databases for critical data where suitable

🏛️ Architect's Note

Senior Architect's Perspective

PersistentVolumes solve attachment, not data architecture. Stateful systems still need backup, restore, replication, and operational ownership.

💬 Frequently Asked Questions

Interview: How would you explain Persistent Volumes in a real Kubernetes project?

Persistent Volumes should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Persistent Volumes?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1PVs are cluster-scoped storage resources
2PVCs bind workloads to PVs
3Reclaim policy and access modes are critical
4Durability needs backup and recovery planning

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages