KubernetesL · PersistentVolumes and ClaimsPersistentVolumes and Claims
PVC lifecycle — the states and transitions of a PersistentVolumeClaim
What you'll learn
- Describe the PVC lifecycle states and transitions
- Identify what Pending means operationally
- Trace the path from PVC submission to Pod mount
- Apply the production pattern for managing PVC 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 PersistentVolumeClaim has a simpler lifecycle than the PV: only two states, Pending and Bound. This lesson walks the states, what each means, and the production patterns for managing the lifecycle.
The two states
A PVC is in one of two states:
| State | Meaning |
|---|---|
Pending | The PVC has been submitted but is not yet bound to a PV. |
Bound | The PVC is bound to a PV; the PV’s claimRef points to the PVC. |
stateDiagram-v2
[*] --> Pending: PVC submitted
Pending --> Bound: matching PV found or created
Bound --> [*]: PVC deleted (PV enters Released or is deleted)
Pending
A Pending PVC has been submitted but is not yet bound.
The reasons for Pending:
- No matching PV: no existing PV matches the PVC’s criteria, and no provisioner is configured (or the provisioner is slow).
- No matching provisioner: the StorageClass references a provisioner that does not exist.
- StorageClass mismatch: the PVC asks for
ssdbut nossdPVs or provisioners exist. - Selector mismatch: the PVC has a selector that no existing PV matches.
kubectl get pvc
# NAME STATUS VOLUME CAPACITY ACCESS MODES
# data Pending RWO
kubectl describe pvc data
# Events:
# Type Reason Message
# Warning ProvisioningFailed no persistent volumes available for this claim
# and no storage class is set
The events are diagnostic. kubectl describe pvc is the
production starting point for “the PVC is Pending.”
Bound
A Bound PVC is matched to a PV. The PV’s claimRef
points to the PVC; the PVC’s volumeName points to the
PV. The Pod can mount the PVC.
kubectl get pvc
# NAME STATUS VOLUME CAPACITY ACCESS MODES
# data Bound pvc-7c8f2d8e-... 100Gi RWO
kubectl get pv pvc-7c8f2d8e-...
# NAME CAPACITY STATUS CLAIM RECLAIM POLICY
# pvc-7c8f2d8e-... 100Gi Bound production/data Delete
A Bound PVC is the steady state. It remains Bound until
the PVC is deleted or the PV fails.
The deletion sequence
When a PVC is deleted:
- The PVC transitions to a terminating state (briefly).
- The PV’s
claimRefis cleared (with Retain) or the PV is deleted (with Delete). - The underlying storage is preserved (with Retain) or deleted (with Delete).
A Pod that is using the PVC blocks the PVC deletion. The kubelet does not allow the PVC to be deleted while the Pod is still mounting it. The deletion waits for the Pod to be deleted first.
# Attempting to delete a PVC that is in use
kubectl delete pvc data
# Error from server (Forbidden): error when deleting
# "data": PersistentVolumeClaim "data" is in use by Pod(s)
The fix: delete the Pod (or the workload that owns the Pod), then delete the PVC.
The access modes in lifecycle context
The PVC’s access modes affect which PVs can bind and which Pods can mount:
- RWO: single-node mount. The Pod must be on a node that can attach the volume.
- ROX: multi-node read-only. Multiple Pods can mount the same PVC read-only on different nodes.
- RWX: multi-node read-write. Multiple Pods can mount the same PVC read-write on different nodes.
- RWOP: single-Pod mount. Only one Pod can mount the PVC.
A PVC with RWX requires a backend that supports
multi-node mounting (NFS, CephFS, EBS multi-attach). A
PVC with RWO cannot bind to a PV that does not support
RWO.
The capacity in lifecycle context
The PVC’s capacity request is the minimum:
- Submission: PVC requests 100 GB. If no PV has
= 100 GB capacity, the PVC is Pending.
- Binding: the bound PV may have more capacity than requested (e.g., 200 GB). The PVC sees the PV’s actual capacity.
- Expansion: the PVC’s request can be increased (with
allowVolumeExpansion: trueon the StorageClass). The CSI driver handles the expansion.
Quiz
Knowledge check · 4 questions
Q1. A Pod is using a PVC. The operator runs `kubectl delete pvc data`. What happens?
Q2. A PVC in `Pending` state blocks the Pod that mounts it from being scheduled.
Q3. Your team submits a PVC for a new database. The PVC is Pending for 5 minutes. Walk through the diagnostic.
PVC: storageClassName: db-ssd, 100 GB, ReadWriteOnce. Status: Pending for 5 minutes. No events have fired yet. The cluster has been running for a year; databases typically bind within 30 seconds.
Q4. Explain why `kubectl delete pvc` is blocked while the PVC is in use by a Pod, and how to handle the situation.
Passing score: 75%. Answers are checked in this browser.
Production discipline
kubectl describe pvcis the diagnostic starting point. Events show why a PVC is Pending.- Pending PVCs block Pod scheduling. Monitor Pending state with alerts.
- PVC deletion is blocked by Pod mount. Delete the Pod first, then the PVC.
- Finalizers prevent accidental deletion. Understand the finalizer before bypassing it.
- Capacity is a minimum. The PV can be larger; the PVC sees the actual capacity.