Kubernetes / Basic: objects and execution boundaries / Lesson 6

Storage claims and data lifecycle

Distinguish ephemeral data, persistent claims, storage provisioning, and recovery guarantees before choosing a workload storage contract.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the model, assumptions, and boundaries of storage claims and data lifecycle.
Interpret both examples and distinguish declared intent from established evidence.
Diagnose the listed failures and justify the worked recovery decisions without executing cluster operations.

Separate container and data lifetimes

A container’s writable layer is disposable and should not be the only home for important data. A Pod volume has its own semantics; emptyDir survives some container restarts but ends with the Pod, while persistent storage has a separate lifecycle. The application still needs crash consistency and a recovery plan. State which data can be discarded, which can be regenerated, and which requires a verified copy. Replacing a Pod does not prove data was lost or preserved until the selected volume and storage system are identified. Avoid inferring durability from the word volume alone.

Read claim, volume, and class separately

A PersistentVolume represents available storage and a PersistentVolumeClaim requests suitable storage. A StorageClass describes provisioning policy and provider-related parameters. Dynamic provisioning depends on installed drivers, class configuration, credentials, topology, and backend capacity. The first PVC requests a class named training-retained; that class is an assumed lab contract, not a built-in Kubernetes class. A syntactically valid claim can remain Pending. Inspect binding and provisioning evidence before changing the application or widening permissions. The course neither provisions storage nor contacts a CSI driver or cloud provider.

yaml Illustrative storage request

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: booking-data
  namespace: training
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: training-retained
  resources:
    requests:
      storage: 5Gi

The installation must supply the named class and compatible storage. Five GiB and ReadWriteOnce express a request, not provisioned capacity, backup, or single-Pod fencing.

Understand modes without overpromising locking

Access modes describe supported attachment or mounting patterns and depend on the volume implementation. ReadWriteOnce typically refers to access from one node rather than a universal single-Pod lock. ReadWriteOncePod has stronger single-Pod semantics for supported CSI configurations. Neither mode supplies database transaction isolation or safe multiwriter application behavior. The second synthetic matrix separates a placement rule from an application invariant. Confirm the exact driver, filesystem, platform, and version before designing failover. A writable shared filesystem does not make two independent writers coordinate their business updates correctly.

text Synthetic storage responsibility matrix

property                     supplied by
node attachment constraints  storage driver and volume policy
transaction correctness      application and database
restorable historical copy   verified backup process
replacement identity         workload controller
credential protection        access and secret controls

Each guarantee has a different owner. Selecting persistent storage does not automatically satisfy transaction, backup, identity, and access requirements.

Review binding topology and deletion policy

Storage placement can constrain where a Pod runs, and delayed binding can consider scheduling before provisioning. A claim’s zone, node affinity, access mode, and capacity can therefore explain a Pending Pod. Reclaim policy controls what happens to the underlying volume after release according to its type and provisioner; deleting a claim may have irreversible consequences. Retain does not mean a complete backup or automatic recovery. Before any authorized deletion or migration, identify ownership, snapshots, keys, backend behavior, and the path to restore. Never delete a claim merely to clear an unexplained scheduling status.

Verify recovery at the application boundary

Snapshots and replicas can help availability and recovery but need consistency scope, retention, key access, and tested restoration. A snapshot API object does not prove a restorable application. Verify schema, relationships, user operations, and external side effects in an authorized isolated environment. StatefulSet identity and PVC association also do not replace database fencing, replication, or backups. Record storage assumptions beside the release and capacity plan because scale and replacement depend on them. Examples here are non-runnable declarations and synthetic reasoning; no device, filesystem, database, claim, snapshot, or real data is changed.

Common errors and fixes

ReadWriteOnce is treated as a single-writer guarantee

Why it happens: Node access semantics were confused with application locking.
How to fix it: Review driver behavior and explicit writer coordination.
Prevent it next time: Test failover and concurrent-write assumptions safely.

Deleting a claim destroys important data

Why it happens: Reclaim policy and backend effects were not reviewed.
How to fix it: Use the approved recovery plan and preserve evidence.
Prevent it next time: Require ownership and backup verification before deletion.

A Pod cannot schedule with bound storage

Why it happens: Storage topology conflicts with node constraints.
How to fix it: Compare volume affinity, zones, and scheduling evidence.
Prevent it next time: Plan topology and binding together.

Check your understanding

1. A container restarts inside its existing Pod. Is emptyDir necessarily deleted?

Show worked solution

No. emptyDir is tied to the Pod lifetime rather than each container lifetime. Replacing the Pod ends that volume’s lifetime. Neither observation makes it suitable as the only copy of durable application data.

2. A PVC requests a nonexistent StorageClass. Should application probes be relaxed?