Kubernetes PersistentVolume and PersistentVolumeClaim Lifecycle

Posted on In Views: Word count in article: 495 Reading time ≈ 2 mins.
DevOps, Cloud, Kubernetes — personal tech notes by ChengQing Su

The lifecycle of a PV and PVC can be divided into four phases: Provisioning, Binding, Using, and Reclaiming.
This post covers each of these four phases.

Provisioning

The main task of this phase is to provision a PV for use in subsequent phases. There are two ways to provision a PV: static and dynamic.

Static: A cluster administrator creates a fixed number of PVs that are available for use by cluster users.
Dynamic: PVs are created dynamically based on a PVC. When no existing static PV can match a PVC, the cluster will attempt to provision a PV based on that PVC. This approach requires the cluster administrator to create and configure a StorageClass in advance. If you do not want PVs to be dynamically provisioned from PVCs, you can set spec.storageClassName to "" in the PVC.

Binding

This phase binds a PV to a PVC. The binding relationship is one-to-one, and bidirectional binding between a PV and a PVC is achieved through ClaimRef.

When a new PVC is created, the cluster first checks whether there is an unbound PV available. If one exists, it is bound to the PVC. If none is found, the cluster will attempt to dynamically provision a PV for the PVC (which may or may not succeed), and that PVC will remain permanently bound to its dynamically provisioned PV.
When a PVC has no matching PV, its status is unbound. Once it matches a PV, its status becomes bound.

Using

Pods use PVCs as volumes. The cluster locates the PV bound to the PVC and mounts it into the Pod. As long as a Pod using the PVC exists, that PVC remains active.

To ensure that an active PVC and its bound PV are not accidentally deleted from the system — since deletion could result in data loss — Kubernetes provides a feature called Storage Object in Use Protection. As a result, when a user deletes an active PVC, the PVC is not actually deleted until no Pod is using it. Similarly, if a PV that is bound to a PVC is deleted, the PV will not be removed until no PVC is bound to it.

Reclaiming

This phase refers to the reclamation of a PV. After a PV is released by its PVC (i.e., the binding is removed), the cluster reclaims the PV according to its reclaim policy.
Currently, three policies are supported: Retain, Recycle, and Delete.

Retain: This policy allows manual reclamation of storage resources. After the bound PVC is deleted, the PV is preserved but will not be bound by any other PVC.
Delete: This policy deletes both the PV and its associated external storage resource, such as an AWS EBS volume or an Azure Disk. The default reclaim policy for a StorageClass is Delete, and PVs dynamically provisioned from it will inherit this value.
Recycle (deprecated): This policy removes all data on the PV and then makes it available to be bound by a PVC again.