Skip to content

Persistent Volumes

Kubernetes provides persistent storage solutions through Persistent Volumes (PVs) and Persistent Volume Claims (PVCs), enabling stateful applications to retain data across pod restarts and node failures. This section explains how to configure PVs and PVCs, including dynamic provisioning via StorageClasses.

Persistent Volumes (PVs)

A Persistent Volume is a piece of storage in your cluster, provisioned by an administrator or dynamically via a StorageClass. It is a resource in the cluster, independent of any single pod. PVs define the storage capacity, access modes, and lifecycle policies.

Key Concepts

  • Access Modes: Define how the PV can be accessed by pods. Common modes include:
  • ReadWriteOnce (RWO): Read/write by a single node.
  • ReadOnlyMany (ROX): Read-only by multiple nodes.
  • ReadWriteMany (RWX): Read/write by multiple nodes (rare, requires backend support).
  • Reclaim Policy: Determines what happens to a PV when it is no longer needed. Options include Retain, Delete, or Recycle.

Example: Static PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - RWO
  hostPath:
    path: /mnt/data
  persistentVolumeReclaimPolicy: Retain

Persistent Volume Claims (PVCs)

A Persistent Volume Claim is a request for storage by a user. PVCs bind to available PVs, ensuring the application gets the storage it needs. Kubernetes automatically matches PVCs to PVs based on capacity and access mode.

Key Concepts

  • Binding: A PVC is bound to a PV when the PV meets the PVC's requirements (capacity, access mode).
  • Status: A PVC can be in states like Bound, Pending, or Lost.

Example: PVC Request

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - RWO
  resources:
    requests:
      storage: 5Gi

Dynamic Provisioning with StorageClasses

StorageClasses enable dynamic provisioning, where a PVC automatically creates a PV when no matching static PV exists. StorageClasses define parameters like the provisioner (e.g., example.com/provisioner) and reclaim policy.

Example: StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: example.com/provisioner
parameters:
  type: ssd
reclaimPolicy: Delete

Example: PVC Using StorageClass

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - RWO
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

When this PVC is created, Kubernetes dynamically provisions a PV using the standard StorageClass.

Access Modes and Reclaim Policies

Access Mode Use Case Notes
RWO Single-node applications Most common for databases
ROX Read-only multi-node access Suitable for caching layers
RWX Multi-node applications Requires distributed filesystems

Reclaim Policies: - Retain: Manually delete PV data when PVC is deleted. - Delete: Automatically remove the PV and its data. - Recycle: (Deprecated) Reformat and re-publish the PV.

Key takeaways

  • PVs represent storage resources, while PVCs request and bind to them.
  • StorageClasses enable dynamic provisioning, allowing PVCs to auto-create PVs.
  • Access modes and reclaim policies define how storage is shared and cleaned up.
  • Always align PVC requirements with available PVs or StorageClass capabilities to avoid binding failures.