A Container Storage Interface (CSI) driver connects Kubernetes to a particular storage technology. It lets a cluster provision storage for applications without building that technology’s support into Kubernetes itself. Examples include drivers for NFS, Azure Disks, and Google Compute Engine Persistent Disks. section 10.1.1 section 10.2.6
For persistent storage, an application pod refers to a PersistentVolumeClaim, not directly to a PersistentVolume. The claim names a StorageClass; that class identifies a provisioner and supplies its parameters. A matching PersistentVolume is then found or created and bound to the claim. The CSI driver typically has a controller that provisions volumes and a component on each node that handles the storage volume when a pod uses it. section 10.1.1 section 10.2.5 section 10.2.6
Trace a claim to its driver
On the illustrated GKE cluster, `kubectl get sc standard-rwo -o yaml` shows `provisioner: pd.csi.storage.gke.io`. A PersistentVolumeClaim naming `standard-rwo` uses that provisioner to obtain its volume. The StorageClass also supplies parameters, including `type: pd-balanced`. StorageClasses and drivers differ between clusters, so inspect those available in yours. section 10.2.5
$ kubectl get csidrivers NAME ... MODES AGE filestore.csi.storage.gke.io ... Persistent 17h pd.csi.storage.gke.io ... Persistent 25h
Run `kubectl get csidrivers` to see drivers represented in the cluster. In this example, the listed GKE driver name `pd.csi.storage.gke.io` matches the StorageClass provisioner. section 10.2.6 section 10.2.5
A CSI driver can also provide an ephemeral volume that lasts only as long as its pod. For persistent storage, pods generally use a `persistentVolumeClaim` volume rather than name a technology-specific volume directly. You normally do not create CSIDriver objects by hand: the driver vendor supplies a manifest, and installation may create the object automatically. section 9.1.2 section 10.2.6
