CSI Drivers, Flex Volumes, Migration Plans, Limitations, and Getting Involved

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. ### What will happen to the in-tree volume plugins? Once CSI reaches stability, we plan to migrate most of the in-tree volume plugins to CSI. Stay tuned for more details as the Kubernetes CSI implementation approaches stable. ### What are the limitations of alpha? The alpha implementation of CSI has the following limitations: - The credential fields in CreateVolume, NodePublishVolume, and ControllerPublishVolume calls are not supported. - Block volumes are not supported; only file. - Specifying filesystems is not supported, and defaults to ext4. - CSI drivers must be deployed with the provided “external-attacher,” even if they don’t implement “ControllerPublishVolume”. - Kubernetes scheduler topology awareness is not supported for CSI volumes: in short, sharing information about where a volume is provisioned (zone, regions, etc.) to allow k8s scheduler to make smarter scheduling decisions. ### What’s next? Depending on feedback and adoption, the Kubernetes team plans to push the CSI implementation to beta in either 1.10 or 1.11. ### How Do I Get Involved? This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. A huge thank you to Vladimir Vivien ([vladimirvivien](https://github.com/vladimirvivien)), Jan Šafránek ([jsafrane](https://github.com/jsafrane)), Chakravarthy Nelluri ([chakri-nelluri](https://github.com/chakri-nelluri)), Bradley Childs ([childsb](https://github.com/childsb)), Luis Pabón ([lpabon](https://github.com/lpabon)), and Saad Ali ([saad-ali](https://github.com/saad-ali)) for their tireless efforts in bringing CSI to life in Kubernetes. If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). We’re rapidly growing and always welcome new contributors.

Storage vendors can use provided components for Kubernetes plugin deployments, allowing CSI drivers to be unaware of Kubernetes. CSI drivers are developed by third parties, with examples for illustration. The Flex Volume plugin coexists with CSI, but new features will be CSI-only. In-tree volume plugins will eventually migrate to CSI. Alpha limitations include lack of credential fields, block volume support, and filesystem specification. The Kubernetes team plans to push CSI to beta based on feedback. Interested contributors can join the Kubernetes Storage Special-Interest-Group (SIG).