Welcome to the NZRT Wiki Podcast. Today we’re looking at Storage Overview.

If you’ve worked with Kubernetes before, you’ve probably noticed that it goes out of its way to separate your applications from the details of where their data actually lives. That’s the core idea behind Kubernetes storage — it abstracts the underlying storage system away from your workloads, so your pods don’t need to know whether their data is sitting on a local disk, a network drive, or a cloud volume. They just ask for storage, and Kubernetes handles the rest.

Let’s walk through how that actually works, because there’s a clear hierarchy to understand here. Think of it as a chain of four layers, each one sitting on top of the next.

At the top of that chain is something called a StorageClass. This is essentially a template or a definition that says “here’s the type of storage we can provision, and here’s how to provision it.” It points to a provisioner — the thing that actually knows how to create storage on your underlying infrastructure.

Beneath the StorageClass sits the PersistentVolume, or PV. This is the actual storage resource — the real chunk of space that exists in your cluster. It can be created manually by an administrator, or it can be created automatically and dynamically by Kubernetes using the StorageClass you just defined.

Below the PersistentVolume is the PersistentVolumeClaim, or PVC. This is how a pod makes a request for storage. Instead of pointing directly at a specific volume, a pod says “I need some storage with these characteristics” — and the PVC is that request. Kubernetes then matches the claim to an appropriate PersistentVolume.

And finally, at the bottom of the chain, you have the Pod itself. The pod mounts the PVC as a volume, and from that point on it just reads and writes files like normal. It never needs to know anything about the StorageClass or the underlying PersistentVolume that made it all possible.

So to put it simply — StorageClass defines how to make storage, PersistentVolumes are the actual storage, PersistentVolumeClaims are how pods ask for it, and Pods consume it.

Now let’s look at the five key storage objects you’ll encounter in Kubernetes. There are five of them, each with a distinct purpose.

First, the PersistentVolume — this is a cluster-level resource. It represents actual storage, and it can be provisioned manually by an admin or created dynamically when a claim comes in.

Second, the PersistentVolumeClaim — this operates at the namespace level. It’s the pod’s way of saying “I need storage,” and Kubernetes binds it to a matching PersistentVolume.

Third, the StorageClass — this is the provisioner definition. When dynamic provisioning is enabled, Kubernetes uses the StorageClass as a blueprint to create new PersistentVolumes on demand.

Fourth, the ConfigMap — this is how you inject non-sensitive configuration data into your pods. Think of it as key-value pairs that your application can read at runtime, without baking that configuration into your container image.

And fifth, the Secret — this is similar to a ConfigMap, but intended for sensitive data like passwords, tokens, and certificates. One important thing to know here: Secrets are base64-encoded by default, but they are not encrypted. Base64 is an encoding format, not a security measure — so if you need proper encryption at rest, that requires additional configuration in your cluster.

The last thing to understand is access modes — these define how a volume can be mounted across nodes in your cluster. There are three modes to know about.

ReadWriteOnce means only one node can mount that volume with read-write access at a time. This is the most common mode and suits most standard workloads.

ReadOnlyMany means the volume can be mounted as read-only across many nodes simultaneously. Useful when multiple pods need to read shared data but none of them need to write.

ReadWriteMany means many nodes can mount the volume with full read-write access at the same time. This requires storage backends that explicitly support it — not all do — so check your provider’s documentation before assuming this is available.

If you want to dive deeper, the related topics from this wiki page include Persistent Volumes, which goes into the full lifecycle of PV creation and binding, ConfigMaps and Secrets, which covers how to use those objects in practice, and StatefulSets, which is where storage gets especially interesting because StatefulSets are designed for workloads that need stable, persistent storage across restarts.

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