PersistentVolume Released: The claim that owned this volume is gone, and the volume is not reusable yet

A PersistentVolume in Released still holds its data but is no longer bound to any claim. With the Retain reclaim policy it stays that way permanently until an administrator acts.

Applies to: All Kubernetes versions

What it means

A PersistentVolume's phase reflects its binding, not its health. When the claim bound to it is deleted, the volume moves to Released and its reclaim policy decides what happens next. With Delete, the volume and usually the underlying storage are removed. With Retain, nothing happens: the data is preserved deliberately, and the volume sits in Released indefinitely. This is the safe default for anything valuable, and it has a consequence people meet later — a released volume will not bind to a new claim, even one that looks identical, because it still records a reference to the claim that is gone.

Most common causes

• A PersistentVolumeClaim was deleted while its volume used the Retain reclaim policy. This is the intended behaviour.
• A namespace was deleted, taking its claims with it.
• A StatefulSet was deleted — its volume claims are not removed automatically, but deleting them by hand releases the volumes.
• A reclaim policy of Recycle on a volume type that no longer supports it.
• A failed deletion under the Delete policy, leaving the volume released but not removed.

How to diagnose it

1. List volumes with their phase and policy: kubectl get pv shows status, claim, and reclaim policy together.
2. Check the stale claim reference: kubectl get pv PV_NAME -o jsonpath='{.spec.claimRef}'.
3. Confirm whether the underlying storage still exists in the backend before deciding anything.
4. For a failed delete, read the volume's events for the backend's error.

How to fix it

1. To reuse the volume and its data, clear the stale claimRef so it returns to Available and can bind to a new claim. Be certain about which data is on it first.
2. To discard it, delete the PersistentVolume object and then remove the underlying storage in the backend — under Retain, deleting the object does not delete the disk.
3. Set the reclaim policy deliberately per StorageClass rather than accepting whatever the default is, because the two choices differ in whether data survives an accident.
4. Resolve the backend error if a Delete policy failed to complete.

Notes

Under Retain, deleting the PersistentVolume object leaves the actual disk behind and still billable. Released volumes are a common source of quiet cloud spend, and they are invisible from inside the cluster once the object is gone.

Related

• PersistentVolumeClaim Pending — The claim has not bound to a volume
• ProvisioningFailed — Dynamic provisioning of a volume failed

Sources

• Kubernetes documentation — Persistent Volumes: reclaiming
• Kubernetes documentation — Storage Classes: reclaim policy
• Kubernetes documentation — StatefulSets