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.

Declaring and mounting a volume

A volume is defined once, at Pod level, in spec.volumes, and each container that needs it mounts it with its own volumeMounts entry (volume name plus mountPath). The two halves are separate on purpose. A volume is visible only to the containers that list it in their own volumeMounts: a second container with no mount entry for it sees nothing at that path, even though the volume exists in the same Pod. Options such as readOnly: true are also set per mount, so one container can write a volume that another only reads.

Two look-alikes do not give you a Kubernetes volume. A Dockerfile VOLUME instruction is image metadata, not an entry in spec.volumes; whatever the runtime does with it, it is not a Kubernetes volume and gives no persistence beyond the container. And writing to a path in the container's own filesystem, without a volume mounted there, is lost when the container is replaced.

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 - one file per key, named after the key and holding its value - the usual way to deliver configuration files without baking them into the image. A secret volume does the same for Secrets - credentials, TLS certificates. Mounting is not the only way in: a container can also take individual keys as environment variables (env with valueFrom) or all keys at once (envFrom). Mounted files are refreshed when the object changes (except when mounted with subPath); environment variables are fixed when the container starts. 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.

Why sensitive values belong in a Secret

A Secret, not a ConfigMap, is the object for passwords, tokens and keys, and the reasons are more than the name. Secrets can be governed by their own RBAC rules, separate from ConfigMaps; the cluster can be configured to encrypt them at rest in etcd; and a secret volume is backed by tmpfs (memory), so the values are not written to the node's disk. Know the limit too: by default Secret data is only base64-encoded, which is an encoding, not encryption - anyone allowed to read the Secret can decode it, and encryption at rest must be turned on deliberately. Security controls around Secrets are covered in the Kubernetes security lesson.

hostPath in practice

The canonical legitimate use of hostPath is a node agent run as a DaemonSet - for example a log shipper that mounts the node's /var/log so each copy reads the logs of the node it runs on. The flip side shows why ordinary apps should avoid it: hostPath data lives on one node's disk. If a Pod writes, say, a cache directory to a hostPath and is later rescheduled to another node (for example after the original node fails), the new Pod mounts the same path on the new node and finds none of the earlier files; nothing was deleted, they are simply on the other machine.

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, so a second claim in any namespace cannot bind it and needs another PV. A claim receives the whole PV it binds to: a 2Gi request matched to an 8Gi volume gets all 8Gi, and the unused capacity is not shared with anyone else. 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 - which is why kubectl get pv takes no namespace flag while kubectl get pvc -n <ns> does. It also limits which claim a Pod can use: a claimName is resolved only in the Pod's own namespace. If the claim exists only in another namespace, the Pod stays Pending with an event saying the persistentvolumeclaim was not found; the fix is a claim in the Pod's namespace, not a cross-namespace reference.

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.

What happens when RWO is exceeded? A cloud block disk can attach to only one node at a time. If a second Pod using the same RWO claim is scheduled to a different node, it cannot attach the volume: it stays in ContainerCreating and its events show a Multi-Attach error (the volume is already exclusively attached to another node). A Pod on the node that already holds the volume mounts it fine. The abbreviations matter in practice too: kubectl get pv and kubectl get pvc print access modes in their ACCESS MODES column as RWO, ROX, RWX and RWOP, not the full names.

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 before the storage is reused: either delete the PV object (the backing disk and its data remain) and create a new PV for the same storage after backing up or scrubbing the data, or edit the PV to clear its claimRef so it returns to Available and can bind a new claim - with the old data still on it. 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 the default for dynamically provisioned volumes: a dynamically provisioned PV inherits the reclaimPolicy of its StorageClass, and a StorageClass that sets no reclaimPolicy defaults to Delete. (A manually created PV defaults to Retain.) So deleting and recreating a claim on such a class does not get the data back - the old PV and disk are already gone, and the new claim gets a fresh, empty volume. 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. The binding mode explains two symptoms. On a WaitForFirstConsumer class, a new PVC stays Pending until a Pod that uses it is scheduled - expected behaviour, not an error (its events say it is waiting for the first consumer). On an Immediate class with zonal disks, the disk may be created in a zone where the Pod cannot run - for example because the Pod's scheduling constraints or available capacity put it in another zone - and the Pod stays Pending with a volume node affinity conflict; switching to a WaitForFirstConsumer class prevents it. A StorageClass's reclaimPolicy field, if unset, defaults to Delete (see the reclaim section). 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: the StatefulSet's persistentVolumeClaimRetentionPolicy defaults to whenScaled: Retain and whenDeleted: Retain. Scaling back up recreates db-2, which reattaches the very same claim data-db-2 by name - the original volume with its earlier data, not a copy or a fresh disk. Deleting the claims is a deliberate separate act (or a policy changed to Delete).

Contrast the anti-pattern: a Deployment whose Pod template mounts one RWO claim backed by a block disk. Every replica shares that single claim, so replicas on other nodes stick in ContainerCreating with a Multi-Attach error - and even when they share a node, they share one disk instead of each having its own. Giving each replica its own durable storage is exactly what a StatefulSet's volumeClaimTemplates provide.

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.