容器存储CSI介绍（二）

朵来朵去

上一期我们简单介绍了容器存储接口（CSI）的主要功能和工作原理：容器存储CSI介绍（一）。在今天的文章中，我们将继续为大家带来，CSI在Kubernetes 中的应用等内容。
CSI在Kubernetes 中的应用

Kubernetes为什么要使用CSI?

在CSI出现以前，K8S存在两种方式的卷插件，一种是in-tree方式，另一种则是Flex Volume方式。这两种方式各有缺点：
In-tree插件意味着它们与核心 K8S代码一起链接、编译、构建和交付，向 K8S（卷插件）添加新的存储系统需要将代码提交到核心K8S代码库，存在很多缺点：

• Volume插件开发紧密耦合并依赖于 K8S版本；。
  
• K8S开发人员/社区负责测试和维护所有卷插件，而不仅仅是测试和维护稳定的插件API；。
  
• 卷插件中的错误可能会导致关键的 K8S组件崩溃，而不仅仅是插件；。
  
• 卷插件获得K8S组件（kubelet和kube-controller-manager）的全部权限；。
  
• 插件开发人员被迫提供插件源代码，并且不能选择只发布二进制文件。
  

由于in-tree插件存在的问题，Flex Volume插件试图通过公开一个基于exec的API进行挂载/卸载/附加/分离来解决这个问题。尽管它使第三方存储供应商能够编写out-of-tree驱动程序，但它需要访问节点和主机的根文件系统才能部署第三方驱动程序文件。
此外，它没有解决in-tree卷插件的另一个痛点：依赖项。卷插件往往有许多外部需求，：例如：，对挂载和文件系统工具的依赖，。一般底层主机可能无法提供这些依赖，而安装依赖需要直接访问主机。
于是，K8S参与到CSI的制定中，通过使用CSI接口标准，存储供应商可以开发各自的存储插件，而不需要把代码贡献给K8S核心库，对K8S而言，采用 CSI 将具有将卷插件移出核心代码的额外好处，并使卷插件能够被容器化。
Kubernetes CSI插件现状

CSI是从K8Sv1.9版本引入的容器存储接口，并于v1.13版本正式GA。K8S实现了in-tree的CSI卷插件, 以及各种Sidecar插件把CSI驱动程序和Kubernetes 的核心代码实现了解耦合, 从而使得方便存储厂商可以更加便捷方便的开发CSI驱动程序。目前CSI还在不断的开发和完善中, 导致不同Kubernetes 版本可使用的CSI版本是不同的，在使用时要特别注意。


Kubernetes CSI Sidecar 容器
Kubernetes CSI Sidecar Containers是一组标准容器，旨在简化K8S上CSI驱动程序的开发和部署。这些容器会观察K8S API的通用逻辑，触发针对CSI卷驱动程序的适当操作，并根据需要更新K8S API。
这些Sidecar容器由K8S存储社区开发和维护，使用时与第三方CSI驱动程序容器捆绑在一起并作为pod pod部署。Sidecar容器使用是可选的，但社区强烈推荐使用。一般的，各大公有云厂商会选择定制化开发自己的Sidecar容器，从而更好地对接K8S和内部存储。
这些Sidecar容器的好处包括：

• 减少“样板”代码。CSI 驱动程序开发人员不必担心复杂的K8S特定代码。
  
• 关注点分离。K8SAPI 交互的代码与实现 CSI 接口的代码隔离（在不同的容器中）。
  

K8S开发团队主要维护以下 Kubernetes CSI Sidecar Containers：

external-attacher	监视Kubernetes API 服务器中的VolumeAttachment对象并触发Controller[Publish|Unpublish]Volume
external-provisioner	监视 Kubernetes API 服务器中的PersistentVolumeClaim对象并触发CreateVolume和DeleteVolume
external-snapshotter	监视 Kubernetes API 服务器的VolumeSnapshotContent CRD 对象并调用 CreateSnapshot、DeleteSnapshot 和 ListSnapshots
external-resizer	监视 Kubernetes API 服务器对PersistentVolumeClaim对象的编辑并触发ControllerExpandVolume
node-driver-registrar	使用kubelet 插件注册机制将其注册到该节点上的kubelet， kubelet 直接针对 CSI 驱动程序发出 CSI NodeGetInfo、NodeStageVolume和NodePublishVolume调用
livenessprobe	它监视 CSI 驱动程序的健康状况并通过Liveness Probe 机制将其报告给 Kubernetes

Kubernetes CSI 架构



综上所述，K8S为了摆脱in-tree插件以及不方便安装依赖的缺点，实现了通过一套复杂的逻辑来解耦CSI驱动程序和核心代码，又依靠自身作为插件的管理者将CSI驱动程序和Sidecar插件一起使用podPOD（即容器）的方式来部署和管理，原理。如上图所示。
K8S提供资源的定义，如pod、pvc、pv、volumeAttachment等， volumesnapshot和volumesnapshotcontent为CRD资源，K8S各个组件调用in-tree插件进行管理，Sidecar插件监听资源变化并调用CSI的接口执行具体动作。下面详细说明以下各个组件的功能。
K8S的存储主要完成以下三组行为：

• provision/delete
  
• attach/detach(可选)
  
• mount/unmount
  

其中，attach/detach又分两种类型，一种是在控制节点的attach/detach， 一种是在容器运行节点的attach/detach，这两类的区别主要是控制节点的attach/detach会完成一些attach/detach的准备工作，节点的attach/detach完成卷在对应节点的attach/detach。

• PV Controller: 监听PV，PVC，。当监听到这些资源的创建、删除、修改时，PV Controller经过判断是否需要做PV/PVC的绑定、生命周期管理，并根据需求进行树内插件（非CSI插件）管理数据卷的 Provision/Delete 操作。
  
• AD Controller: 监听node和pod资源，通过node和pod变更创建/删除VolumeAttachment对象，触发CSI插件在控制节点执行的 Attach/Detach 操作，比如将公有云场景下调用接口将设备挂载到目标节点（可选）。
  
• Volume Manager: Volume Manager不会监听API Server，在node节点所有的资源监听都是Kubelet完成的，Kubelet会监听到调度到该节点上的pod声明，缓存到Pod Manager中，Volume Manager通过Pod Manager获取PV/PVC的状态，并进行分析出具体的attach/detach, 然后调用plugin调用节点执行的 Attach/Detach 操作（可选），管理卷的 Mount/Unmount 操作、卷设备的格式化以及挂载到一些公用目录上的操作。
  
• CSI Plugin(outof tree):它主要是对上面所有功能的具体实现, PV Controller、AD Controller、Volume Manager以及Sidercar插件主要是进行操作的调用，而具体操作则是由 CSI Plugin 实现的。
  
• Scheduler: 实现对 pPod 的调度能力，会根据一些存储相关的的定义去做一些存储相关的节点的调度。
  

本文参考文档：

• https://github.com/container-storage-interface/spec/blob/master/spec.md
  
• https://kubernetes-csi.github.io/docs/
  

相关阅读推荐：容器存储CSI介绍（一）
本篇文章转载自天翼云官方网站开发者社区，了解更多云计算知识可登陆天翼云官方网站开发者社区，点击专栏查看更多技术干货，与技术大咖促膝论道！