liveBook · Manning

Persistent volume claim

As explained in Kubernetes for Developers

A PersistentVolumeClaim is a Kubernetes storage request that allows a workload to obtain persistent storage with specified capacity and access properties.

A database needs its data to outlast a Pod. Rather than naming a cloud disk in the Pod, create a PersistentVolumeClaim (PVC) that requests storage in platform-independent terms. The Pod references the claim; Kubernetes finds or creates a PersistentVolume (PV) representing suitable storage and binds the two. This lets the workload run wherever persistent storage is supported. section 9.1.2

Figure 9.2 A Pod that references a PersistentVolumeClaim that gets bound to a PersistentVolume, which references a disk
09-02

Follow the references from Pod to claim, from bound claim to PersistentVolume, and from PersistentVolume to disk. section 9.1.2

A claim specifies how much storage the workload needs and how it must be accessed:

  • Request a capacity, such as 2 GiB for a MariaDB database. section 9.1.2
  • Choose an access mode. ReadWriteOnce suits the single-Pod database example; ReadOnlyMany permits sharing existing data for reading, while ReadWriteMany permits multiple Pods to read and write where supported. section 9.1.2
  • Mount the named claim in the container. For MariaDB, the mount path is /var/lib/mysql. section 9.1.2

Check that a database claim is bound

Create the MariaDB Pod and PVC, then inspect the claim with kubectl get -o yaml pvc/mariadb-pv-claim. A successful example shows phase: Bound, capacity: 2Gi, and a volumeName identifying its PV. Inspecting that PV shows a claimRef pointing back to the PVC. The Pod uses the claim name, not the cloud disk identifier. section 9.1.2

A StorageClass determines what kind of storage is dynamically provisioned and how it is handled later. Check its reclaim policy before storing important data: with Delete, deleting a bound PVC also deletes its PV and backing disk; with Retain, the disk remains available for deliberate recovery, but unwanted disks must be removed manually. Deleting a StatefulSet alone does not delete its PVCs. section 9.1.3 section 9.3

For one database Pod, a Deployment can reference a standalone PVC and recreate a terminated Pod. Do not extend that arrangement to replicas that each need their own disk: they would reference the same claim. A StatefulSet instead uses volumeClaimTemplates to create a distinct PVC for each Pod, tied to that Pod’s stable identifier. section 9.1.4 section 9.2

If a disk was retained after its Kubernetes objects were removed, recovery involves recreating and relinking the PV and PVC before bringing the workload back. Retain must be in place before deleting claims whose data matters. section 9.3

How Kubernetes for Developers covers it

How deep it goes
Works through claim fields, PV binding, inspection, reclaim policies, and recovery rather than stopping at the API definition.
Examples
Uses a MariaDB data mount, bound-object kubectl output, StatefulSet claim templates, and a Redis disk-recovery exercise.
What it assumes
Introduces claims through a database Pod’s storage problem and explains the PV relationship without assuming prior Kubernetes storage knowledge.
What you can do after
Operate/configure it by requesting storage, checking PV binding, choosing retention, and using per-Pod claims for StatefulSet replicas.
How it connects
Connects PersistentVolumeClaims to PersistentVolumes, Pods, StorageClasses, Deployments, and StatefulSets.

Also explained in

Compare how 9 books explain persistent volume claim →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes for Developers. The section links point to the parts of the book it draws on.