CSI Drivers

Why CSI Replaced In-Tree Plugins

Originally each cloud's storage logic lived inside Kubernetes: AWS EBS, GCE PD, and Azure Disk code shipped in the API server and controller-manager, so every new array meant patching and releasing Kubernetes itself.

CSI (Container Storage Interface) draws a hard line: Kubernetes exposes generic lifecycle verbs — provision, attach, mount, snapshot — and out-of-tree driver binaries implement them for each backend. Drivers run as controller pods and node agents, registered through a CSIDriver object.

The payoff: vendors ship on their own cadence, clusters adopt drivers without upgrading Kubernetes, and legacy in-tree plugins now delegate to CSI through migration features.

Anatomy of a Driver Install

A typical installation creates three pieces:

• controller Deployment — external-provisioner, external-attacher, and external-snapshotter sidecars talking to the API server over the driver's gRPC socket.
• node DaemonSet — the driver's node plugin performing mount/unmount alongside kubelet's CSI client.
• CSIDriver object — declares the driver name and flags such as attachRequired, podInfoOnMount, and fsGroupPolicy.

kubectl get csidrivers
kubectl get csinodes
kubectl -n kube-system get pods -l app=csi-ebs-controller

Claims reach the driver through StorageClass provisioner: names; snapshots appear as VolumeSnapshot and VolumeSnapshotClass objects handled by the snapshotter sidecar.

Pitfalls and Interview Angles

Pitfall 1 — assuming feature parity. Snapshots, online expansion, RWX, and topology support vary per driver and backend. Verify the specific driver's documented capabilities before designing around them.

Pitfall 2 — controller blind spots. The provisioner is just a Deployment; if it crashes, new claims stay Pending while nodes and API look perfectly healthy. Watch those pods alongside PVC state.

Interview-ready: explain the CSI boundary — Kubernetes owns generic lifecycle, driver owns backend specifics — name three sidecars (provisioner, attacher, snapshotter), and answer "my PVC is Pending" by checking StorageClass provisioner → CSIDriver existence → controller pod health → driver logs.