Storage suppliers wanting to provide storage to containers can heave a sigh of relief; the Container Storage Interface (CSI) v1.0.0 has been released and is available on GitHub.
It is an industry standard interface that can be used by any storage system provider and works across various container orchestration systems, such as Kubernetes, Mesos and Cloud Foundry. Envisage a storage supplier writing a single CSI plugin so their storage could be used by containers orchestrated by any CSI-supporting orchestrator.
There’s no further need for multiple one-off plugins for each orchestrator to be written by every storage supplier wanting to offer storage for containers.
The specification is formally described here. With it, a container orchestrator interacts with a plugin though remote procedure calls (RPCs.) These, also known as Application Programming Interface (API) calls, are used for;
- Dynamic provisioning and deprovisioning of a volume.
- Attaching or detaching a volume from a node.
- Mounting/unmounting a volume from a node.
- Consumption of both block and mountable volumes.
- Local storage providers (e.g., device mapper, lvm).
- Creating and deleting a snapshot (source of the snapshot is a volume).
- Provisioning a new volume from a snapshot (reverting snapshot, where data in the original volume is erased and replaced with data in the snapshot, is out of scope).
Note; CSI provides no guarantee that volumes provided are POSIX-compliant filesystems. Compliance is determined by the plugin implementation (and any backend storage system(s) upon which it depends).
The CSI specification has hot links to Cloud Foundry, Kubernetes and Mesos which lead to documents describing their support for CSI.
It all seems sensible, and cut and dried, and should quickly lead to a wider supply of storage options for containerised workloads.
