KubernetesL · PersistentVolumes and ClaimsPersistentVolumes and Claims
PV lifecycle — the states and transitions of a PersistentVolume
What you'll learn
- Describe the four PV lifecycle states in detail
- Trace the transitions between states
- Identify what each state means operationally
- Apply the production pattern for managing PV lifecycle
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
The PersistentVolume has four lifecycle states. Each state tells a story about the volume’s history and its operational implications. This lesson walks the states, the transitions, and what each one means.
The four states
stateDiagram-v2
[*] --> Available: PV created
Available --> Bound: PVC binds
Bound --> Released: PVC deleted
Released --> Available: reclaim succeeds (Retain)
Released --> [*]: reclaim succeeds (Delete)
Released --> Failed: reclaim fails
Failed --> [*]: manual intervention
Available --> [*]: operator deletes PV
Bound --> [*]: operator deletes PV (force)
Available
A PV in Available is created (either manually by the
operator or by the provisioner) and is not yet bound to a
PVC. It is available for binding.
kubectl get pv
# NAME CAPACITY STATUS RECLAIM POLICY
# pvc-7c8f2d8e-... 100Gi Available Delete
An Available PV is the steady state for pre-allocated
storage that has not yet been claimed.
Bound
A PV in Bound is bound to a PVC. The PV’s
spec.claimRef points to the PVC; the PVC’s
spec.volumeName points to the PV.
kubectl get pv
# NAME CAPACITY STATUS CLAIM RECLAIM POLICY
# pvc-7c8f2d8e-... 100Gi Bound production/data Delete
A Bound PV is in active use. The Pod mounts the PVC; the
CSI driver attaches and mounts the PV.
Released
A PV in Released had its PVC deleted but has not been
reclaimed. The PV is no longer bound; the underlying
storage is preserved (with Retain) or in the process of
being deleted (with Delete).
kubectl get pv
# NAME CAPACITY STATUS RECLAIM POLICY
# pvc-7c8f2d8e-... 100Gi Released Retain
A Released PV is a smell — it indicates data that is
preserved but inaccessible. With Retain, the operator
must decide what to do; with Delete, the provisioner
should have already deleted the PV (if it has not, the
state is Released and the cleanup is in progress).
Failed
A PV in Failed could not be reclaimed. The provisioner
attempted to delete the underlying storage but failed
(e.g., the cloud API call failed, the NFS export could
not be removed).
kubectl get pv
# NAME CAPACITY STATUS RECLAIM POLICY
# pvc-7c8f2d8e-... 100Gi Failed Delete
A Failed PV requires manual intervention: investigate
why the cleanup failed, fix the underlying issue, and
either retry the cleanup or delete the PV manually.
The reclaim policy and lifecycle
The reclaim policy determines what happens at the
Released -> [*] transition:
| Reclaim policy | Released -> … | Underlying storage |
|---|---|---|
| Retain | Stays Released until manual cleanup | Preserved indefinitely |
| Delete | Provisioner deletes the underlying storage | Deleted |
With Delete, the transition is Released -> (provisioner
deletes storage) -> [*]. The PV is deleted from the
cluster; the underlying storage is gone.
With Retain, the transition is Released -> (operator
decides) -> Available (with manual cleanup) or
[*] (with manual deletion).
The Failed state in detail
The Failed state can occur in two ways:
- Provisioner fails to delete underlying storage: the
PV’s reclaim policy is Delete; the provisioner’s API
call to delete the storage failed. The PV remains in
Failed. - Manual deletion fails: an operator tries to delete the PV; the PV’s finalizer prevents deletion; the deletion is stuck.
# PV name from `kubectl get pv`:
PV=pvc-7c8f2d8e-4b1a-4f6d-9a03-6d2e5b8c71f4
# Investigate a Failed PV
kubectl get pv "$PV" -o yaml
# status.message: "Failed to delete underlying EBS volume: rate limit exceeded"
The fix depends on the cause: retry the operation, increase the API rate limit, manually delete the underlying storage, or remove the finalizer.
Recovery from Released
A Released PV with Retain can be recovered to
Available by removing the claimRef:
# PV name from `kubectl get pv`:
PV=pvc-7c8f2d8e-4b1a-4f6d-9a03-6d2e5b8c71f4
kubectl edit pv "$PV"
# Delete spec.claimRef
# Save
# The PV transitions from Released to Available
The PV is now Available; a new PVC can bind to it. The underlying storage is preserved.
Quiz
Knowledge check · 4 questions
Q1. A PV has been in `Released` state for two weeks with `Retain` reclaim policy. What does this mean operationally?
Q2. A `Failed` PV requires manual intervention to clean up the underlying storage and the cluster object.
Q3. A team's cluster has accumulated 50 `Released` PVs with Retain reclaim. Design the cleanup procedure.
Cluster has been running for 6 months. 50 Released PVs with Retain. Each PV has 100-500 GB of underlying storage (EBS volumes). The team needs to identify which PVs have valid data and which can be deleted.
Q4. Explain the difference between `Released` and `Failed` PVs and the production action for each.
Passing score: 75%. Answers are checked in this browser.
Production discipline
AvailableandBoundare healthy. No action required.Releasedrequires a decision. Audit monthly; recover, delete, or keep per case.Failedrequires remediation. Investigate the cleanup failure; retry or manual cleanup.- Reclaim policy determines the transition. Retain = preserve; Delete = automatic cleanup.
- Tag Released PVs with a TTL. Automated cleanup after a defined period prevents accumulation.