应用上云，怎能没有容器！点击上方容器魔方关注我
术语
行业痛点
容器编排系统（CO），负责管理我们的容器工作负载生命周期， 比如目前最火热的Kubernetes，可以帮助我们快速部署、调度、缩放工作负载，显著提高资源使用率和生产效率。 Kubernetes并不是唯一的容器编排系统，还有Cloud Foundry, Mesos, Docker Swarm等多种系统可供我们使用。每种编排系统都可以运行持久化工作负载，而每种工作负载可以选择不同类型的后端存储。由于没有标准的框架或接口，每种编排系统都有特有的处理存储的方式。
比如：Docker使用DVDI，Kubernetes采用Flexvolume; Mesos支持本地卷，DVDI和REX-Ray。 不同编排系统的实现具有不同的设计标准，不兼容的API，并且难以评估其质量和可靠性。对于存储供应商，需要针对每种容器编排系统编写不同的插件，并做相应的测试，大大增加了其维护成本。对于用户，需要针对不同的编排系统学习使用对应的插件实现，带来了糟糕的用户体验。
技术方案
CSI是Container Storage Interface的缩写。CSI是由来自Kubernetes、Mesos、 Docker等社区的member联合制定的一个行业标准接口规范，旨在将任意存储系统暴露给容器化应用程序。CSI规范定义了存储提供商（SP）实现CSI兼容插件的最小操作集和部署建议。CSI规范的主要焦点是声明插件必须实现的接口。
CSI主要设计要点
1. In-tree模型 vs. Out-of-tree模型
CSI采用Out-of-tree模型实现，Out-of-tree模型与In-tree模型相比，具有以下优点：
●与CO代码完全解耦，CO无需链接、构建、编译插件代码，发布周期无需同步。
●存储供应商负责插件的设计、开发、测试工作，技术栈选择更加灵活。
●更加安全，CO与插件分开部署，无需CO主机权限，减少相互影响。
2. Service实现 vs. CLI（命令行调用）实现
CSI采用service实现，主要基于以下考虑：
●相比CLI，Service服务更容易部署。
●部署CLI二进制需要主机root权限，导致安全问题。
●基于FUSE(用户空间文件系统)的后端需要服务进程长期不间断运行。
3. API设计原则
●CSI所有API调用都是幂等的，保证服务的鲁棒性以及良好的失败恢复机制。
●采用gRPC协议，插件实现可以选择不同语言，众多编程工具，易于编写。
●采用同步API机制，实现简单，解决volume操作时间长问题，保证服务调用幂等。
技术架构
CO通过RPC与插件交互。每个SP必须实现以下两个plugin：
Node Plugin: 需要运行在使用volume的node上，主要实现需要在node上执行的操作，比如volume mount/unmount操作。
Controller Plugin: 可以运行在任何节点上，主要负责volume creation/deletion、attach/detach等操作。
CSI有多种架构设计用于确定插件的部署方式。这些架构和CO实现相似，分为master和node节点。
方案一： plugin运行在集群中所有节点上：Controller Plugin运行在CO master节点，Node Plugin运行在CO所有node节点。
方案二：Headless 插件部署，只有CO node节点运行插件。插件拆分，Controller Plugin和node plugin分别提供服务。
方案三：Headless 插件部署，只运行CO node节点运行插件。统一插件提供Controller服务和Node服务。
Volume完整的生命周期如图所示（示例图包含了关于volume的所有操作，SP plugin可选择实现）。
完整过程： volume创建→attach到节点→mount到全局路径→mount到容器路径→从容器路径unmount → 从全局路径unmount→ 从节点detach→ 删除volume。
业界应用
CSI自发布以来，各容器编排系统也逐步加入了对CSI的支持，Kubernetes 1.9实现了CSI plugin alpha版本，1.11版本已升至Beta，Mesos 1.6已经支持CSI Spec 0.2版本。同时，各存储厂商或云服务提供商，如OpenSDS、RBD、GCE等，也相应发布了CSI plugin。
本部分文章主要对CSI出现的行业背景，设计要点以及架构等做了总体介绍，下一部分，我们将对CSI SPEC进行解析，详细介绍每个服务接口的功能。
推荐阅读
