PersistentVolumeClaim

Large applications rarely run on a single machine today. They run in small, isolated packages called containers, spread across many servers. Distributing and monitoring a program for this purpose is handled by software called Kubernetes. Containers, however, have an unpleasant trait: when a container is terminated, all data inside it is gone. This is exactly what the PersistentVolumeClaim, or PVC for short, is for. It is a brief request in which a program states how much durable storage space it needs and how it wants to access it. The system then searches for suitable storage and provisions it.

Why data must outlive a container

Containers are deliberately short-lived. They are started, stopped, copied, and moved to another server if a machine fails. For a program that just serves web pages, this is not a problem. For a database holding customer orders, it would be a disaster.

A PersistentVolumeClaim therefore separates the lifespan of the data from the lifespan of the container. The storage continues to exist even if the container is deleted and restarted. Upon restart, the same storage is reattached, and the data is still there, unchanged. Without this mechanism, Kubernetes could practically only run programs that don’t need to remember anything.

The second advantage is the division of labor. A developer doesn’t need to know whether the company operates hard drives in its own basement or rents storage from Amazon. They simply write: twenty gigabytes, fast, writable by one program. As a result, the same program runs unchanged on the developer’s laptop and in the large data center.

Request, offer, and the matchmaking in between

You can think of this like a housing agency. The PersistentVolumeClaim is the application: desired size, desired access mode. Its counterpart is called a PersistentVolume and is the concrete offer, i.e. an actually existing storage area. Kubernetes plays the matchmaker and brings the two together.

In practice, the matching offer usually doesn’t exist yet. This is where the so-called StorageClass comes in, a kind of catalog of storage types. It defines which provider is contacted and what quality of storage is used, such as fast SSD or cheap standard disk. When a request comes in, the matching storage is automatically created and allocated. This process is called dynamic provisioning.

The access mode matters a great deal. It is common for only one server to be allowed to write at a time, because otherwise two programs could end up scrambling the same file. Some storage systems also allow shared writing from multiple servers at once. A common misconception is also that deleting a request automatically deletes the data with it. This depends on a setting: depending on the policy, the storage is either released and wiped, or kept around as a safety measure.

Where PVCs show up in operations

Anyone running a database, a file store, or a wiki in Kubernetes cannot avoid PersistentVolumeClaims. AI systems also make heavy use of them. Training data and finished models are often hundreds of gigabytes in size and shouldn’t need to be downloaded again on every restart.

The topic usually becomes visible when something goes wrong. A classic case: a container fails to start and gets stuck in the Pending state because no suitable storage could be found. Another classic case is cloud bills that keep rising even though applications have long since been shut down — the paid-for storage simply sat around unused.

In job postings and technical articles, the term appears in the context of cloud operations and DevOps, i.e. the work of running and delivering software. It belongs to the basic vocabulary, much like container or cluster. Anyone who has understood that a PVC is only a request and not the storage itself has grasped the crucial point.