iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

CSI Drivers

By · Reviewed & last updated · Part of Kubernetes Tutorial

The Container Storage Interface (CSI) is the standard that decouples Kubernetes from the storage backend. CSI drivers run as DaemonSets + StatefulSets and expose backends — EBS, GCE PD, Azure Disk, Ceph, Longhorn, OpenEBS, Trident, Portworx — via the same Kubernetes API. Provisioner, attacher, mounter, snapshotter, and resizer are all plug-points the driver implements.

Install a CSI driver, use snapshots and cloning

EXAMPLE
# 1) Install a CSI driver (example: AWS EBS CSI)
# Easiest path: an Add-on on EKS, otherwise the manifest from the project.
kubectl apply -k 'github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=v1.30.0'

# Validate the driver is registered
kubectl get csidrivers
# NAME              ATTACHREQUIRED   PODINFOONMOUNT
# ebs.csi.aws.com   true             false

# 2) StorageClass that points at the driver
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
  encrypted: 'true'
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

---
# 3) A PVC + Pod using the driver
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: db-data, namespace: shop }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: gp3
  resources: { requests: { storage: 50Gi } }

---
# 4) CSI Snapshotter — point-in-time snapshots
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata: { name: ebs-snap-class }
driver: ebs.csi.aws.com
deletionPolicy: Retain
parameters: { tagSpecification_1: 'project=shop' }

---
# Create a snapshot (point-in-time copy of db-data)
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata: { name: db-data-2026-06-11, namespace: shop }
spec:
  volumeSnapshotClassName: ebs-snap-class
  source: { persistentVolumeClaimName: db-data }

# Watch for the snapshot to become ReadyToUse
kubectl -n shop get volumesnapshot db-data-2026-06-11 -w

---
# 5) Restore a PVC FROM a snapshot — fast forking for QA / migration
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: db-data-qa, namespace: shop }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: gp3
  resources: { requests: { storage: 50Gi } }
  dataSource:
    name: db-data-2026-06-11
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

---
# 6) Clone — same shape but from a PVC, not a snapshot (driver must support cloning)
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: db-data-clone, namespace: shop }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: gp3
  resources: { requests: { storage: 50Gi } }
  dataSource:
    name: db-data
    kind: PersistentVolumeClaim

# 7) Online expansion — the CSI resizer grows the volume + filesystem live
kubectl -n shop patch pvc db-data --type merge \
  -p '{"spec":{"resources":{"requests":{"storage":"80Gi"}}}}'

# 8) Inspect the volume from inside the pod
kubectl -n shop exec -it pg-0 -- df -h /var/lib/postgresql/data

Why it matters

CSI snapshots + dataSource cloning are the unlock for QA / staging workflows: copy production data state into a fresh PVC in seconds, then run schema migrations or load tests against it without risking the real volume. Snapshot retention plus a sensible deletionPolicy keeps the bill in check.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# Container Storage Interface — pluggable drivers for every cloud / on-prem storage.
Try it Yourself »

Discussion

Loading…