Skip to content

7.03 Container Storage Interface (CSI)

Abstract

Container Storage Interface (CSI) is a standard that allows Kubernetes and other container orchestrators to work with different storage systems through plugins.

CSI separates Kubernetes from vendor-specific storage code, making storage integration cleaner, extensible, and production-ready.

Why CSI Was Introduced

Earlier, Kubernetes had storage logic tightly coupled with in-tree volume plugins.

As more storage vendors appeared, maintaining storage code inside Kubernetes became difficult.

CSI solves this by allowing storage vendors to build their own drivers without modifying Kubernetes core code.

Note

CSI is not Kubernetes-specific. It is a universal standard that can be used by multiple container orchestration platforms.

Similar Interfaces in Kubernetes

Kubernetes uses standard interfaces to support pluggable systems.

Interface Purpose Examples
CRI Container runtime integration containerd, CRI-O
CNI Network plugin integration Calico, Flannel, Cilium
CSI Storage plugin integration EBS, Portworx, GlusterFS

Tip

Think of CSI as the storage equivalent of CNI for networking and CRI for container runtimes.

What CSI Does

CSI defines how Kubernetes communicates with external storage systems.

It allows Kubernetes to:

  • provision volumes
  • delete volumes
  • attach volumes to nodes
  • detach volumes from nodes
  • mount volumes into pods
  • expand volumes
  • snapshot volumes, if supported

CSI Architecture

Typical CSI flow:

Kubernetes
    ↓
CSI Interface
    ↓
CSI Driver
    ↓
Storage Backend

Storage backends can include:

  • Amazon EBS
  • Azure Managed Disk
  • Google Persistent Disk
  • Portworx
  • Dell EMC
  • GlusterFS
  • NetApp
  • Pure Storage

Success

Storage vendors can build CSI drivers independently and make their storage work with Kubernetes.

CSI Responsibilities

CSI defines a set of Remote Procedure Calls (RPCs).

Kubernetes calls these RPCs, and the storage driver must implement them.

RPC Purpose
CreateVolume Provision a new volume
DeleteVolume Delete an existing volume
ControllerPublishVolume Attach volume to a node
ControllerUnpublishVolume Detach volume from a node
NodeStageVolume Prepare volume on node
NodePublishVolume Mount volume into pod
NodeUnpublishVolume Unmount volume from pod

Example CSI Workflow

When a pod requires a persistent volume:

  1. User creates a PVC
  2. Kubernetes calls CSI driver
  3. CSI driver provisions storage
  4. Volume is attached to the worker node
  5. Volume is mounted into the pod
  6. Application writes data to the volume
Pod
 ↓
PVC
 ↓
Kubernetes
 ↓
CSI Driver
 ↓
Storage Provider

Example

If a pod requests storage from Amazon EBS, Kubernetes calls the EBS CSI driver, and the driver provisions an EBS volume.

CSI vs Docker Volume Drivers

Feature Docker Volume Driver CSI
Scope Docker containers Kubernetes and orchestrators
Standard Docker-specific Open container storage standard
Used by Kubernetes No longer preferred Yes
Vendor integration Docker plugin CSI driver
Production Kubernetes Limited Recommended

Warning

For Kubernetes production storage, use CSI drivers, not Docker volume drivers.

Common CSI Drivers

Storage Provider CSI Driver
AWS Amazon EBS CSI Driver
Azure Azure Disk CSI Driver
Google Cloud GCE Persistent Disk CSI Driver
Portworx Portworx CSI Driver
Dell EMC Dell CSI Drivers
GlusterFS GlusterFS CSI Driver
NetApp Trident CSI Driver

Production Best Practices

Recommended

  • Use official CSI drivers from cloud or storage vendors
  • Use dynamic provisioning with StorageClasses
  • Enable volume snapshots if needed
  • Monitor storage performance and capacity
  • Use encryption for sensitive workloads
  • Use backup and disaster recovery policies
  • Test volume attach, detach, resize, and restore workflows

StorageClass with CSI

A StorageClass defines how Kubernetes should provision storage.

Example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ebs
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Tip

In production, WaitForFirstConsumer helps Kubernetes provision storage in the correct availability zone.

Do's

  • Use CSI-supported storage drivers
  • Use StorageClasses for dynamic provisioning
  • Use Retain reclaim policy for critical data
  • Enable encryption where supported
  • Monitor storage latency and capacity
  • Validate backup and restore procedures

Don'ts

  • Don't use unsupported or outdated storage plugins
  • Don't rely on local node storage for critical workloads
  • Don't ignore volume reclaim policies
  • Don't skip testing failover scenarios
  • Don't grant excessive permissions to CSI components

Danger

Misconfigured storage can cause data loss, pod scheduling failures, or production downtime.

CSI Security Considerations

CSI drivers often need permissions to create, attach, and delete volumes.

Production security checklist:

  • Use least-privilege RBAC
  • Protect cloud credentials
  • Enable encryption at rest
  • Restrict who can create StorageClasses
  • Audit volume provisioning events

Warning

A compromised CSI driver or overly permissive CSI role can impact storage across the cluster.

Summary

Quote

  • CSI is the standard interface for container storage
  • Kubernetes uses CSI drivers to communicate with storage systems
  • CSI supports dynamic provisioning, attach, mount, delete, and snapshots
  • Storage vendors maintain their own CSI drivers
  • Production Kubernetes storage should use trusted CSI drivers