Mastering Kubernetes Storage: Volumes, PVs, PVCs, and StorageClasses Explained

Background

In Kubernetes the smallest management unit is a Pod, whose data is temporary and lost on restart. While stateless services are ideal, many applications require state, so a mechanism for data persistence is needed—this is the role of Kubernetes storage.

The rise of cloud computing, cloud‑native, and micro‑service architectures has made Kubernetes the de‑facto OS‑level platform, driving an open and extensible storage ecosystem.

Main Concepts and Usage

Kubernetes storage revolves around four key objects: Volume, PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass.

Volume

A Volume abstracts underlying storage and can be backed by many providers. Common built‑in types include:

awsElasticBlockStore

azureDisk

azureFile

cephfs

cinder

configMap

…

Example of using an AWS EBS volume in a Pod:

<code>apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    awsElasticBlockStore:
      volumeID: <volume-id>
      fsType: ext4</code>

Persistent Volumes (PV) and PersistentVolumeClaims (PVC)

PV represents a physical storage unit provisioned by administrators, while PVC is a logical request for storage that consumes a PV. This abstraction shields developers from low‑level details.

Typical YAML for a PV and a matching PVC:

<code>apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    type: amazonEBS
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: vol-xxxxxxxxxxxxxxxx
    fsType: ext4
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
  labels:
    type: amazonEBS
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      type: "amazonEBS"</code>

StorageClass

StorageClass enables dynamic provisioning of PVs. Developers request a PVC without pre‑creating a PV; the StorageClass controller creates the PV automatically.

Example StorageClass definition:

<code>apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate</code>

Plugin System

In‑tree

Older in‑tree plugins are compiled into the Kubernetes binary, making bug fixes and new storage support dependent on the Kubernetes release cycle and raising security and stability concerns.

FlexVolume

Introduced in Kubernetes 1.2 as an out‑of‑tree solution, FlexVolume lets users develop custom drivers. However, it only supports basic attach/detach and mount/unmount operations and lacks features like dynamic provisioning and snapshots.

CSI (Container Storage Interface)

CSI is the modern plugin model using gRPC, offering rich features such as dynamic provisioning, snapshots, and expansion. Existing in‑tree usage is gradually migrated to CSI drivers behind the scenes.

Summary

The core of Kubernetes storage is how to mount the target storage onto Kubernetes node machines.

In practice, you can map a host directory into a Pod with a simple Docker command:

<code>docker run -d --name=nginx -v nginx-vol:/usr/share/nginx/html nginx:latest</code>

Understanding this mounting process is essential for mastering the entire Kubernetes storage stack.