Pod Volumes and Volume Lifetime

Application Design and Build / Guide 14 of 44 / Beginner

• Kubernetes1.36.4
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min
• Reviewed23 August 2026

Written against the versions above. `local-path` is this cluster's default StorageClass and uses `WaitForFirstConsumer`, so binding is deferred until a Pod is scheduled - the provisioner has to know which node to put the directory on. An `Immediate` class binds straight away, which is why the same manifest behaves differently on different clusters.

Before you start

• A cluster with a default StorageClass.
• The session creates namespace ckad-vol, a Pod with two emptyDir volumes, a 128Mi PVC, and two Pods that mount the claim one after the other.

1. 1

   An emptyDir lives and dies with the Pod

   Two emptyDir volumes: one default, one with medium: Memory.

   written to disk-backed
   written to memory-backed

   Both writable, and df shows what they actually are - the default is the node's disk, the Memory one is a tmpfs.

   Use the default for scratch space, caches and anything two containers need to share (see guide 20). Use medium: Memory when the data must never touch disk, remembering it counts against the container's memory limit - a tmpfs full of files can get you OOMKilled.

   Both are deleted with the Pod. Not with the container - a container restart keeps the emptyDir - but with the Pod.

   $kubectl create namespace ckad-volnamespace/ckad-vol created$kubectl -n ckad-vol wait --for=condition=Ready pod/scratch --timeout=120spod/scratch condition met$kubectl -n ckad-vol exec scratch -- sh -c 'echo "written to disk-backed" > /scratch/a.txt; echo "written to memory-backed" > /inmem/b.txt; cat /scratch/a.txt /inmem/b.txt'written to disk-backedwritten to memory-backed$kubectl -n ckad-vol exec scratch -- sh -c 'df -h /scratch /inmem | grep -vE "^Filesystem"'/dev/mapper/ubuntu--vg-ubuntu--lv                         47.1G     19.9G     25.0G  44% /scratchtmpfs                    16.0M      4.0K     16.0M   0% /inmem

   Expected resultBoth volumes writable, one on disk and one on tmpfs.

   Success conditionYou can pick between the two ephemeral options and know what each costs.

2. 2

   A claim that waits on purpose

   A PVC with no Pod using it:

   NAME   STATUS    VOLUME   CAPACITY   STORAGECLASS
   data   Pending                          local-path

   Pending, and nothing is wrong. The reason is in the StorageClass:

   NAME         MODE
   local-path   WaitForFirstConsumer

   The provisioner creates the volume on a specific node, so it cannot act until the scheduler has decided which node the Pod goes to. Binding is deliberately deferred - if it bound immediately, it might pick a node the Pod cannot be scheduled to and deadlock.

   This is worth recognising cold, because the instinct is to start debugging storage. The distinction:

   • Pending + WaitForFirstConsumer + no Pod yet -> normal, create the Pod.
   • Pending with a Pod already mounting it -> a real problem. kubectl describe pvc will have events.

   $sleep 10; kubectl -n ckad-vol get pvc dataNAME   STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGEdata   Pending                                      local-path     <unset>                 10s$kubectl get storageclass local-path -o 'custom-columns=NAME:.metadata.name,MODE:.volumeBindingMode'NAME         MODElocal-path   WaitForFirstConsumer

   Expected resultA Pending claim and a WaitForFirstConsumer class.

   Success conditionYou will not debug a PVC that is behaving correctly.

3. 3

   A Pod binds it

   The moment a Pod mounting the claim is scheduled:

   NAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS
   data   Bound    pvc-3316a118-094b-4be5-9221-714fe45610f3   128Mi      RWO            local-path

   Bound, with a PersistentVolume created automatically and named after the claim's UID. That is dynamic provisioning - you never wrote a PV.

   survives the pod

   Note ACCESS MODES: RWO - ReadWriteOnce, meaning it can be mounted read-write by one node at a time. It is the default and the only mode most provisioners support, and it is why a Deployment with two replicas and one RWO claim will have one Pod stuck if the replicas land on different nodes.

   $kubectl -n ckad-vol wait --for=condition=Ready pod/writer --timeout=180spod/writer condition met$kubectl -n ckad-vol get pvc dataNAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGEdata   Bound    pvc-3316a118-094b-4be5-9221-714fe45610f3   128Mi      RWO            local-path     <unset>                 15s$kubectl -n ckad-vol exec writer -- sh -c 'echo "survives the pod" > /data/keep.txt; cat /data/keep.txt'survives the pod$kubectl -n ckad-vol get pod writer -o 'custom-columns=POD:.metadata.name,NODE:.spec.nodeName'POD      NODEwriter   cka1001-node01

   Expected resultThe claim Bound and a file written to it.

   Success conditionYou have data in a volume the Pod does not own.

4. 4

   Delete the Pod and look again

   The Pod is deleted. The claim is not:

   NAME   STATUS   VOLUME                                     CAPACITY
   data   Bound    pvc-3316a118-...        128Mi

   and a completely new Pod mounting the same claim reads the file back:

   survives the pod

   That is the whole point. The lifecycle of a PVC is tied to the namespace, not to any Pod. Delete the workload, redeploy it, roll it forward - the data stays.

   What eventually removes it is deleting the claim, at which point the StorageClass's reclaimPolicy decides. local-path here is Delete, so the volume and its data go with the claim. Retain would keep the PV and its data behind for manual recovery.

   $kubectl -n ckad-vol delete pod writer --wait=truepod "writer" deleted from ckad-vol namespace$kubectl -n ckad-vol get pvc dataNAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGEdata   Bound    pvc-3316a118-094b-4be5-9221-714fe45610f3   128Mi      RWO            local-path     <unset>                 47s$kubectl -n ckad-vol wait --for=condition=Ready pod/reader --timeout=180spod/reader condition met$kubectl -n ckad-vol exec reader -- cat /data/keep.txtsurvives the pod$kubectl delete namespace ckad-vol --wait=falsenamespace "ckad-vol" deleted

   Expected resultThe claim survives the Pod and the file is still readable.

   Success conditionYou can prove data outlives the Pod that wrote it.

Troubleshooting

• A PVC is Pending and there are no events.

  Why: WaitForFirstConsumer with no Pod mounting it yet.

  Fix:Normal. Create the Pod; the claim binds when the Pod is scheduled.

• A PVC is Pending with no persistent volumes available.

  Why: No default StorageClass, or a storageClassName that does not exist.

  Fix:kubectl get storageclass and look for (default).

• A second replica cannot start - volume already attached.

  Why: ReadWriteOnce allows one node at a time.

  Fix:Use a StatefulSet with volumeClaimTemplates for a claim per replica, or a provisioner that supports ReadWriteMany.

• A memory-backed emptyDir got the container OOM-killed.

  Why: medium: Memory counts against the container's memory limit.

  Fix:Set sizeLimit on the volume and size the memory limit to include it. See guide 52.

Official sources

• Volumes
• Persistent Volumes
• Configure a Pod to Use a PersistentVolume