Skip to content

Kubernetes PersistentVolumes (PV)

PersistentVolumes (PV) are an abstraction in Kubernetes that represent storage resources in a cluster^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. They function as a bridge between the physical or network storage hardware (such as NFS, cluster nodes, or cloud services) and the logical storage requests made by applications^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

A defining characteristic of a PV is that its lifecycle is independent of the Pod lifecycle^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. This separation ensures that data persists and remains available even if Pods are destroyed, scaled up, or scaled down^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Provisioning

PVs can be provisioned in two ways:

  1. Static: A cluster administrator manually creates PVs representing available storage resources^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
  2. Dynamic: If a [[persistent-volume-claim|PersistentVolumeClaim]] (PVC) specifies a StorageClass, Kubernetes can dynamically provision a new PV to match the request automatically^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Lifecycle and Binding

The relationship between storage and users is established via [[persistent-volume-claim|PersistentVolumeClaims]]^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. A PVC acts as a user's request for specific storage resources (size and access modes). The system continuously searches for a PV that matches the PVC's criteria^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Once a match is found, the two are bound. If no suitable PV exists, the PVC will remain in a Pending state indefinitely until a matching PV becomes available^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

PV Status

A PersistentVolume can exist in one of the following phases^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

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

Access Modes

PVs support specific access modes that define how they can be mounted on nodes^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  • ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. This also allows multiple Pods on the same node to access the volume.
  • ReadOnlyMany (ROX): The volume can be mounted as read-only by many nodes^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
  • ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
  • ReadWriteOncePod (RWOP): The volume can be mounted as read-write by a single Pod, ensuring exclusive access across the entire cluster^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Reclaim Policy

When a PVC is deleted, the PV enters a Released state. The ReclaimPolicy dictates what happens to the underlying storage resource^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]:

  • Retain: The volume is kept manually. The administrator must handle data recovery and deletion^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
  • Recycle: (Deprecated) Automatically runs a rm -rf /thevolume/* command on the volume^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
  • Delete: Deletes both the PV object and the associated backend storage asset (e.g., the cloud disk)^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Sources

^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]