Skip to content

PV & PVC binding mechanism

The PV & PVC binding mechanism defines how storage resources are provisioned and connected in Kubernetes. This process decouples storage from the Pod lifecycle, allowing data to persist independently of application state.

Core Concepts

PersistentVolumes (PV)

A PersistentVolume (PV) represents a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [[Storage Classes]].^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md] PVs are actual storage resources backed by various media such as NFS, node-local storage, or cloud services.^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

PersistentVolumeClaims (PVC)

A PersistentVolumeClaim (PVC) is a request for storage by a user.^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md] It functions similarly to how a Pod requests compute resources (CPU/Memory), but instead requests specific storage capacity and access modes (e.g., ReadWriteOnce, ReadOnlyMany).^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

Binding Lifecycle

The interaction between PV and PVC follows a specific workflow to match requests with resources^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  1. Provisioning:

    • Static: An administrator creates PVs manually. These resources exist in the cluster waiting to be claimed.
    • Dynamic: If a PVC specifies a StorageClass, Kubernetes can automatically create a matching PV on the fly.^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

  2. Matching:

    • Once a PVC is created, the control plane searches for a PV that satisfies the PVC's requirements (size, access modes, storage class).^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

  3. Binding:

    • If a matching PV is found, the two are Bound. The binding is a one-to-one exclusive mapping.^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]
    • If no match is found, the PVC remains Pending indefinitely until a suitable PV is created or added to the cluster.^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

PV Lifecycle States

The binding process drives the state transitions of a PersistentVolume^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  • Available: A free resource in the cluster that is not yet bound to any PVC.
  • Bound: The PV has been bound to a specific PVC.
  • Released: The PVC has been deleted, but the PV has not yet been reclaimed by the cluster.
  • Failed: The automatic reclamation of the volume has failed.

Reclaim Policy

When a PVC is deleted (releasing the PV), the data on the underlying volume is handled according to the PV's Reclaim Policy^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  • Retain: The volume remains in a Released state with data intact, requiring manual reclamation by an administrator.
  • Recycle: (Deprecated) Automatically scrubbed data (rm -rf /volume).
  • Delete: The PV and the associated underlying storage asset (e.g., disk) are automatically deleted.

Access Modes

PVCs define how the storage can be accessed, which influences binding decisions^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
  • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes.
  • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes.
  • ReadWriteOncePod (RWOP): The volume can be mounted as read-write by a single Pod (ensuring exclusivity across the cluster).

Sources