What is the Container Storage Interface (CSI) in Kubernetes, and why were storage drivers moved out of the Kubernetes core codebase onto it?

## The problem CSI solves A pod that needs durable storage requires something to call the storage system's API - EBS, Ceph, a NetApp filer, a vSphere datastore - to carve out a disk, attach it to the right machine, format it and mount it into the container. Originally that code lived **in-tree**: in the Kubernetes source repository, compiled into the core binaries. That had real costs. Vendors could only ship a driver fix on the Kubernetes release train. Kubernetes maintainers had to review storage code for hardware they could not test. Every cloud SDK a driver needed became a dependency of the core binaries, widening the attack surface of components that run as root on every node. ## What CSI actually is CSI is a specification, not a Kubernetes component. It defines gRPC services a storage plugin implements: - **Identity** - who am I, what capabilities do I have, am I healthy. - **Controller** - cluster-wide operations against the storage API: `CreateVolume`, `DeleteVolume`, `ControllerPublishVolume` (attach to a node), `ControllerUnpublishVolume`, `CreateSnapshot`, `ControllerExpandVolume`. - **Node** - machine-local operations: `NodeStageVolume` (format and mount once per node to a staging path), `NodePublishVolume` (bind-mount into the pod's directory), and the unpublish/unstage counterparts. Because the contract is orchestrator-agnostic, one driver binary can serve Kubernetes, Nomad and others. ## How a driver shows up in a cluster A CSI driver installation typically creates: - a **controller Deployment** (often 1-2 replicas with leader election) containing the vendor's controller plugin plus Kubernetes-maintained sidecar containers that translate Kubernetes objects into CSI calls; - a **node DaemonSet** on every node containing the node plugin plus the `node-driver-registrar` sidecar that tells kubelet where the driver's UNIX socket is; - a `CSIDriver` object (cluster-scoped) declaring capabilities such as whether the driver needs an attach step, whether it supports fsGroup, and pod-info-on-mount; - one or more `StorageClass` objects whose `provisioner` field is the driver name; - RBAC and, in many drivers, a Secret holding cloud credentials. You can see the installed drivers with `kubectl get csidrivers`, and per-node driver state with `kubectl get csinodes` (which also records how many volumes a node can attach). ## What did not change The application-facing API is untouched. A workload still asks for storage with a PersistentVolumeClaim; a PersistentVolume object still represents the real disk; a StorageClass still selects the backend and parameters. CSI changes *who executes* the request, not *how you request it*. That is why moving a cluster from an in-tree plugin to the equivalent CSI driver can be transparent to manifests. ## Migration off in-tree drivers Kubernetes has removed the in-tree cloud volume plugins. A translation layer (CSI migration) rewrote in-tree volume specs such as `kubernetes.io/aws-ebs` into their CSI equivalent (`ebs.csi.aws.com`) so existing PersistentVolumes kept working, while the CSI driver did the real work. That translation went stable for the major clouds and the in-tree code was then deleted over subsequent releases. The practical rule for operators: the matching CSI driver must be installed *before* upgrading past the release that removes the in-tree plugin, or volumes stop attaching. ## Why interviewers ask this It separates candidates who know only `kubectl apply -f pvc.yaml` from those who know that storage in Kubernetes is an extension point with its own control loops, its own failure modes, and its own upgrade lifecycle.