Volumes, claims and persistence

The mechanism

Container files, ephemeral volumes and persistent volumes have different lifecycles. An emptyDir belongs to a Pod and can survive a container restart inside that Pod, but it is removed when the Pod leaves the node. A PersistentVolumeClaim requests persistent storage through the cluster’s storage system.

A claim’s binding and mount behavior depends on storage classes, provisioners, access modes and topology. Creating a PVC does not guarantee immediate usable storage. Some classes delay binding until scheduling decisions identify a suitable location.

Persistence is not backup. A volume can preserve data across Pod replacement while still losing data through corruption, accidental writes or provider failure. Define recovery objectives and test restoration separately from attachment.

Worked example

This offline PVC example expresses a storage request without choosing a provider. It is not applied. A real cluster may have no default StorageClass, and provisioning can incur cost. Review class, reclaim policy and topology before any live use.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: parcelops-data
  namespace: handbook-lab
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Practice: predict, inspect, explain

Offline exercise. Trace data lifetime through a container restart, Pod replacement and claim deletion. For the last case, explain why reclaim policy and provider behavior matter; do not perform deletion. Then compare the access requirement of one writer with multiple replicas needing shared data.

Expected observation: ReadWriteOnce describes a node-level access mode and is not simply “one Pod forever”. Application consistency still needs a design. Write a proposed restore test that uses a separate approved environment and verifies application-level data, rather than only a successful volume mount.

Troubleshooting and trade-offs

If a PVC remains Pending, inspect StorageClass, capacity, topology and events. If a Pod cannot mount a bound volume, investigate attachment and node constraints. If two replicas corrupt shared data, the storage mode alone may not solve application coordination. Do not delete claims as a troubleshooting shortcut; the data consequences can be irreversible.

Interview practice

Completion check

Explain data lifetime and recovery as separate properties without deleting or provisioning any storage.

Sources and version notes

Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.

• Official documentation: Persistent volumes
• Official documentation: Assign pod node
• Official documentation: Pod lifecycle