Black Friday · 27 Nov 2026

Up to 90% off selected certifications.

One time only offer for a very precious career goal. Limited coupons, waitlist first.

Free lesson · CKA Prep Program · Module 5: Storage

Bind PVs and PVCs Predictably

PersistentVolumes are cluster storage carved into chunks; claims are namespaced requests for a chunk. Binding matches them by rules, and Pending claims always name the unmatched rule if you read the events.

12 min reading

Objectives

  • Explain the PV lifecycle: Available, Bound, Released, Failed
  • Match claims to volumes with capacity plus access modes plus selectors
  • Read why a claim stays Pending from its events
  • Set reclaim policies so data survives the claim that used it

Why this matters

Stateful workloads need storage that outlives pods, nodes and sometimes namespaces. The two-object split (admin-owned PV, user-owned PVC) lets storage admins provision once while developers claim without knowing backends. The exam lives in the matching rules, because every Pending claim is a quiz with the answer in its events.

Concepts

A PV carries capacity, access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), a storage class name, a reclaim policy, and the backend details. A PVC requests capacity (minimum satisfied, not exact), access modes (intersection with the PV must cover the request), optionally a storage class, and optionally a selector for labels. Binding is exclusive: one Bound claim per volume until released.

The lifecycle runs Available to Bound on match, Bound to Released when the claim is deleted, then per the reclaim policy: Retain keeps the data (requiring manual cleanup before reuse), Delete removes volume plus data, Recycle is deprecated history. Released volumes never auto-rebind: stale data plus old claims must be cleared deliberately.

Worked example

One volume, one claim, one pod, receipts at each bind:

# admin carves the chunk (hostPath for the lab only)
apiVersion: v1
kind: PersistentVolume
metadata: { name: pv-demo }
spec:
  capacity: { storage: 2Gi }
  accessModes: [ReadWriteOnce]
  persistentVolumeReclaimPolicy: Retain
  hostPath: { path: /srv/pv-demo }
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: claim-demo, namespace: demo }
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 1Gi } }

kubectl get pv moves Available to Bound; the 1Gi claim fits the 2Gi volume because requests are minimums. Delete the claim and watch Released plus Retain: the data sits protected until an admin decides, which is exactly the safety net production wants.

Exam notes

Access-mode mismatch is the top Pending cause: a ReadWriteMany claim against ReadWriteOnce volumes waits forever. Storage class mismatch (named versus empty string) blocks binding silently across provisioners. And deleting a Bound PVC does not delete a Retain volume: the data survives, which is the feature, and the cleanup is yours.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

Carve a fictional 5Gi Retain volume and bind a 2Gi claim to it, then delete the claim and document each lifecycle state with the proving command output. State what an admin must do before that volume serves again.

Pass criteria

PV plus PVC valid with matching modes; Available, Bound, Released shown with outputs; reuse answer names manual cleanup under Retain.

Sources

Log in to track progressFree account: stores only your lesson progress and quiz results.