liveBook · Manning

Persistent volume

As explained in Kubernetes for Developers

A persistent volume is a Kubernetes storage resource that provides data storage intended to survive container or Pod replacement.

A database Pod needs somewhere to keep its data when the Pod is replaced. A persistent volume (PV) is the Kubernetes object representing storage backed by a disk. Instead of naming a particular cloud disk in the Pod, you normally give the Pod a persistent volume claim (PVC) that requests the storage it needs. section 9.0 section 9.1.2

The Pod references the claim; the claim requests a capacity and access mode; and Kubernetes creates or finds a suitable PV and binds them. The PV represents the available storage and references the underlying disk. This keeps the Pod’s storage request separate from provider-specific disk details. 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 links from Pod to claim, from claim to bound persistent volume, and from persistent volume to disk. section 9.1.2

Choose an access mode for the claim:

  • ReadWriteOnce: read/write storage mounted to a single Pod, like a traditional hard drive. section 9.1.2
  • ReadOnlyMany: existing data shared read-only across multiple Pods. section 9.1.2
  • ReadWriteMany: file storage that multiple Pods can read and write simultaneously, when supported. section 9.1.2

Give MariaDB its own storage

A MariaDB Pod mounts a claim at /var/lib/mysql, where it keeps its data. The claim requests 2 GiB with ReadWriteOnce access. After creation, inspect the claim and PV with kubectl: their Bound status and reciprocal references show which storage the Pod will use. Unlike mounting a provider disk directly, this does not require the Pod manifest to name a disk created manually outside Kubernetes. section 9.1.1 section 9.1.2

Persistent does not mean impossible to delete. A common default reclaim policy is Delete: deleting the bound claim can also delete its disk, even though deleting a StatefulSet leaves its claims in place. For data you must recover, use a StorageClass with a Retain reclaim policy and verify the PV’s policy. A retained disk can be relinked by re-creating its PV and PVC, including in another cluster. section 9.3

How Kubernetes for Developers covers it

How deep it goes
Explains PV–PVC binding, access modes, and reclaim-policy consequences through manifests and recovery steps; does not detail storage-driver internals.
Examples
Uses a MariaDB claim mounted at /var/lib/mysql and a Redis StatefulSet whose retained disk is relinked after deletion.
What it assumes
Assumes basic Pod-manifest and kubectl familiarity while building from direct volume mounts to claims and PV binding.
What you can do after
Operate/configure it by requesting storage through a claim, checking PV binding, and setting retention before deleting claims.
How it connects
Connects persistent volumes to Pods, persistent volume claims, access modes, StorageClasses, reclaim policies, and StatefulSets.

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 Kubernetes for Developers. The section links point to the parts of the book it draws on.