The Universal Adapter

In the early days, Kubernetes had storage code (AWS EBS, GCE PD) hardcoded into its core binary ("in-tree"). This was a maintenance nightmare. The Container Storage Interface (CSI) is a standard that allows any storage vendor to write a plugin for Kubernetes without modifying the core Kubernetes code ("out-of-tree").

1. Architecture: How CSI Works

A CSI Driver typically has two components:

  1. Controller Plugin (StatefulSet/Deployment): Runs on the Control Plane (or anywhere). Talks to the Cloud API to create/delete volumes.
  2. Node Plugin (DaemonSet): Runs on every Node. Responsible for formatting and mounting the volume to the Pod.

2. Interactive: CSI Workflow Visualizer

Follow the journey of a Pod request triggering a CSI Driver operation.

K8s API Server
Waiting
CSI Controller
CreateVolume
CSI Node Plugin
NodePublishVolume
Cloud Storage API (AWS/GCP)
$ System Idle.

3. The gRPC Protocol

CSI communicates using gRPC. The Kubelet (on the Node) calls these functions on the CSI Driver:

  1. NodeStageVolume: Mount the device to a global path on the node.
  2. NodePublishVolume: Bind mount the global path to the specific Pod directory.
  3. NodeUnpublishVolume: Unmount from the Pod.

4. Installing a CSI Driver

Most drivers are installed via Helm. For example, the AWS EBS CSI Driver:

helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
helm install aws-ebs-csi-driver aws-ebs-csi-driver/aws-ebs-csi-driver \
  --namespace kube-system

Once installed, you see the Pods running:

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver
# NAME                                  READY   STATUS    RESTARTS
# ebs-csi-controller-56f77c8756-abcde   6/6     Running   0        (Controller)
# ebs-csi-node-xyzwq                    3/3     Running   0        (Node Plugin)