Container Storage Interface (CSI): The Universal Adapter for K8s Storage

WHY IT EXISTS Before CSI, storage driver code was part of the main Kubernetes codebase, known as being 'in-tree'. Adding a new storage provider or fixing a bug required a full Kubernetes release, a slow and cumbersome process. CSI was created to move this logic 'out-of-tree', defining a standard interface so storage vendors could develop, deploy, and update their drivers independently.

THE MENTAL MODEL Think of CSI as a universal power adapter for storage. Instead of Kubernetes needing a specific plug for every storage system (AWS EBS, GCE PD, NetApp, etc.), it has one standard socket: the CSI API. Storage vendors provide a 'plug'—a CSI driver—that fits this socket and translates standard requests like 'create volume' or 'attach volume' into the specific commands for their proprietary system.

HOW IT WORKS CSI defines a set of gRPC API calls that a storage driver must implement. The architecture is split into two main parts. First, controller plugins, which handle operations that are not node-specific, like provisioning and attaching volumes. These are typically deployed as a Deployment or StatefulSet and use sidecar containers (like external-provisioner and external-attacher) to watch the Kubernetes API for objects like PersistentVolumeClaims. Second, node plugins, which run on every node as a DaemonSet. The kubelet on each node communicates directly with the node plugin over a Unix Domain Socket to perform operations like staging and mounting volumes for pods scheduled on that node.

WHEN TO USE IT Use CSI whenever you need persistent, non-ephemeral storage for your containerized workloads in Kubernetes. It is the current standard for connecting stateful applications to any block or file storage system, whether from a cloud provider or an on-premise SAN. It supports features like snapshots, cloning, and resizing.

WHEN NOT TO USE IT CSI is not necessary for temporary, ephemeral storage that is tied to a pod's lifecycle. For scratch space, Kubernetes's built-in emptyDir volume type is simpler and more appropriate. CSI is designed for managing the lifecycle of persistent storage that needs to outlive individual pods.

ONE CANONICAL EXAMPLE A developer creates a PersistentVolumeClaim (PVC) manifest asking for 50GiB of 'fast' storage. The Kubernetes API server accepts this. A CSI driver's external-provisioner sidecar sees the new PVC. It calls the CreateVolume function on its own driver's controller component. The driver, which is specific to a cloud provider like AWS, then makes an API call to AWS to provision a 50GiB gp3 EBS volume. Once the volume exists, the driver reports back to Kubernetes, which creates a corresponding PersistentVolume (PV) object. Now, a pod can claim that PVC and have the EBS volume mounted into its filesystem.