Why CSI Exists
Originally, the code to talk to every storage provider — AWS EBS, Google Persistent Disk, Azure Disk, NetApp, Ceph, and dozens more — was compiled directly into the Kubernetes binary. Adding a new storage backend required a code change to Kubernetes itself, a full release cycle, and waiting for cluster operators to upgrade. This was unsustainable.
The CSI Standard
The Container Storage Interface (CSI) is an industry-standard API specification that decouples storage providers from the Kubernetes core. Storage vendors write their own CSI drivers — separate programs that run in the cluster — and Kubernetes communicates with them through a well-defined gRPC interface. Adding a new storage backend now means installing a driver, not patching Kubernetes.
A CSI driver typically deploys two components:
1. Controller Plugin — Runs as a Deployment (usually with one or a few replicas). It handles cluster-level operations: calling the cloud provider API to create/delete/snapshot volumes, and attaching/detaching volumes from nodes. It doesn't need to run on any specific node.
2. Node Plugin — Runs as a DaemonSet on every node. It handles node-level operations: formatting the attached block device with a filesystem (e.g., ext4, xfs), and mounting/unmounting the volume into the Pod's filesystem namespace. It must run on the specific node where the Pod is scheduled.
# Check installed CSI drivers in your cluster
kubectl get csidrivers
# Example output:
NAME ATTACHREQUIRED PODINFOONMOUNT STORAGECAPACITY ...
ebs.csi.aws.com true false false ...
efs.csi.aws.com false false false ...
The Volume Lifecycle Through CSI
When a Pod requests a volume, the full flow is:
- Kubernetes calls the CSI Controller's
CreateVolumeRPC → cloud API creates the disk - Kubernetes calls
ControllerPublishVolume→ disk is attached to the target node - The CSI Node plugin calls
NodeStageVolume→ disk is formatted and staged to a global mount point on the node - The CSI Node plugin calls
NodePublishVolume→ volume is bind-mounted into the Pod's container filesystem
This four-step process ensures clean separation between provisioning (cloud API), attachment (hypervisor/OS), and mounting (container runtime).