kubernetes 存储插件CSI开发指导

1.K8s 的持久化存储支持

在支持持久化存储方面，K8s 提供了内嵌原生 Driver 的方式连接外部的常见存储系统例如 NFS、iSCSI、CephFS、RBD 等来满足不同业务的需求。但由于存储生态本身也在不断演进，使用 K8s 内嵌的方式来支持不断变化的存储系统在成本和时效上都会对 K8s 项目自身带来巨大的挑战。

所以和其他服务管理系统一样，K8s 逐渐的将存储系统的具体实现从主项目中分离出来，通过定义接口的方式允许第三方厂商自行接入存储服务。在这个道路上也经历了两个阶段：

1. Flex Volume, 自 1.2 版本引入。
   第三方存储服务提供商直接在 K8s Server 上部署符合 Flex Volume 规范的 Driver，利用 K8s 暴露出的 mount/unmount/attach/detach 等关键 API 实现存储系统的接入。这个模式主要的问题是，在这个形态下第三方厂商的 Driver 有权限接入物理节点的根文件系统，这会带来安全上的隐患。
2. Container Storage Interface (CSI), 自 1.9 版本引入，目前已经进入 GA 阶段（1.13）。
   CSI 定义了容器场景所需要的存储控制原语和完整的控制流程，并且在 K8s 的 CSI 实现中，所有的第三方 Driver 和 K8s 的其他服务扩展一样，以服务容器的形态的运行，不会直接影响到 K8s 的核心系统稳定性。

2.存储对象

CSI 定义的存储对象为持久化卷，称之为 Volume。包括两种类型：

• Mounted File Volume，Node 将会把 Volume 以指定的文件格式 Mount 到 Container 上，从 Container 的角度看到的是一个目录；
• Raw Block Volume, 直接将 Volume 以 Block Device（磁盘）的形态暴露给 Container，对于某些可以直接操作磁盘的服务，这个形态可以省去文件系统的开销获得更好的性能。

Raw Block Volume 目前还处于 Beta 阶段，所以下文的过程描述和 SMTX 的 CSI Driver 目前的实现方式均针对 Mounted File Volume。

3.基本术语

4.Plugin

RPC接口: CO通过RPC与插件交互, 每个SP必须提供两类插件：

• Controller Plugin，负责存储对象（Volume）的生命周期管理，在集群中仅需要有一个即可；
• Node Plugin，在必要时与使用 Volume 的容器所在的节点交互，提供诸如节点上的 Volume 挂载/卸载等动作支持，如有需要则在每个服务节点上均部署。

存储服务商可以根据自身需求实现不同的的 Plugin 组合。例如对于以 NFS 形式提供的存储服务，可以仅实现 Controller Plugin 实现资源的创建和访问权限控制，每个节点均可以通过标准的 NFS 方式获得服务，无需通过 Node Plugin 来实现挂载/卸载等操作。而以 iSCSI 形式提供的存储服务，就需要 Node Plugin 在指定节点上，通过挂载 LUN，格式化，挂载文件系统等一系列动作完成 iSCSI LUN 至容器可见的目录形式的转化。

5.Volume 生命周期

一个典型的 CSI Volume 生命周期如下图（来自 CSI SPEC）所示：

 &