《如何为容器提供持久化存储？》文章中我们已经介绍了Kubernetes存储系统的一些核心概念，其中包括：
- StorageClass (SC)：存储类，类似存储池的概念，包括了存储池的一些信息；
- PersistenVolume (PV)：持久卷，独立的存储资源对象，其生命周期与Pod无关；
- PersistenVolumeClaim (PVC): 声明，代表计算任务对存储资源的需求。
这种存储结构是为了解决
- 有状态的容器实例需要持久化卷；
- 容器实例动态提供新卷；
- 不同类型的应用需要不同访问模式的存储卷；
- 解耦计算资源和存储资源。
但是对于接触Kubernetes不久的人而言，可能仍然存在不少疑惑，卷(Volume)，持久卷(PersistoneVolume)，存储类(StorageClass)，供给器(Provisioner)， 容器存储接口(CSI)，动态供应（Dynamic provisioning）等等到底是什么？存储提供商如何提供自定义存储服务？下面我们将一步一步深入了解。
一、Kubernetes 存储对接如何选择
如果有使用过Docker经验的话，就会发现在Docker中就有Volume的概念，Volume本质上是容器上挂载的某个目录 [1]。
1、Volume（卷）
Kubernetes同样也有Volume的概念，它属于Pod内部共享资源存储，生命周期和Pod相同，与Container无关，即使Pod上的容器停止或者重启，Volume不会受到影响，但是如果Pod终止，那么这个Volume的生命周期也将结束。
2、Persistent Volume（持久卷）
显然，这样的存储无法满足有状态服务的需求，于是有个Persistent Volume(PV)即持久卷，故名思义，持久卷是能将数据进行持久化存储的一种资源对象。PV，它是独立于Pod的一种资源，是一种网络存储，它的生命周期和Pod无关。云原生的时代，PV的种类也包括很多，包括XSKY全面支持的iSCSI，RBD，NFS，以及CSI, CephFS, OpenSDS, GlusterFS, Cinder等网络存储。
可以看出Volume和Persistent Volume的最大区别是生命周期，PV是一种独立的存储，管理员只需要在存储上创建足够的PV，就可以提供给计算节点中的Pod来使用，而且数据是持久存储的。这种手动创建PV来提供给Pod使用的方式也叫做静态供应。
3、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适合变动较少，不会频繁修改的场景，是比较直接的使用方式。
二、如何实现动态供应
面对计算层的多种存储需求，要考虑如何高效且灵活的提供存储服务，于是就有了动态供应的策略。动态供应能按需分配资源，大大减轻了运维工作，是目前最为推荐的一种方式，在很多企业生产环境中都有它的应用。
1、如何实现动态供应
显然动态供应比静态供应灵活更多，而且这种方式还解耦了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是更推荐的解决方案。
2、几种卷插件对比
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的核心组件解耦，并能支持更多的存储类型和高级特性，因而也是推荐使用的一种供应方式。由于后者对编排系统而言是非侵入式插件部署，因而更受存储供应商的青睐。
三、XSKY基于CSI的容器存储方案
Kubernetes作为最流行的容器编排系统之一，用户的接受度高，XSKY也密切关注Kubernetes社区的发展。从最初的In-tree 插件支持，后来又支持Out-of-tree provisioner，到现在最新的CSI，XSKY都是同步跟进支持的。
前面已经非常详尽的对CSI技术原理进行了剖析，XSKY基于CSI的容器存储方案，具体如下图所示：
1、统一存储：XSKY基于CSI接口提供iSCSI和NFS两种容器存储方案，无论是块存储还是文件存储，都可以通过CSI的方式去使用；
2、稳定性：CSI方案将存储和计算两种资源完全解耦，实现了资源的隔离，同时CSI插件以容器化部署，因此稳定性更进一步得到保障；
3、兼容性：CSI插件以容器化部署，不会受到操作系统版本和存储集群的限制，消除环境差异所带来的不确定性以及其他约束；
4、易运维：不需要复杂的集群配置修改和准备工作，只需填好CSI容器配置，拉取镜像，一键可达；
5、无缝升级：如果之前使用的RBD，iSCSI，NFS对接，XSKY也提供完善可靠的无缝升级方案，从In-tree/Out-of-tree升级到CSI接口上；
6、丰富的特性支持：不仅仅满足客户存储的基本需求，在实际使用中，XSKY提供的存储插件有很多非常重要和倍受青睐的高级特性，支持动态扩容，根据实际需求动态地扩容和缩容。除此之外，还会有Snapshots快照以及QoS管理等其他的特性，进一步完善容器生态；
7、高性能：在容器的使用场景，通常会有非常多的Pod或者在Pod上会挂载较多的卷，需要消耗一定的资源，得益于后端存储的IO全路径性能优化以及资源的有效管理，我们仍然能保证非常高的性能。特别如今云原生时代，非常适合要求轻量，快速的容器云平台，一分钟内就能启动上百个pod，不但存储IO性能良好，并发创建也是经得起考验的。
四、总结
通过非常详尽的分析Kubernetes存储机制，从静态供应存储到动态供应，对比动态供应几种方案，以及从数据流的角度深入到每个存储组件的细节中，XSKY希望可以为用户提供更加可靠和完善的存储服务。
目前XSKY已经能为容器编排平台包括且不限于Kubernetes，Rancher和OpenShift提供RBD，iSCSI和NFS存储。同时这也是XSKY不断完善周边生态重要的一步，正如XSKY的使命：Make Data Alive（赋予数据无限可能）。
参考文献：[1] https://kubernetes.io/docs/concepts/storage/volumes/