Free — no signup required

The Plumbing: Container Storage Interface (CSI)

2 min read

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:

  1. Kubernetes calls the CSI Controller's CreateVolume RPC → cloud API creates the disk
  2. Kubernetes calls ControllerPublishVolume → disk is attached to the target node
  3. The CSI Node plugin calls NodeStageVolume → disk is formatted and staged to a global mount point on the node
  4. 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).

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free