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

Background

In Kubernetes the smallest management unit is a Pod, and data inside a Pod is temporary; when a Pod restarts the data is lost. While stateless services are ideal, many applications require state, so persistent storage mechanisms are needed in a Kubernetes cluster.

With the rise of cloud computing, Cloud Native, and micro‑services, Kubernetes has become an OS‑level standard that must be extensible and open to support various cloud providers. Its storage subsystem has evolved similarly, moving toward open and scalable solutions.

Main Concepts and Usage

Kubernetes storage includes Volume, PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass.

Volume

A Volume abstracts underlying storage and can be backed by many providers such as awsElasticBlockStore, azureDisk, azureFile, cephfs, cinder, configMap, …

Example:

<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
    # This AWS EBS volume must already exist.
    awsElasticBlockStore:
      volumeID: <volume-id>
      fsType: ext4
</code>

Persistent Volumes

PV is a concrete storage unit provided by cluster administrators, while PVC is a logical request for storage that consumes a PV. This abstraction lets developers request size and I/O requirements without dealing with storage details.

Example:

<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 create PVCs, and the StorageClass automatically creates the appropriate PV.

<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 difficult and affecting stability.

Hard to patch or add new storage types without a new Kubernetes release.

Third‑party code in the core reduces security and stability.

FlexVolume

Since Kubernetes 1.2, out‑of‑tree FlexVolume allows users to develop their own drivers, but it lacks features such as dynamic provisioning and snapshots, and communication is done via binary calls, which complicates state sharing.

CSI

Container Storage Interface (CSI) is the modern plugin model using gRPC, supporting dynamic provisioning, expansion, snapshots, and smoother migration from in‑tree plugins.

Conclusion

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

Using a command like the following maps a host directory into a Pod, enabling containers to store data persistently.

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

Understanding how storage is mounted to nodes is essential for mastering the Kubernetes storage system.