Das Container Storage Interface (CSI) ist ein offener Standard, mit dem sich Speichersysteme einheitlich in Kubernetes anbinden lassen. Statt dass jede Speicherlösung eine eigene eingebaute Anbindung braucht, liefert der Hersteller einen CSI-Treiber – Kubernetes spricht mit ihm über eine fest definierte Schnittstelle. CSI ist seit Kubernetes 1.13 stabil (GA).
Wie CSI funktioniert
Die Kommunikation zwischen Kubernetes und Treiber läuft über gRPC. Jeder Treiber stellt drei Dienste bereit:
- Identity Service: meldet Name und Fähigkeiten des Treibers.
- Controller Service: erzeugt und löscht Volumes und hängt sie an Knoten an – etwa über
CreateVolumeoderControllerPublishVolume. - Node Service: bindet das Volume auf dem Knoten ein (
NodeStageVolume,NodePublishVolume).
Die Treiber laufen als Pods im Cluster. Ergänzende Sidecar-Container vermitteln zwischen Kubernetes-API und Treiber: der external-provisioner überwacht PersistentVolumeClaims und stößt die Volumes an, der external-attacher kümmert sich um das Anhängen, der external-resizer um Vergrößerung und der external-snapshotter um VolumeSnapshots.
Warum CSI?
Vor CSI mussten Speicher-Plugins direkt in den Kubernetes-Quellcode eingebaut werden (in-tree). CSI macht die Anbindung out-of-tree und damit unabhängig von Kubernetes-Versionen; der ältere Mechanismus FlexVolume gilt als veraltet. Typische CSI-Treiber gibt es für AWS EBS, Azure Disk, Ceph RBD, NFS oder lokale Pfade. Sie arbeiten mit StorageClasses zusammen, die die passende Klasse für die dynamische Bereitstellung wählen – Grundlage ist das PersistentVolume-Konzept.