Skip to main content
RunBook Academy

KubernetesL · PersistentVolumes and ClaimsPersistentVolumes and Claims

PV lifecycle — the states and transitions of a PersistentVolume

Advanced⏱ ~16 minkubectl

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

Not yet marked complete on this device.

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 policyReleased -> …Underlying storage
RetainStays Released until manual cleanupPreserved indefinitely
DeleteProvisioner deletes the underlying storageDeleted

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:

  1. 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.
  2. 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

  1. Q1. A PV has been in `Released` state for two weeks with `Retain` reclaim policy. What does this mean operationally?

  2. Q2. A `Failed` PV requires manual intervention to clean up the underlying storage and the cluster object.

  3. 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.

  4. 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

  • Available and Bound are healthy. No action required.
  • Released requires a decision. Audit monthly; recover, delete, or keep per case.
  • Failed requires 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.