Skip to main content
The Container Storage Interface (CSI) standardizes how container orchestrators (like Kubernetes) interact with external storage systems. CSI decouples storage plugins from the core orchestrator code so vendors can write a single driver that works across multiple platforms. Originally, Kubernetes embedded Docker-specific runtime logic in the kubelet. As alternative runtimes such as rkt, containerd, and CRI-O became widely used, Kubernetes introduced the Container Runtime Interface (CRI) to provide a stable, pluggable runtime API.
A presentation slide titled "Container Runtime Interface" showing the Kubernetes logo in a large rounded box on the right and three runtime logos (rkt, containerd, cri-o) on the left with a vertical "CRI" label between them. The slide has a dark blue background.
Likewise, Kubernetes adopted the Container Network Interface (CNI) to enable pluggable networking solutions. Network vendors implement the CNI spec so their plugins (Calico, Flannel, Cilium, etc.) integrate with Kubernetes without changing its core.
A diagram titled "Container Network Interface" with a Kubernetes logo in the center. On the left are container runtimes (rkt, containerd, cri-o) labeled under CRI, and along the bottom are CNI plugins like Project Calico, Flannel, and Cilium.
CSI follows the same pluggable pattern for storage. It defines a vendor-neutral RPC (gRPC) API that orchestrators call and that CSI drivers implement. Because CSI is not Kubernetes-specific, a single driver implementation can support Kubernetes, Cloud Foundry, Mesos, and other orchestrators that implement the CSI spec.
A diagram titled "Container Storage Interface" with the Kubernetes logo in the center. It shows CRI (rkt, containerd, cri-o) on the left, CSI storage drivers (Portworx, Amazon EBS, Managed Disk, Dell EMC, GlusterFS) on the right, and CNI network plugins (Calico, Flannel, Cilium) along the bottom.
Common CSI drivers available from storage vendors include Portworx, Amazon EBS, Azure Disk, Dell EMC, NetApp, Pure Storage, HPE, Nutanix, and many others. Because CSI is an open spec, vendors can expose the same capabilities across multiple orchestration platforms.
CSI is a vendor-neutral specification. Implementing the CSI API lets a storage vendor support multiple orchestrators with a single driver implementation.

​
CSI RPCs and the Volume Lifecycle

The CSI specification defines two logical groups of RPCs: controller-side (cluster-level) and node-side (per-node) calls. The orchestrator (for example, Kubernetes) invokes these RPCs to provision, attach, mount, and delete volumes. Key controller RPCs:
  • CreateVolume — provision a new backend volume
  • DeleteVolume — remove a backend volume
  • ControllerPublishVolume — controller-side attach (if the backend requires it)
  • ControllerUnpublishVolume — controller-side detach
Key node RPCs:
  • NodeStageVolume — prepare a volume on the node (optional staging mount)
  • NodePublishVolume — make the staged volume available to the container (bind-mount, mount)
  • NodeUnpublishVolume — unmount from container path
  • NodeUnstageVolume — undo staging on the node (if staged)
Table: Common CSI RPCs and their responsibilities Typical call sequence when a Pod requests a PersistentVolume (simplified):
  1. If dynamic provisioning is needed: orchestrator calls CreateVolume.
  2. If attach is required by the backend: ControllerPublishVolume.
  3. On the target node: NodeStageVolume (optional).
  4. On the target node: NodePublishVolume.
  5. When Pod terminates or PVC deleted: NodeUnpublishVolume, NodeUnstageVolume, ControllerUnpublishVolume, DeleteVolume (depending on reclaim policy).
A dark-themed diagram of the Container Storage Interface (CSI) showing orchestration platforms (Kubernetes, Cloud Foundry, Mesos) on the left, storage providers (Portworx, Amazon EBS, Dell EMC, GlusterFS, etc.) on the right, and RPC controller calls (CreateVolume, DeleteVolume, ControllerPublishVolume) in the center. Checklist items on each side list expected "SHOULD" behaviors for provisioning, deleting, and attaching volumes.

​
Interoperability and Specifications

The CSI spec defines the exact RPC signatures, expected responses, error codes, and versioning rules to ensure reliable interoperability between orchestrators and drivers. For full details—including gRPC method definitions and capabilities—see the official CSI repository: Further reading and references: That covers the high-level overview of the Container Storage Interface and how it fits into the cloud-native storage ecosystem.

Watch Video

Practice Lab