Persistent Storage in Kubernetes & OpenShift: PV and PVC

— ny_wk

Containers are designed to be disposable — and that's a problem the moment you run a database. By default, anything a container writes vanishes when it restarts. For stateful apps like databases or message queues, you need storage that survives crashes and restarts. In Kubernetes and OpenShift, that's what PersistentVolumes and PersistentVolumeClaims provide.

The problem: ephemeral by default

Start a container from an immutable image and it uses ephemeral storage — data written inside is lost on stop or restart. Fine for stateless web apps; fatal for anything that must remember things.

PersistentVolume (PV): the storage resource

A PersistentVolume is a piece of storage in the cluster (backed by a cloud disk, NFS, iSCSI, etc.) that exists independently of any pod. Its lifecycle is separate from the pods that use it, so the data outlives container restarts. An admin can provision PVs manually, or a StorageClass can create them on demand.

PersistentVolumeClaim (PVC): the request

Developers don't grab PVs directly — they file a PersistentVolumeClaim describing what they need (size, access mode). Kubernetes binds the claim to a matching PV (or dynamically provisions one). The pod then mounts the PVC like a normal volume. This separation lets developers ask for "10Gi of fast storage" without knowing the underlying infrastructure.

StorageClass: dynamic provisioning

Manually pre-creating PVs doesn't scale. A StorageClass defines a "type" of storage (e.g., SSD, standard) and automatically provisions a PV whenever a PVC asks for it. This is how most clusters run today — claim it, and the volume appears.

Access modes you'll choose

• ReadWriteOnce (RWO): mounted read-write by a single node — typical for databases.
• ReadOnlyMany (ROX): read-only by many nodes.
• ReadWriteMany (RWX): read-write by many nodes — needs shared storage like NFS.

Key takeaways

• Containers lose data on restart — stateful apps need persistent storage.
• PV = the storage resource; PVC = the developer's request that binds to a PV.
• StorageClass dynamically provisions volumes on demand (the modern default).
• Pick the right access mode (RWO for most databases; RWX needs shared storage).

Frequently asked questions

What's the difference between a PV and a PVC?

A PV is the actual storage in the cluster; a PVC is a request for storage that gets bound to a PV. Developers create PVCs; PVs are provisioned by admins or a StorageClass.

Do I need to create PVs manually?

Not if you use a StorageClass — it provisions a PV automatically when a PVC is created.

Which access mode for a database?

Usually ReadWriteOnce — a single node mounts it read-write. Multi-node read-write (RWX) requires shared storage like NFS.

What happens to data when the pod dies?

It persists on the PV. A new pod re-binds the same PVC and picks up right where the old one left off.

Think "PVC = I need storage, PV = here's the storage," let a StorageClass handle the rest, and stateful workloads stop losing their memory.