CSI 介绍
我们知道Kubernetes中关于使用存储卷的机制有In-Tree、Flexvolume模式，那为何还要提出CSI方式呢？
In-Tree Volume: 这种方式需要将后端存储的代码逻辑放到K8S的代码中运行，调用引擎与插件间属于强耦合。插件的逻辑代码需要K8S负责维护，可能会引起与K8S其他部件之间的相互影响。
Flexvolume: Kubelet通过调用一个主机的可执行程序包的方式执行存储卷的挂载使用。解决了In-Tree方式的强耦合，不过由于Flexvolume作为命令行调用的方式，在主机安全性、部署依赖的容器化、与K8S服务之间的相互扩展性等方面存在不足。
Flexvolume运行在host 空间，不能使用rbac授权机制访问Kubernetes API，导致其功能极大的受限。
CSI: 基于上述模式存在的不足，CSI标准使K8S和存储提供者之间将彻底解耦，将存储的所有的部件作为容器形式运行在K8S上。
在FlexVolume中Kubelet通过使用操作系统CLI实现调用Driver接口，而CSI采用的是grpc方式，grpc调用的一个优势就是可以将grpc服务运行在socket上，这样服务端就可以运行在socket端点的任何地方，即可以运行在容器里。另外CSI接口使用同步方式进行调用，保证了存储插件实现的简单性。
从平台支持上，CSI不仅仅支持Kubernetes平台存储插件接口，而是作为云原生生态中容器存储接口的标准，Mesos、CloudFoundry、Swarm等平台也同时支持CSI。
下图给出了CSI接口在云原生应用中的位置。
我们回顾一下CSI版本发布历程：
从2017年初发展到今天，CSI用了2了两年的时间发布了自己的稳定版本，且K8S对CSI的支持也进入到GA阶段。
