What is a CSI driver?
A CSI driver is a plugin that implements the Container Storage Interface, a standard set of gRPC calls between a container orchestrator and a storage system. Kubernetes calls the driver to create a volume, attach it to a node, mount it into a pod, grow it and delete it. The storage vendor writes the driver once, outside the Kubernetes code.
Think of a universal power adapter. The wall socket and the laptop never need to know about each other, because the adapter speaks to both. Kubernetes is the laptop, the storage system is the socket, and the CSI driver is the adapter in between.
Why does Kubernetes use CSI drivers?
Early volume plugins were “in-tree”: compiled and shipped inside the core Kubernetes binaries. Adding or fixing a storage system meant changing Kubernetes itself and waiting for its next release.
CSI moved that code out of tree. Vendors ship and update drivers on their own schedule, and older in-tree plugins are redirected to their CSI replacements. FlexVolume, an earlier out-of-tree option, is deprecated in favour of CSI.
How does a CSI driver work?
A driver has two parts, plus a few helper containers that watch the Kubernetes API.
Controller part
The controller part handles volume-level work that does not need to run on a specific node. It creates and deletes volumes, attaches them to nodes and, where the driver supports it, takes snapshots and expands volumes.
Node part
The node part runs on every worker node. The kubelet calls it to stage the volume on the node, mount it into the pod’s path and grow the filesystem after a resize.
From claim to mounted volume
A typical dynamic provisioning flow looks like this:
- You create a PersistentVolumeClaim that names a StorageClass.
- The StorageClass’s provisioner field matches the driver’s name, so the provisioner sidecar calls the driver to create a volume.
- Kubernetes creates a PersistentVolume for it and binds it to the claim.
- When a pod using the claim is scheduled, the volume is attached to that node and mounted into the pod.
How enum handles CSI drivers
enum Block Storage attaches to enum Kubernetes Engine workloads through a CSI driver, with dynamic provisioning and online resizing. Create a PersistentVolumeClaim and the driver provisions an NVMe volume, replicated synchronously three times across failure domains. enum does not document volume snapshots, so back up with your database’s own tools or Velero file-system backup.
FAQ
Do I need to install a CSI driver myself? On a managed Kubernetes platform the provider usually installs the driver and a StorageClass for you. On a self-run cluster you install it yourself, because core Kubernetes does not ship storage drivers.
Can one cluster run several CSI drivers? Yes. Each driver registers its own name, and each StorageClass points at one of them through its provisioner field. A claim picks a driver by naming the matching StorageClass.
Does every CSI driver support snapshots and resizing? No. Snapshots and volume expansion are optional capabilities that each driver advertises to Kubernetes. Check what your driver supports before you plan backups or growth around them, and test a restore before you rely on it.