Introduction
Kubernetes Container Storage Interface (CSI) Documentation
This site documents how to develop, deploy, and test a Container Storage Interface (CSI) driver on Kubernetes.
The Container Storage Interface (CSI) is a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes. Using CSI third-party storage providers can write and deploy plugins exposing new storage systems in Kubernetes without ever having to touch the core Kubernetes code.
The target audience for this site is third-party developers interested in developing CSI drivers for Kubernetes.
Kubernetes users interested in how to deploy or manage an existing CSI driver on Kubernetes should look at the documentation provided by the author of the CSI driver.
Kubernetes users interested in how to use a CSI driver should look at kubernetes.io documentation.
Kubernetes Releases
| Kubernetes | CSI Spec Compatibility | Status |
|---|---|---|
| v1.9 | v0.1.0 | Alpha |
| v1.10 | v0.2.0 | Beta |
| v1.11 | v0.3.0 | Beta |
| v1.13 | v0.3.0, v1.0.0 | GA |
Development and Deployment
Minimum Requirements (for Developing and Deploying a CSI driver for Kubernetes)
Kubernetes is as minimally prescriptive about packaging and deployment of a CSI Volume Driver as possible.
The only requirements are around how Kubernetes (master and node) components find and communicate with a CSI driver.
Specifically, the following is dictated by Kubernetes regarding CSI:
- Kubelet to CSI Driver Communication
- Kubelet directly issues CSI calls (like
NodeStageVolume,NodePublishVolume, etc.) to CSI drivers via a Unix Domain Socket to mount and unmount volumes. - Kubelet discovers CSI drivers (and the Unix Domain Socket to use to interact with a CSI driver) via the kubelet plugin registration mechanism.
- Therefore, all CSI drivers deployed on Kubernetes MUST register themselves using the kubelet plugin registration mechanism on each supported node.
- Kubelet directly issues CSI calls (like
- Master to CSI Driver Communication
- Kubernetes master components do not communicate directly (via a Unix Domain Socket or otherwise) with CSI drivers.
- Kubernetes master components interact only with the Kubernetes API.
- Therefore, CSI drivers that require operations that depend on the Kubernetes API (like volume create, volume attach, volume snapshot, etc.) MUST watch the Kubernetes API and trigger the appropriate CSI operations against it.
Because these requirements are minimally prescriptive, CSI driver developers are free to implement and deploy their drivers as they see fit.
That said, to ease development and deployment, the mechanism described below is recommended.
Recommended Mechanism (for Developing and Deploying a CSI driver for Kubernetes)
The Kubernetes development team has established a "Recommended Mechanism" for developing, deploying, and testing CSI Drivers on Kubernetes. It aims to reduce boilerplate code and simplify the overall process for CSI Driver developers.
This "Recommended Mechanism" makes use of the following components:
- Kubernetes CSI Sidecar Containers
- Kubernetes CSI objects
- CSI Driver Testing tools
To implement a CSI driver using this mechanism, a CSI driver developer should:
- Create a containerized application implementing the Identity, Node, and optionally the Controller services described in the CSI specification (the CSI driver container).
- See Developing CSI Driver for more information.
- Unit test it using csi-sanity.
- See Driver - Unit Testing for more information.
- Define Kubernetes API YAML files that deploy the CSI driver container along with appropriate sidecar containers.
- See Deploying in Kubernetes for more information.
- Deploy the driver on a Kubernetes cluster and run end-to-end functional tests on it.