OpenSDS introduces CSI aims to define an industry standard that enables storage vendors (SP) to develop a plugin once and have it work across several container orchestration (CO) systems. The container orchestration (CO) systems include Kubernetes, Docker Swarm, Cloud Foundry and so on.
Container orchestration platform is especially beneficial when running microservices in containers. Kubernetes and Docker Swarm are the top orchestration production.
Why there is a need of CSI?
Pluggable storage interface (PSI) allowing storage vendors to plugin into systems. Popular container orchestration (CO) or middleware have independently evolved storage interfaces. It causes painful to storage providers because they have to build those different types of interface for different COâ€™s.
Also, it was causing problem for cost providers because they have to understand different types of standards, eventually causes issues to users.
Existing interfaces creating problems like CLI based interface, lack of Idempotency on APIâ€™s, too heavyweight and so forth.
To overcome such issues, Container Storage Interface (CSI) has been introduced which provides interoperability which helps storage vendors to create single plugin and that plugin can be used by systemâ€™s that supports CSI. CSI also overcome problems like Vendor neutral, focus on specification and so on.
Container Storage Interface (CSI)
Container Storage Interface in a cloud native environment have container orchestration system, storage vendors, storage container orchestration systems. Container Orchestrators (COâ€™s) include the Kubernetes, Docker Swarm, Cloud Foundry, Mesos.
Figure: Container Storage Interface
Pluggable Storage Interface (PSI) allowing storage vendors to plugin into system. CSI provides container orchestrators with following capabilities.
- Create or delete volumes.
- Mounting and Unmounting of a volume from a host node.
- Format volumes.
- Create snapshots.
- Attachment and Detachment of volumes from a host node.
- Dynamic provisioning and decommissioning of volumes.
CSI lifecycle of a new volume
Figure: Lifecycle of a new volume request
The above diagram illustrates the lifecycle of a new volume request.
The create volume and delete volume calls are used to create and delete a volume on the storage platform. Once a volume is created ControllerPublishVolume/ControllerUnpublishVolume ensure that an existing volume is made physically available to a container host.
NodePublishVolume/NodeUnpublishVolume is used to associate a volume with a specific container. All these happens in dynamically provisioned volume.
In case of Pre-provisioned volumes, the plugin simply maps and publishes volumes to a host.
CSI is designed and divided into different architecture diagrams that specifies how the plugins are deployed. The focus of this architecture is between CO and Plugin for a different deployment architecture.
Scenario 1 is an architecture diagram of master/node separate CSI. It shows the plugin runs on all the nodes in the cluster. The controller plugin is available on the master host whereas the node plugin is available on the node host.
Scenario 2 is an architecture diagram of Headless combined CSI. In this, only the CO node host run plugins. The controller plugin and the node plugin split the component plugins separately.
Scenario 3 is an architecture diagram of headless plugin deployment. Here only the CO node host run plugins. The unified plugin component supplies both controller and node service.
Container Storage Interface, its volume and plugins provide a clear benefit for the COâ€™s and storage vendors. Due to the interfaces, it not only helps developers but also future COâ€™s to easily implement and test CSI.