Kubernetes Storage: Volumes, PersistentVolumes, PVCs, and CSI

A container's writable filesystem lives exactly as long as the container. When a container crashes and the kubelet restarts it, the replacement starts from the image again and everything written at runtime is gone. Pods add a second cliff: when a Pod is deleted or rescheduled to another node, even storage tied to the Pod disappears with it. Any real application - a database, a message queue, anything with user data - needs its data to outlive both events, and that is the problem the Kubernetes storage stack solves in layers.

The layers are worth naming up front, because every storage question on the exam is really asking which layer does what. A Volume is storage declared in a Pod spec and mounted into its containers; it outlives container restarts but, for the ephemeral types, not the Pod itself. A PersistentVolume (PV) is a piece of storage that exists as a cluster resource in its own right, independent of any Pod. A PersistentVolumeClaim (PVC) is a request for such storage that a Pod consumes by name. A StorageClass describes a type of storage the cluster can create on demand, enabling dynamic provisioning. And the Container Storage Interface (CSI) is the plugin standard through which external storage drivers actually attach and mount the disks.

Not all storage needs to persist. Kubernetes ships several volume types whose lifetime is deliberately tied to the Pod, and the exam expects you to recognize what each is for.

An emptyDir volume is created empty when the Pod is assigned to a node and deleted when the Pod is removed. It survives container crashes and restarts within the Pod, which makes it the standard scratch space: caches, temporary processing files, and - importantly - a shared directory between containers in the same Pod, such as an app writing files that a sidecar ships elsewhere. A configMap volume projects the keys of a ConfigMap as read-only files inside the container, the usual way to deliver configuration files without baking them into the image. A secret volume does the same for Secrets - credentials, TLS certificates - mounted as files rather than injected as environment variables. A hostPath volume mounts a directory from the node's own filesystem into the Pod. It has legitimate niche uses, mostly for node-level agents that need to read host logs or sockets, but it couples the Pod's data to one specific node and opens access to the host, so it is flagged as a security risk and avoided for ordinary applications.

The common thread: none of these give an application durable data. For that, Kubernetes switches from volumes declared inline in a Pod to storage managed as its own resource - the subject of the next section.

Kubernetes splits persistent storage into two objects on purpose. A PersistentVolume is the supply side: a cluster-scoped resource representing an actual piece of storage - a cloud disk, an NFS export, a SAN LUN - with a capacity, access modes, and a reclaim policy. PVs are created by an administrator in advance (static provisioning) or by the cluster on demand (dynamic provisioning). A PersistentVolumeClaim is the demand side: a namespaced object in which an application requests storage by size, access mode, and optionally StorageClass, without knowing or caring what technology sits underneath. The separation is the same consumer/provider split as Pods and nodes: developers ask for what they need, infrastructure supplies it.

The two meet through binding. The control plane matches a pending PVC to a suitable PV - enough capacity, compatible access mode, matching class - and binds them one-to-one; a bound PV belongs to exactly one claim. The Pod then consumes the claim by name:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: db
spec:
  containers:
  - name: postgres
    image: postgres:16
    volumeMounts:
    - name: data
      mountPath: /var/lib/postgresql/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-claim

Notice what the Pod references: the claim, never the PV. If the Pod dies and is recreated on another node, it mounts the same claim and finds its data intact - persistence is achieved because the storage's lifecycle is anchored to the PVC and PV, not to the Pod. One scoping fact recurs on the exam: PVCs are namespaced, PVs are cluster-scoped.

Every PV and PVC declares access modes, which describe how the storage can be mounted. There are exactly four, each with a standard abbreviation, and inventing a fifth is a favorite distractor.

The trap the exam sets is in the word Once. ReadWriteOnce restricts the mount to one node, not one Pod. Several Pods scheduled onto that same node can all use an RWO volume simultaneously. If you genuinely need to guarantee that only one Pod anywhere in the cluster can write, that is ReadWriteOncePod, a newer mode supported only by CSI volumes. Keep the pair straight: RWO = one node, RWOP = one Pod.

Two supporting facts round out the picture. A PV may list several supported access modes, but it is mounted with only one mode at a time. And access modes are a matching constraint during binding: a claim requesting ReadWriteMany can only bind to a PV whose storage actually supports it, which is why RWX is common on NFS-style file storage and generally unavailable on plain cloud block disks. When a scenario mentions many Pods on different nodes writing to one shared volume, the answer is RWX and file or network storage underneath.

Deleting a Pod never deletes its PVC, and deleting a PVC does not automatically mean the data is destroyed - what happens next is decided by the PV's persistentVolumeReclaimPolicy. Two policies matter.

Retain keeps everything. When the claim is deleted, the PV is not removed and its data is untouched; the volume moves to the Released state, but it is not made available to a new claim automatically, because it still contains the previous owner's data. An administrator must intervene - back up or scrub the data, then delete or recreate the PV - before the storage is reused. Retain is the safety-first choice for data you cannot afford to lose to an accidental deletion.

Delete removes the PV object and the underlying storage asset in the external infrastructure - the cloud disk itself is deleted along with the claim. This is the automation-first choice and it is the typical default for dynamically provisioned volumes, where storage was created on demand and can be discarded on demand. The convenience cuts both ways: deleting the wrong PVC can destroy real data, which is exactly why the distinction is exam-worthy.

• Need the data to survive claim deletion, with manual cleanup? Retain.
• Want storage to be created and destroyed automatically with the claim? Delete.
• A third historical policy, Recycle, performed a basic wipe for reuse; it is deprecated, and recognizing it as obsolete is all KCNA requires.

A last vocabulary anchor: a PV's status walks through Available (unbound), Bound (attached to a claim), and Released (claim deleted, awaiting reclaim) - and with Retain, Released is where it waits for a human.

Static provisioning has an obvious scaling problem: an administrator must guess demand and hand-create PVs ahead of every claim. Dynamic provisioning removes the guesswork. A StorageClass is a cluster-scoped object that describes a kind of storage the cluster can manufacture: which provisioner (storage driver) to call, with what parameters (disk type, performance tier, replication), and what reclaim policy the resulting PVs get. When a PVC names a StorageClass and no suitable PV exists, the provisioner creates a new volume in the backing storage system, wraps it in a PV, and binds it to the claim - supply generated to order.

A cluster typically offers several classes as a menu: a fast SSD class for databases, a cheaper standard class for bulk data, an RWX-capable file storage class for shared volumes. One class can be marked as the default StorageClass, which is applied to any PVC that does not specify one - the reason storage appears by magic on managed clouds: EKS, AKS, and GKE ship a default class wired to their disk services, so a bare PVC just works. A PVC can also opt out of dynamic provisioning entirely by setting an empty class name, forcing a bind to a pre-created PV.

One refinement is worth recognizing: a StorageClass's volumeBindingMode. The default, Immediate, provisions and binds as soon as the claim is created. WaitForFirstConsumer delays provisioning until a Pod actually uses the claim, so the volume can be created in the same availability zone the scheduler picks for the Pod - avoiding the classic failure where a disk exists in zone A and the Pod lands in zone B. For the exam, the core equation is enough: StorageClass plus PVC equals a PV created on demand.

Someone has to actually create the cloud disk, attach it to the right node, format it, and mount it into the Pod. Historically that code lived in-tree: volume plugins for each vendor were compiled into Kubernetes itself, so adding or fixing a storage integration meant changing and re-releasing Kubernetes core. The Container Storage Interface (CSI) ended that. CSI is an open standard API between container orchestrators and storage systems: a vendor implements a CSI driver once, ships it as its own deployable component running in the cluster, and Kubernetes calls the standard interface to provision, attach, mount, and unmount volumes. Drivers now develop and release on their own schedule, out of tree.

You can recognize CSI in the wild by names like ebs.csi.aws.com or pd.csi.storage.gke.io appearing as the provisioner in a StorageClass. The old in-tree cloud volume plugins have been migrated to CSI drivers, and new storage capabilities land in CSI first - features from earlier sections, such as the ReadWriteOncePod access mode and much of volume snapshotting and expansion, exist only through CSI drivers.

For KCNA, place CSI beside its siblings and its role becomes obvious. Kubernetes standardizes its extension points as interfaces: CRI for container runtimes, CNI for networking, and CSI for storage. A question offering those three as options and asking which one storage vendors implement is testing exactly this mapping. CSI is not a volume type you pick in a Pod spec and not a competitor to PVs and PVCs - it is the plumbing layer that StorageClass provisioners and PV attach/mount operations call into.

The stack comes together in stateful applications. A Deployment treats its Pods as interchangeable, and if you attach one PVC to a Deployment, every replica tries to share that single claim - unworkable for a database where each member needs its own disk. A StatefulSet solves this with volumeClaimTemplates: a template from which a PVC is stamped out for each replica, paired with the replica's stable identity. A StatefulSet named db with three replicas and a template named data yields Pods db-0, db-1, db-2 and claims data-db-0, data-db-1, data-db-2 - each Pod permanently paired with its own claim.

Walk the full lifecycle for one replica. The StatefulSet creates db-1 and its PVC data-db-1. The PVC names a StorageClass, so the CSI provisioner creates a disk, wraps it in a PV, and binds it. The scheduler places the Pod (with WaitForFirstConsumer, the disk is created in the Pod's zone), the driver attaches and mounts the volume, and the database writes to it. Now the node dies. The Pod is recreated - same name, db-1 - on another node, mounts the same PVC, and finds every byte it wrote. Scaling the StatefulSet down deletes Pods but, by default, keeps their PVCs, so scaling back up reunites each replica with its data; deleting the claims is a deliberate separate act.

That is the whole point of the storage stack in one scenario: the Pod is disposable, the claim endures, the class manufactured the volume, and CSI did the physical work. If you can narrate that chain - and name which object plays which part - you can answer any KCNA storage question by locating it in the chain.