Getting Started with Container Storage Interface (CSI) for Kubernetes Workloads
What is CSI in Kubernetes?
When container deployment (a light-weight implementation of software deployment) started it was mostly used for stateless services that were running business logic without much data persistence. As more and more Stateful applications were being deployed, the storage interface to these applications needed to be well defined in native Kubernetes constructs. This need gave way to the CSI standard.
CSI stands for Container Storage Interface and is an industry-standard specification aimed at defining how storage providers can develop plugins that work across many container orchestration systems. For context, a common container orchestration system that highly utilizes CSI is Kubernetes. Kubernetes has had a GA (Generally Available) implementation of CSI since Kubernetes v1.13 was released in December 2018.
How does CSI work?
Part of the deployment declaration (manifest) of a containerized stateful service is to specify the type of storage that the application needs. This can be done in two ways: dynamic provisioning and manual provisioning:
- For dynamic provisioning, the POD (an application deployment unit) manifest points to a persistent volume claim object that references a Storage class defined by the CSI plugin of the specific storage type. This will automatically create and connect a persistent volume of the specified storage class.
- For manual provisioning, the manifest directly points to an existing persistent volume that is pre-created using the storage class definition.
Here is a figure that illustrates the two use cases: 
This figure shows how the POD deployment manifest resolves to the storage devices through CSI for dynamic and manual provisioning.
Key aspects of a CSI plugin
|
Aspect |
Description |
|
Persistent Volume (PV) |
A logical storage volume in Kubernetes that will be made available inside of a CO-managed container, using the CSI. |
|
Persistent Volume Claim (PVC) |
PVCs are requests for storage resources such as the persistent volumes. |
|
Block Volume |
A volume that will appear as a block device inside the container. |
|
Mounted Volume |
A volume that will be mounted using the specified file system and appear as a directory inside the container. |
|
CO (Container Orchestration) |
Container orchestration system communicates with plugins using CSI service RPCs (Remote Procedure Calls). |
|
SP |
Storage Provider, the vendor of a CSI plugin implementation. |
|
RPC |
|
|
Node |
A host where the user workload will be running, uniquely identifiable from the perspective of a plugin by a node ID. |
|
Plugin |
Aka “plugin implementation,” a gRPC endpoint that implements the CSI Services. |
|
Plugin Supervisor |
A process that governs the lifecycle of a plugin, perhaps the CO. |
|
Workload |
The atomic unit of "work" scheduled by a CO. This might be a container or a collection of containers. |
Resources
You can explore the following resources to learn more about this topic:
Demystifying CSI plug-in for PowerFlex (persistent volumes) with Red Hat OpenShift
How to Build a Custom Dell CSI Driver
Dell Ready Stack for Red Hat OpenShift Container Platform 4.6
Solution Brief - Red Hat OpenShift Container Platform 4.10 on Dell Infrastructure
Dell PowerStore with Azure Arc-enabled Data Services
Persistent Storage for Containerized Applications on Kubernetes with PowerMax SAN Storage
Amazon Elastic Kubernetes Service Anywhere on Dell PowerFlex
What is Container Storage Interface (CSI) and how does Dell use it?
Authors: Ryan Wallner and Parasar Kodati