What is a CSI Driver in Kubernetes? Explained Simply

If you have ever created a PersistentVolumeClaim in Kubernetes, a CSI driver was doing the heavy lifting behind the scenes. Here is what it is, why it exists, and how it works.

The Problem Before CSI

Before CSI existed, storage drivers were baked directly into the Kubernetes source code. If you wanted to use AWS EBS, the EBS logic lived inside the kubelet binary. If AWS needed to fix a bug or add a feature, they had to submit a pull request to Kubernetes, wait for it to merge, wait for a Kubernetes release, and wait for clusters to upgrade.

This was painful for everyone: storage vendors could not ship quickly, and Kubernetes had to carry hundreds of storage plugins as maintenance burden.

CSI (Container Storage Interface) was the solution. It defines a standard gRPC API that any storage vendor can implement as an independent binary. Kubernetes calls the CSI API, and the driver handles the vendor-specific logic. Storage vendors can now release their own drivers on their own schedule.

How CSI Works: Two Plugins

Every CSI driver ships as two components:

1. Controller Plugin

Runs as a Deployment (usually with 2 replicas for HA). Handles cluster-level operations:

• Provisioning a new volume (calling AWS to create an EBS disk)
• Deleting a volume when a PVC is deleted
• Creating and restoring snapshots
• Attaching a volume to a specific node

The controller plugin runs on any node and talks to the cloud or storage API.

2. Node Plugin

Runs as a DaemonSet (one pod per node). Handles node-level operations:

• Mounting the volume onto the host filesystem
• Formatting the disk (if needed)
• Unmounting the volume when the pod terminates

The node plugin must run on the same node as the pod that needs the volume, because it does filesystem operations directly on that node.

The PVC to Storage Flow

Here is what happens when you create a PVC:

PVC created
    ↓
StorageClass → identifies which CSI driver to use
    ↓
CSI Controller Plugin → calls cloud API to create the disk
    ↓
PersistentVolume (PV) → automatically created by Kubernetes
    ↓
PVC becomes Bound to the PV
    ↓
Pod is scheduled to a node
    ↓
CSI Controller → attaches the disk to that node
    ↓
CSI Node Plugin → mounts the disk into the pod's filesystem
    ↓
Pod starts and can read/write the volume

A StorageClass example that uses the AWS EBS CSI driver:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-encrypted
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
  kmsKeyId: "arn:aws:kms:us-east-1:123456789012:key/your-key-id"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true

The provisioner field is the name of the CSI driver. Kubernetes uses this to know which driver to call.

Check Which CSI Drivers Are Installed

kubectl get csidriver

Example output on an EKS cluster:

NAME              ATTACHREQUIRED   PODINFOONMOUNT   STORAGECAPACITY   TOKENREQUESTS   REQUIRESREPUBLISH   MODES        AGE
ebs.csi.aws.com   true             false            false             <unset>         false               Persistent   45d
efs.csi.aws.com   false            false            false             <unset>         false               Persistent   45d

This tells you the driver name (used in StorageClass provisioner field), whether volumes need to be attached (true for block storage like EBS, false for network filesystems like EFS), and whether the driver supports capacity tracking.

Common CSI Drivers

AWS EBS CSI Driver

Block storage for EKS. Supports gp2, gp3, io1, io2 volume types. Requires IRSA (IAM Roles for Service Accounts) to give the controller permission to create EBS volumes.

# Install via EKS add-on (recommended)
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name aws-ebs-csi-driver \
  --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKS_EBS_CSI_DriverRole

AWS EFS CSI Driver

Network filesystem. Multiple pods on different nodes can mount the same EFS filesystem simultaneously — EBS cannot do this. Use EFS for shared config files, machine learning datasets, or CMS media uploads.

Longhorn

Open-source distributed block storage that runs entirely inside your Kubernetes cluster. Good for bare metal or on-premises clusters where you do not have a cloud block storage API. Provides replication, backups to S3, and snapshots.

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace

Rook Ceph

Turns your cluster nodes' local disks into a distributed Ceph storage cluster. More complex than Longhorn but supports block, filesystem, and object storage (S3-compatible). Used in large on-premises Kubernetes deployments.

CSI Snapshots

CSI drivers that support snapshots let you create point-in-time backups of PVCs:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
spec:
  volumeSnapshotClassName: csi-aws-vsc
  source:
    persistentVolumeClaimName: my-pvc

This triggers the CSI controller to create a snapshot via the cloud API (an EBS snapshot, for example). You can then create a new PVC from the snapshot.

Key Takeaway

CSI drivers decoupled storage from Kubernetes. The driver = controller plugin (manages volumes in the cloud) + node plugin (mounts volumes on nodes). The provisioner field in your StorageClass is what connects a PVC to the right driver. When something goes wrong with a PVC mount, the CSI driver pods in kube-system are where you look first.

Dealing with a stuck PVC right now? See our CSI driver troubleshooting guide.