Home Explore Blog CI



kubernetes

4th chunk of `content/en/blog/_posts/2018-01-00-Introducing-Container-Storage-Interface.md`
004344de0cdd3fcdcf3770b3dce7c00738779ab2ee07f579000000010000095d
The minimum requirements document also contains a [section](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#recommended-mechanism-for-deploying-csi-drivers-on-kubernetes) outlining the suggested mechanism for deploying an arbitrary containerized CSI driver on Kubernetes. This mechanism can be used by a Storage Provider to simplify deployment of containerized CSI compatible volume drivers on Kubernetes.   

As part of this recommended deployment process, the Kubernetes team provides the following sidecar (helper) containers:  


- [external-attacher](https://github.com/kubernetes-csi/external-attacher)

  - Sidecar container that watches Kubernetes VolumeAttachment objects and triggers ControllerPublish and ControllerUnpublish operations against a CSI endpoint.
- [external-provisioner](https://github.com/kubernetes-csi/external-provisioner)

  - Sidecar container that watches Kubernetes PersistentVolumeClaim objects and triggers CreateVolume and DeleteVolume operations against a CSI endpoint.
- [driver-registrar](https://github.com/kubernetes-csi/driver-registrar)

  - Sidecar container that registers the CSI driver with kubelet (in the future), and adds the drivers custom NodeId (retrieved via GetNodeID call against the CSI endpoint) to an annotation on the Kubernetes Node API Object

Storage vendors can build Kubernetes deployments for their plugins using these components, while leaving their CSI driver completely unaware of Kubernetes.  


### Where can I find CSI drivers?
CSI drivers are developed and maintained by third-parties. You can find example CSI drivers [here](https://github.com/kubernetes-csi/drivers), but these are provided purely for illustrative purposes, and are not intended to be used for production workloads.



### What about Flex?
The [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) exists as an exec based mechanism to create “out-of-tree” volume plugins. Although it has some drawbacks (mentioned above), the Flex volume plugin coexists with the new CSI Volume plugin. SIG Storage will continue to maintain the Flex API so that existing third-party Flex drivers (already deployed in production clusters) continue to work. In the future, new volume features will only be added to CSI, not Flex.  

Title: CSI Driver Deployment, Availability, and the Role of Flex Volumes
Summary
Kubernetes offers a suggested mechanism for deploying containerized CSI drivers, simplifying the process for storage providers. The Kubernetes team provides sidecar containers like external-attacher, external-provisioner, and driver-registrar to help build Kubernetes deployments for CSI plugins. CSI drivers are developed and maintained by third parties, with examples available for illustrative purposes. While the Flex Volume plugin coexists with CSI, future volume features will be added to CSI, not Flex.