Persistent Volumes

Welcome to the NZRT Wiki Podcast. Today we’re looking at Persistent Volumes.

If you’ve worked with Kubernetes at all, you’ve probably run into the question of where your data actually lives. Containers are ephemeral by design — when one stops, its local data disappears with it. Persistent Volumes solve that problem, and that’s exactly what we’re covering today.

Let’s start with the two core concepts. A PersistentVolume, or PV, is a storage resource that exists at the cluster level. Think of it as a chunk of storage that Kubernetes knows about and can hand out. A PersistentVolumeClaim, or PVC, is how a workload actually requests that storage. Claims are scoped to a namespace, meaning they live within a specific environment in your cluster, and when you create one, Kubernetes binds it to an available PV that matches what you asked for.

Before you can claim storage, you usually need a StorageClass. This is where dynamic provisioning comes in. The first example in the wiki shows a StorageClass definition. It sets a name — in NZRT’s case that’s called nzrt-standard — and points to a provisioner, which is the component that actually goes and creates the underlying storage. The example uses a placeholder provisioner that you would swap out for your real cloud provider’s provisioner in a live deployment. Two other settings matter here: the reclaim policy is set to Retain, which we’ll come back to shortly, and the volume binding mode is set to wait for the first consumer, meaning storage isn’t actually provisioned until something tries to use it.

Next up is the PersistentVolumeClaim itself. The example shows a claim named nextcloud-pvc, sitting in the nzrt-prod namespace. It requests twenty gigabytes of storage, references the nzrt-standard StorageClass you just defined, and specifies an access mode of ReadWriteOnce. That access mode means only one node in the cluster can mount this volume for reading and writing at a time. That’s fine for something like a Nextcloud instance where you have one primary pod handling file access.

Once you have your claim, you need to attach it to a pod. The third example shows how that works inside a pod specification. You define a volume entry that references your claim by name — nextcloud-pvc in this case — and then inside your container definition, you mount that volume at a specific directory path. Here it’s mounted at the path where Nextcloud expects its web files to live. From the container’s point of view, it just sees a regular folder. The fact that it’s backed by persistent storage is completely transparent to the application.

Now let’s talk about the commands you’ll use day to day. You can list all persistent volumes across the cluster, list all claims within the nzrt-prod namespace specifically, pull up a detailed description of a particular claim to check its status or spot any error messages, and list all available StorageClasses. Those four commands cover most of what you need for routine inspection and troubleshooting.

Finally, reclaim policies — and this one is worth paying close attention to before you start deleting things. The wiki covers three options. Retain means that when you delete a PVC, the underlying PV stays intact and its data is preserved, but you are responsible for cleaning it up manually. Delete means that when the claim is removed, Kubernetes automatically removes the PV and all the backing storage with it. And Recycle is a third option that exists mostly as a historical footnote — it is deprecated, so don’t use it.

For most production workloads at NZRT, Retain is the safer default because it protects you from accidental data loss. Delete makes sense only when you are confident that automatically removing the data is acceptable, such as with temporary or test environments.

If you want to go deeper, the related topics in the wiki are Storage Overview and StatefulSets. StatefulSets in particular pair closely with Persistent Volumes when you need stable, predictable storage for applications that need to remember their state across restarts.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.