k8s之CSI实现原理

简介

Kubernetes存储系统的核心概念包括：

• StorageClass (SC)：存储类，类似存储池的概念，包括了存储池的一些信息；
• PersistenVolume (PV)：持久卷，独立的存储资源对象，其生命周期与Pod无关；
• PersistenVolumeClaim (PVC): 声明，代表计算任务对存储资源的需求。

这种存储结构是为了解决

• 有状态的容器实例需要持久化卷；
• 容器实例动态提供新卷；
• 不同类型的应用需要不同访问模式的存储卷；
• 解耦计算资源和存储资源。

但是对于接触Kubernetes不久的人而言，可能仍然存在不少疑惑，卷(Volume)，持久卷(PersistoneVolume)，存储类(StorageClass)，供给器(Provisioner)， 容器存储接口(CSI)，动态供应（Dynamic provisioning）等等到底是什么？存储提供商如何提供自定义存储服务？下面我们将一步一步深入了解。

Kubernetes 存储对接如何选择

如果有使用过Docker经验的话，就会发现在Docker中就有Volume的概念，Volume本质上是容器上挂载的某个目录 [1]。

Volume（卷）

Kubernetes同样也有Volume的概念，它属于Pod内部共享资源存储，生命周期和Pod相同，与Container无关，即使Pod上的容器停止或者重启，Volume不会受到影响，但是如果Pod终止，那么这个Volume的生命周期也将结束。

Persistent Volume（持久卷）

Volume无法满足有状态服务的需求，持久卷(Persistent Volume)是能将数据进行持久化存储的一种资源对象。它是独立于Pod的一种资源，生命周期和Pod无关。PV的种类也包括很多，包括iSCSI，RBD，NFS，以及CSI, CephFS, OpenSDS, GlusterFS, Cinder等网络存储。

Dynamic Provisioning（动态供应）

iSCSI，RBD，NFS等PV分别代表了各种类型的存储资源，供集群消费，PersistentVolumeClaim（PVC）就是对这些存储资源的请求。PVC消耗的资源是PV，这很好理解，就像Pod消耗Node资源一样。于是，在Kubernetes中Pod可以不直接使用PV，而是通过PVC来使用PV。

通过PVC可以将Pod和PV解耦，Pod不需要知道确切的文件系统和支持它的持久化引擎，可以把PVC理解为存储的抽象，把底层存储细节给隔离了。另一方面，如果使用PV作为存储的话，需要集群管理员事先创建好这些PV，但是如果使用PVC的话则不需要提前准备好PV，而是通过StorageClass把存储资源定义好，Kubernetes会在需要使用的时候动态创建，这种方式称为动态供应 (Dynamic Provisioning)。

详细流程分析如下：

（1）Pod加载存储卷，请求PVC

（2）PVC根据存储类型(此处为rbd)找到存储类StorageClass

（3）Provisioner根据StorageClass动态生成一个持久卷PV

（4）持久卷PV和PVC最终形成绑定关系

（5）持久卷PV开始提供给Pod使用

简单总结下，如果在Kubernetes中运行有状态服务，比如数据库MySQL，MongoDB或者中间件Redis，RabbitMQ等，那么就需要用持久卷（PV），从而不用担心随着Pod的终止而丢失数据（相比使用了普通Volume）。 另外，从以上对比可看出，直接使用PV适合变动较少，不会频繁修改的场景，是比较直接的使用方式。

动态供应

面对计算层的多种存储需求，要考虑如何高效且灵活的提供存储服务，于是就有了动态供应的策略。动态供应能按需分配资源，大大减轻了运维工作，是目前最为推荐的一种方式，在很多企业生产环境中都有它的应用。

如何实现动态供应

显然动态供应比静态供应灵活更多，而且这种方式还解耦了Kubernetes系统的计算层和存储层，更重要的是它给存储供应商提供了可插拔式的开发模型，存储供应商只需要根据这个模型开发相应的卷插件即可为Kubernetes提供存储服务。

有如下三种方法实现卷插件:

• In-tree Volume Plugin
• Out-of-tree Provisioner
• Out-of-tree CSI Driver

第一种，Kubernetes内部代码中实现了一些存储插件，用于支持一些主流网络存储，叫作In-tree Volume Plugin。

第二种 Out-of-tree Provisioner：如果官方的插件不能满足要求，存储供应商可以根据需要去定制或者优化存储插件并集成到Kubernetes系统。

第三种是容器存储接口CSI (Container Storage Interface)，是Kubernetes对外开放的存储接口，实现这个接口即可集成到Kubernetes系统中。CSI特性在刚过去的12月正式GA，同时社区也宣布未来将不再对In tree/Out of tree继续开发，并将已有功能全部迁移到CSI上，所以对于存储供应商和使用者来说，第三种CSI是更推荐的解决方案。

几种卷插件对比

In-tree Volume Plugin

In-tree Volume Plugin是Kubernetes自带的，属于Kubernetes的一部分，由Kubernetes一起发布和维护，所有存储插件代码都集成在Kubernetes中，第三方存储供应商难以集成。

Out-of-tree Provisioner

其中挂载组件还是复用，只是把Provisioner组件从Kubernetes中挪出来，以供实现定制化或者自定义的高级功能。

创建流程（绿色）：状态更新，监听状态，调用外部供给器，结合后端存储服务，创建一个PV对象，这一步借助外部的Provisioner组件来完成。

挂载流程（橙色）：监听事件，插件挂载卷等操作由原有挂载组件继续负责。

Container Storage Interface (CSI)

一直以来，存储插件的测试、维护等事宜都由Kubernetes社区来完成，即使有贡献者提供协作也不容易合并到主分支发布。另外，存储插件需要随Kubernetes一同发布，如果存储插件存在问题有可能会影响Kubernetes其他组件的正常运行。

鉴于此，Kubernetes和CNCF决定把容器存储进行抽象，通过标准接口的形式把存储部分移到容器编排系统外部去。CSI的设计目的是定义一个行业标准，该标准将使存储供应商能够自己实现，维护和部署他们的存储插件。这些存储插件会以Sidecar Container形式运行在Kubernetes上并为容器平台提供稳定的存储服务。

如上CSI设计图：浅绿色表示从Kubernetes社区中抽离出来且可复用的组件，负责连接XSKY CSI插件（右侧）以及和Kubernetes集群交互：

• Driver-registrar: 使用 Kubelet注册 CSI 驱动程序的 sidecar 容器，并将 NodeId （通过 GetNodeID 调用检索到 CSI endpoint）添加到 Kubernetes Node API 对象的 annotation 里面；
• External-provisioner: 监听 Kubernetes PersistentVolumeClaim 对象的 sidecar 容器，并触发对 CSI 端点的 CreateVolume 和DeleteVolume 操作；
• External-attacher: 可监听 Kubernetes VolumeAttachment 对象并触发 ControllerPublish 和 ControllerUnPublish 操作的 sidecar 容器，负责attache/detache卷到node节点上。

右侧橘黄色表示XSKY实现的存储插件驱动，分别有三个服务：

• CSI identify: 标志插件服务，并维持插件健康状态；
• CSI Controller: 创建/删除，attaching/detaching，快照等；
• CSI Node: attach/mount、umount/detach。

动态供应方式总结：通过对比Kubernetes的In-tree Volume Plugin，以及Out-of-tree Provisioner和CSI三种方式，在对接比较常见的存储时，可以使用不需要改动的In-tree方案，因为开箱即用，但是缺点也非常明显，只支持有限的存储类型，可拓展性较差甚至有版本限制，另外官方宣布以后新特性将不再添加到其中。

相比之下，使用Out-of-tree Provisioner或者CSI则可以实现和Kubernetes的核心组件解耦，并能支持更多的存储类型和高级特性，因而也是推荐使用的一种供应方式。由于后者对编排系统而言是非侵入式插件部署，因而更受存储供应商的青睐。

基于CSI的容器存储方案

Kubernetes作为最流行的容器编排系统之一，用户的接受度高，XSKY也密切关注Kubernetes社区的发展。从最初的In-tree 插件支持，后来又支持Out-of-tree provisioner，到现在最新的CSI，XSKY都是同步跟进支持的。

前面已经非常详尽的对CSI技术原理进行了剖析，XSKY基于CSI的容器存储方案，具体如下图所示：

• 统一存储：基于CSI接口提供iSCSI和NFS两种容器存储方案，无论是块存储还是文件存储，都可以通过CSI的方式去使用；

• 稳定性：CSI方案将存储和计算两种资源完全解耦，实现了资源的隔离，同时CSI插件以容器化部署，因此稳定性更进一步得到保障；

• 兼容性：CSI插件以容器化部署，不会受到操作系统版本和存储集群的限制，消除环境差异所带来的不确定性以及其他约束；

• 易运维：不需要复杂的集群配置修改和准备工作，只需填好CSI容器配置，拉取镜像，一键可达；

• 无缝升级：如果之前使用的RBD，iSCSI，NFS对接，XSKY也提供完善可靠的无缝升级方案，从In-tree/Out-of-tree升级到CSI接口上；

• 丰富的特性支持：不仅仅满足客户存储的基本需求，在实际使用中，XSKY提供的存储插件有很多非常重要和倍受青睐的高级特性，支持动态扩容，根据实际需求动态地扩容和缩容。除此之外，还会有Snapshots快照以及QoS管理等其他的特性，进一步完善容器生态；

• 高性能：在容器的使用场景，通常会有非常多的Pod或者在Pod上会挂载较多的卷，需要消耗一定的资源，得益于后端存储的IO全路径性能优化以及资源的有效管理，我们仍然能保证非常高的性能。特别如今云原生时代，非常适合要求轻量，快速的容器云平台，一分钟内就能启动上百个pod，不但存储IO性能良好，并发创建也是经得起考验的。