CSI - Container Storage Interface
The goal of CSI is to establish a standardized mechanism for Container Orchestration Systems (COs) to expose arbitrary storage systems to their containerized workloads. The CSI specification emerged from cooperation between community members from various COs – including; Kubernetes, Mesos, Docker, and Cloud Foundry. The specification is developed, independent of Kubernetes, and maintained here.
Why do we need it?
Historically, Kubernetes volume plugins were “in-tree”, meaning they’re linked, compiled, built, and shipped with the core kubernetes binaries. Adding support for a new storage system to Kubernetes (a volume plugin) required checking code into the core Kubernetes repository. But aligning with the Kubernetes release process was very painful for many plugin developers. CSI, the Container Storage Interface, makes installing new volume plugins as easy as deploying a pod. It also enables third-party storage providers to develop solutions without the need to add to the core Kubernetes codebase.
CSI enables storage plugins to be developed out-of-tree, containerized, deployed via standard Kubernetes primitives, and consumed through the familiar Kubernetes storage primitives, such as
Which versions of Kubernetes/vSphere support it?
How do I install it?
How do I use/consume it?
If the vSphere CSI storage plugin is already deployed on your cluster, you can use it through the familiar Kubernetes storage primitives such as
Do you have an example StorageClass?
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: space-efficient annotations: storageclass.kubernetes.io/is-default-class: "true" provisioner: csi.vsphere.vmware.com parameters: storagepolicyname: "Space Efficient"