Dynamic Storage Provisioning: PersistentVolumes, PVCs, StorageClasses, and CSI gRPC

A database administrator needs to provision a 500 Gigabyte high-performance SSD volume for a new PostgreSQL database cluster.

In early Kubernetes versions, this required a 4-step manual administrative ticket workflow:

An infrastructure engineer manually logged into the cloud console to create an AWS EBS or GCP Persistent Disk volume.
The engineer formatted the raw block device with an ext4 filesystem.
The engineer wrote a static PersistentVolume (PV) YAML file with hardcoded volume IDs.
The database administrator created a PersistentVolumeClaim (PVC) to bind to the manually created volume.

If the application scaled to 50 database instances, the manual workflow collapsed under administrative overhead.

With modern Dynamic Storage Provisioning, a developer submits a single declarative PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-storage
spec:
  accessModes: [ "ReadWriteOnce" ]
  storageClassName: "fast-nvme"
  resources:
    requests:
      storage: 500Gi

Within 12 seconds, the cluster automatically communicates with cloud storage APIs, provisions a 500GB NVMe block disk, formats the filesystem, binds the volume, and mounts it into the running database Pod.

How does Kubernetes decouple storage consumption from physical cloud storage provisioning using StorageClasses, PersistentVolumeClaims (PVCs), and Container Storage Interface (CSI) gRPC calls?

1. The Storage Abstraction Layer

Kubernetes separates storage infrastructure management into a 3-tier abstraction model:

+-------------------------------------------------------------------+
| 1. StorageClass (Storage Profile Definition)                       |
|    - Provisioner: ebs.csi.aws.com                                 |
|    - Parameters: type=gp3, iops=3000                              |
|    - ReclaimPolicy: Delete                                        |
+-------------------------------------------------------------------+
                                  ^
                                  |  Triggers Dynamic Provisioning
+---------------------------------+---------------------------------+
| 2. PersistentVolumeClaim (PVC)  | 3. PersistentVolume (PV)        |
|    User request ticket:         |    Actual storage resource      |
|    "Give me 500GB fast-nvme"    |    Bound 1-to-1 to the PVC      |
+---------------------------------+---------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| PHYSICAL STORAGE BACKEND (AWS EBS / GCP PD / Ceph / Longhorn)     |
+-------------------------------------------------------------------+

StorageClass: Defined by Cluster Administrators. Specifies how storage of a certain type should be dynamically provisioned (provisioner plugin, performance tier, disk encryption keys).
PersistentVolumeClaim (PVC): Defined by Developers. A request ticket specifying storage size (500Gi), access mode (ReadWriteOnce), and desired StorageClass.
PersistentVolume (PV): Created automatically by the storage provisioner. Represents the actual storage volume bound to a specific PVC.

2. Storage Access Modes

When requesting a PVC, developers specify an Access Mode defining how many host nodes can mount the volume concurrently:

ReadWriteOnce (RWO)                       ReadWriteMany (RWX)
Single Node Mount Only                    Multiple Nodes Mount Concurrently

+---------------+                         +---------------+  +---------------+
| Node 1 (Pod A)|                         | Node 1 (Pod A)|  | Node 2 (Pod B)|
+---------------+                         +---------------+  +---------------+
        |                                         \                  /
        v                                          v                v
[ Block Disk Volume ]                     [ Network Shared Storage (NFS) ]

Access Mode Definitions:

ReadWriteOnce (RWO): Volume can be mounted as read-write by pods running on a single worker node. (Standard cloud block storage like AWS EBS or GCP PD).
ReadOnlyMany (ROX): Volume can be mounted as read-only by pods running across multiple worker nodes.
ReadWriteMany (RWX): Volume can be mounted as read-write by pods running across multiple worker nodes simultaneously. (Requires network filesystems like NFS, AWS EFS, or Ceph).
ReadWriteOncePod (RWOP): Volume can be mounted as read-write by one single Pod across the entire cluster.

3. The Container Storage Interface (CSI)

Similar to how CRI standardizes container runtimes, the Container Storage Interface (CSI) standardizes third-party storage driver integration.

Storage vendors (AWS, NetApp, Portworx, Pure Storage) publish CSI drivers executing as gRPC services inside the cluster.

+-------------------------------------------------------------------+
| KUBERNETES CONTROL PLANE / KUBELET                                |
+-------------------------------------------------------------------+
                                  |
            gRPC API over UNIX Socket (/var/lib/kubelet/plugins/...)
                                  |
            +---------------------+---------------------+
            |                                           |
            v                                           v
+-----------------------+                   +-----------------------+
| 1. Controller Plugin  |                   | 2. Node Plugin        |
|    - CreateVolume     |                   |    - NodeStageVolume  |
|    - DeleteVolume     |                   |    - NodePublishVolume|
|    - ControllerPublish|                   |    - NodeUnpublishVol |
+-----------------------+                   +-----------------------+

Step-by-Step Trace: Mounting a Volume to a Pod

When a Pod requesting a PVC is scheduled onto Worker Node 02, the storage system executes a 4-step sequence:

1. Provisioning (CSI Controller Plugin):
   Kubelet detects PVC -> Calls CSI `CreateVolume()` gRPC.
   AWS CSI Driver calls AWS EC2 API to create a 500GB gp3 EBS volume.
        |
        v
2. Attaching / Publishing (CSI Controller Plugin):
   Kubelet calls CSI `ControllerPublishVolume()` gRPC.
   AWS CSI Driver attaches the EBS volume to Worker Node 02's EC2 instance (`/dev/xvdf`).
        |
        v
3. Staging (CSI Node Plugin on Node 02):
   Kubelet calls CSI `NodeStageVolume()` gRPC on Node 02.
   CSI Node Plugin formats `/dev/xvdf` with ext4/xfs and mounts it to a global staging directory (`/var/lib/kubelet/plugins/kubernetes.io/csi/...`).
        |
        v
4. Mounting / Publishing (CSI Node Plugin on Node 02):
   Kubelet calls CSI `NodePublishVolume()` gRPC on Node 02.
   CSI Node Plugin executes a **Linux bind mount**, mounting the staged directory directly into the target Pod's container directory!

Storage Abstraction Comparison Matrix

Object / Component	Created By	Lifecycle Scope	Primary Function
`StorageClass`	Cluster Administrator	Cluster-Wide	Configures dynamic volume provisioner rules & disk tiers
`PersistentVolumeClaim` (PVC)	Application Developer	Namespace-Scoped	Storage request ticket (specifying size & access modes)
`PersistentVolume` (PV)	Storage Provisioner (CSI)	Cluster-Wide	Actual physical/cloud storage representation bound to PVC
CSI Driver	Storage Vendor (AWS/Ceph)	Cluster DaemonSet	Executes cloud API calls and node bind mounts over gRPC

Summary & Next Steps

Kubernetes CSI dynamic provisioning decouples application storage requests from cloud infrastructure details:

StorageClasses define automated volume provisioning rules and cloud disk performance tiers.
PVCs act as developer storage tickets requesting specific capacity and access modes (RWO, RWX).
PVs represent bound physical or cloud storage resources.
The Container Storage Interface (CSI) standardizes storage driver operations over gRPC (CreateVolume, ControllerPublishVolume, NodeStageVolume, NodePublishVolume).

In the next article, we examine Configuration and Secrets Management: ConfigMaps, Secrets, and Volume Mount Mechanics.

References & Further Reading

Cloud Native Computing Foundation. Custom Resources & The Operator Pattern in Kubernetes. CNCF Docs.
CNCF Operator Framework. Operator SDK User Guide & Kubebuilder Architecture. Operator SDK Docs.
Hausenblas, M., & Schimanski, S. (2019). Programming Kubernetes (Chapter 5: Custom Resource Definitions). O’Reilly Media.