Storage

Domain 4 of the CKA curriculum is the smallest by weight — 10%, tied for last — and the most mechanical: three published competencies, no sprawling sub-topics, no shifting vocabulary between exam versions. It asks whether you can make a Pod's data outlive the Pod that wrote it, using exactly three cooperating objects — a StorageClass that describes a kind of storage and how to make more of it on demand, a PersistentVolumeClaim that asks for some, and a PersistentVolume that is the actual piece of storage once something has bound the two together. Small weight, real cost if you skip it: a StatefulSet with a misconfigured access mode, a PVC quietly stuck Pending forever, or a reclaim policy that either deletes data you needed or leaves an orphaned disk racking up cloud spend — all of that lives in this ten percent. This page covers the object model, the exact fields the exam probes, and a diagnostic sequence for the single most common storage failure: a claim that refuses to bind.

The domain: where 10% of the exam goes

☺ Like you're 10: Five topics make up the whole exam, and they're not equal sizes — Storage is the smallest slice, but it still has to be studied on its own.

These are the five CKA domains and weights exactly as published in the CNCF's Certified Kubernetes Administrator (CKA) Exam Curriculum, version 1.35. They sum to exactly 100% — 25 + 15 + 20 + 10 + 30 — and carry 27 published competencies between them. This page is Domain 4; the other four are linked below.

Storage publishes exactly three competencies: implement storage classes and dynamic volume provisioning; configure volume types, access modes and reclaim policies; manage persistent volumes and persistent volume claims. No more, no fewer — if a source quotes a fourth Storage bullet about troubleshooting clusters and nodes, that's a copy-paste artifact of the curriculum PDF's two-column layout, not a real fourth competency. Small as it is, don't skip it for Troubleshooting: a real chunk of D5's 30% is diagnosing broken storage, and you can't troubleshoot what you never learned to configure correctly the first time.

StorageClasses & dynamic provisioning

☺ Like you're 10: A StorageClass is the standing instruction that lets the cluster manufacture a new storage unit the instant someone asks for one, instead of making them wait for a human to build it by hand.

Before dynamic provisioning, a cluster administrator pre-created a pool of PersistentVolumes and hoped the sizes matched what applications would eventually ask for — static provisioning, still valid and still tested, but tedious at any real scale. A StorageClass flips that: it names a provisioner (a CSI driver, almost always — see Storage & the CSI for how that driver actually talks to the underlying disk system) and a set of parameters that provisioner understands, and the cluster creates a brand-new PersistentVolume on demand the moment a claim asks for that class.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"   # at most one class should carry this
provisioner: ebs.csi.aws.com          # a CSI driver name — cloud-specific, exam-agnostic in shape
parameters:
  type: gp3
  iops: "3000"
reclaimPolicy: Delete                 # the StorageClass default if the PV omits its own
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Four fields on that object are worth knowing cold. reclaimPolicy sets the default a dynamically provisioned PersistentVolume inherits — almost always Delete unless the class overrides it, which is the opposite of what most people assume. volumeBindingMode decides when binding and provisioning happen: Immediate binds as soon as the PVC exists, which on a multi-zone cluster can provision a disk in a zone no eligible node can reach; WaitForFirstConsumer delays binding until a Pod actually claims the volume, so the scheduler's node choice and the disk's zone are guaranteed to agree — the exam's default-correct answer for anything topology-aware. allowVolumeExpansion: true is what makes kubectl edit pvc with a larger storage request actually grow the underlying disk instead of being silently ignored. And exactly one StorageClass in a cluster should carry the is-default-class: "true" annotation — a PVC that names no storageClassName at all uses whichever class holds it, and two classes claiming default at once is a cluster misconfiguration, not a feature.

kubectl get storageclass                       # SC abbreviates it; look for (default) on one row
kubectl describe storageclass fast-ssd          # provisioner, parameters, reclaimPolicy, bindingMode
kubectl get storageclass -o \
  jsonpath='{.items[?(@.metadata.annotations.storageclass\.kubernetes\.io/is-default-class=="true")].metadata.name}'

Volume types, access modes & reclaim policy

☺ Like you're 10: Not every volume needs to survive the Pod — some are just scratch space that vanishes with it — and every durable one has to say how many Pods, and in what direction, are allowed to touch it at once.

Kubernetes' volumes field on a Pod spec covers far more than persistent disks. Ephemeral types live and die with the Pod: emptyDir is scratch space wiped the moment the Pod is removed from a node (useful for a sidecar sharing files with its main container), configMap and secret volumes project cluster config into a container's filesystem, and hostPath mounts a path from the node itself — powerful, and one of the riskier objects a NetworkPolicy or PodSecurity admission rule exists to restrict. This domain's actual subject is the durable path: a volume backed by a PersistentVolume, provisioned by a CSI driver, that outlives any single Pod.

Every PersistentVolume declares one or more access modes, and a PersistentVolumeClaim requesting a mode the volume doesn't offer will never bind:

A volume's reclaim policy decides what happens to the underlying storage after the PVC that bound it is deleted. Delete — the dynamic-provisioning default — removes the PersistentVolume object and asks the CSI driver to delete the backing disk: fast to clean up, unforgiving if the claim was deleted by mistake. Retain keeps both the PV object and the underlying disk around, but the PV moves to a Released phase and won't automatically bind to a new claim — an administrator has to manually clear its claimRef before anything can reuse it. Recycle is deprecated; don't reach for it. On a StatefulSet, don't assume PVCs vanish when the workload does: by default they outlive both Pod deletion and the StatefulSet's own deletion — deliberately, so a redeploy doesn't silently drop a database's disk — unless the StatefulSet sets a persistentVolumeClaimRetentionPolicy telling Kubernetes to delete them onStatefulSetDeletion or onScaledown.

PersistentVolumes & PersistentVolumeClaims

☺ Like you're 10: The claim is the request, the volume is the actual storage, and something in the middle has to match one to the other before a Pod can ever mount it.

A PersistentVolume (PV) is a cluster-scoped object representing a real piece of storage — capacity, access modes, and the driver that speaks to it. A PersistentVolumeClaim (PVC) is a namespaced request for some storage matching a size, an access mode, and (usually) a StorageClass. Binding is a matching process, not a creation process for the claim: the control plane looks for a PV that satisfies the PVC's requested size, access modes, and class, and links the two with a one-to-one claimRef. When the StorageClass names a provisioner and volumeBindingMode allows it, that PV doesn't have to exist yet — the provisioner creates it on the spot to satisfy the claim.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: reports-data
  namespace: shop
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: report-writer
  namespace: shop
spec:
  containers:
    - name: writer
      image: acme/report-writer:v3
      volumeMounts:
        - name: data
          mountPath: /var/lib/reports
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: reports-data       # the Pod references the claim, never the PV directly

Notice the Pod never names a PersistentVolume — only the claim. That indirection is the whole point: an application manifest stays portable across clusters with completely different underlying storage, because it only ever asks for "20Gi, read-write-once, fast-ssd class," and whatever cluster it lands in supplies a matching volume however that cluster knows how.

Diagnosing a Pending PVC

☺ Like you're 10: When a claim just sits there instead of getting matched to storage, the reason is almost always sitting in plain English in its own event log — read that before you guess.

A PersistentVolumeClaim stuck in phase Pending is one of the most common storage tasks on the exam, and it has a short, memorizable list of causes. Always start the same way — describe the claim and read its events, which name the failure directly far more often than any other object in Kubernetes:

kubectl get pvc reports-data -n shop                 # STATUS column: Pending
kubectl describe pvc reports-data -n shop | tail -15  # Events: at the very bottom, plain English

# fastest single check when no default StorageClass exists
kubectl get storageclass

# is a matching PersistentVolume even eligible, for static provisioning?
kubectl get pv -o wide

# check for a provisioner that simply isn't running
kubectl get pods -n kube-system | grep -i csi
kubectl logs -n kube-system -l app=ebs-csi-controller -c csi-provisioner --tail=40

Five causes cover almost every real case, roughly in order of how often they actually show up:

• No StorageClass resolves. The PVC names a storageClassName that doesn't exist, or names none at all and no class is marked default — dynamic provisioning has nothing to provision from, and the claim waits forever.
• WaitForFirstConsumer, and nothing has consumed it yet. This isn't a failure — it's the class working as designed. If the class uses that binding mode, the PVC stays Pending until a Pod actually references it; describing the claim will show a benign-looking event about waiting for a consumer, not an error.
• No PV satisfies the request, in static provisioning. A capacity request larger than any available PV, an access mode no existing PV offers, or a storageClassName mismatch (an empty string on the PVC only matches a PV with no class at all, not "any class") all leave the claim unmatched.
• The provisioner itself is unhealthy. A CSI controller Pod crash-looping, missing RBAC for the provisioner's ServiceAccount, or a cloud-side quota exceeded all block provisioning silently from the PVC's point of view — the claim's own events may just say "waiting for a volume to be created," so check the provisioner's Pods and logs next.
• Topology mismatch. With Immediate binding on a multi-zone cluster, a volume can provision in a zone that no Pod requesting it can ever be scheduled into — the claim binds, but the Pod that mounts it then sits Pending instead, for a reason that only shows up in its events, not the PVC's. This is the strongest practical argument for defaulting every StorageClass to WaitForFirstConsumer.

This page only covers what D4 tests; the mechanics of how a CSI driver actually attaches, formats and mounts a volume — the plugin architecture Kubernetes delegates all of this to — are unpacked in Storage & the CSI, and stateful application patterns built on top of PVCs (databases, queues, anything that needs one stable disk per replica) live in Stateful Workloads & Database Operators. Platform Engineering's Storage & Stateful Workloads deep dive covers the same PV/PVC/CSI model one altitude up, from the perspective of a platform team offering storage as a self-service API rather than a single cluster administrator provisioning it by hand.

Storage is the smallest domain; the largest is next. Continue to Troubleshooting for the 30% that ties every domain together, or revisit Servicing & Networking if Domain 3 is still fresh.