liveBook · Manning

Persistent volume

As explained in Acing the Certified Kubernetes Administrator Exam, Second Edition

A persistent volume is a Kubernetes API object representing storage provisioned for durable workload data.

A persistent volume (PV) is a cluster-scoped Kubernetes object for storage that outlives an individual pod. Keep data in a PV when replacing or deleting a pod must not erase it. The storage can be backed by a host or an external provider; the PV remains separate from the workload that mounts it. section 7.1

To make that storage available to an application:

  • Create a PV with the required capacity, storage backing, volume mode, access mode, and reclaim policy. Filesystem is the default volume mode; Block is the alternative. section 7.1 section 7.5
  • Create a persistent volume claim (PVC) to reserve storage, then mount the claim in a pod or Deployment. A claim can bind to a larger PV rather than requiring an exact capacity match. section 7.1 section 7.2
  • Alternatively, choose a storage class in the PVC to provision a PV dynamically. Inspect the class with `kubectl get sc standard -o yaml`; automatically provisioned PVs inherit settings such as its reclaim policy and volume binding mode. section 7.3.1 section 7.5

Host-backed storage task

Create a 100Mi hostPath PV from `/mnt/data` on worker node `node01`. Claim 90Mi, then mount the claim in a Deployment at `/usr/share/nginx/html`. Check `kubectl get pv` and `kubectl get pvc`: the claim can show `Bound` to the 100Mi PV. Check `kubectl get deploy`, `kubectl get po`, and `kubectl describe po` to verify the workload and mount. section 7.1

root@kind-control-plane:/# kubectl get pvc
NAME          STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   
 AGE
claim-02833   Bound    vol02833   100Mi      RWO            manual         
 4m
root@kind-control-plane:/# kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   
 CLAIM                 STORAGECLASS
vol02833   100Mi      RWO            Retain           Bound    
 default/claim-02833   manual

The command output shows a 100Mi PV bound to its claim, including access mode, reclaim policy, and storage class. section 7.1

Watch the PV phase while troubleshooting: an Available PV can be claimed; a Bound PV is already reserved. A claim protecting storage used by a pod can leave attempted PV or PVC deletions in Terminating until the workload is removed. Access modes govern which nodes can use the volume and with what read/write permissions; the reclaim policy governs what happens when the storage is released. Choose these settings from the workload’s requirements, not just its requested capacity. section 7.2 section 7.5

How Acing the Certified Kubernetes Administrator Exam, Second Edition covers it

How deep it goes
Works through PV creation, claim binding, mounting, and status checks, with configuration guidance for modes, access, and reclaim policies.
Examples
Uses a 100Mi hostPath PV, a 90Mi claim, a Deployment mount, and `kubectl` output showing the bound resources.
What it assumes
Assumes access to a Kubernetes cluster and builds on the distinction between short-lived pods and durable application data.
What you can do after
Build it from scratch: create a PV and PVC, mount the claim in a workload, and verify binding and the mount with `kubectl`.
How it connects
Connects persistent volume claims, storage classes, access modes, reclaim policies, volume modes, pods, and Deployments.

Also explained in

Compare how 7 books explain persistent volume →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Acing the Certified Kubernetes Administrator Exam, Second Edition. The section links point to the parts of the book it draws on.