CSI架构和原理_Powershell

csi简介

csi的诞生背景

k8s 原生支持一些存储类型的 pv，如 iscsi、nfs、cephfs 等等，这些 in-tree 类型的存储代码放在 kubernetes 代码仓库中。这里带来的问题是 k8s 代码与三方存储厂商的代码强耦合：

更改 in-tree 类型的存储代码，用户必须更新 k8s 组件，成本较高
in-tree 存储代码中的 bug 会引发 k8s 组件不稳定
k8s 社区需要负责维护及测试 in-tree 类型的存储功能
in-tree 存储插件享有与 k8s 核心组件同等的特权，存在安全隐患
三方存储开发者必须遵循 k8s 社区的规则开发 in-tree 类型存储代码

csi 容器存储接口标准的出现解决了上述问题，将三方存储代码与 k8s 代码解耦，使得三方存储厂商研发人员只需实现 csi 接口即可（无需关注容器平台是 k8s 还是 swarm 等）。

pod挂载volume的过程

用户创建一个包含pvc的pod（使用动态存储卷）；
pv controller发现这个pvc处于待绑定状态，调用volume plugin（in-tree或者out-of-tree）创建存储卷，并创建pv对象，然后将创建的pv与pvc绑定；
scheduler根据pod的配置、节点状态、pv配置等信息，把pod调度刀worker节点node上；
ad controller发现pod和pvc处于待挂载状态，调用volume plugin（in-tree或者out-of-tree）实现设备挂载到目标节点（/dev/vdb）；
在worker节点上，kubelet（volume manager）等待设备挂载完成，通过volume plugin将设备挂载到指定目录：/var/lib/kubelet/pods/646154cf-dc72-11e9-b200-00163e007d53/volumes/alicloud~disk/pv-disk；
kubelet在被告知挂载目录准备好后，启动pod中的containers，用docker -v方式（bind）将已经挂载到本地的卷映射到容器中；

csi工作原理

csi的部署模式

csi 主要包含两个部分：csi controller server 与 csi node server，分别对应controller server pod和node server pod

controller server

只需要部署一个 controller server，如果是多备份的，可以部署两个。

controller server 主要是通过多个外部插件来实现的，一个 pod 中可以定义多个 sidecar形式的external container 和一个包含 csi controller server 的 container，这时候不同的 external 组件会和 controller server 组成不同的功能。

交互	过程
external provisioner + controller server	创建、删除数据卷
external attacher + controller server	执行数据卷的挂载、卸载操作
volume manager + volume plugin + node server	执行数据卷的mount、umount操作
ad controller + volumeplugin	创建、删除volumeattachment对象
external resizer + controller server	执行数据卷的扩容操作
externalsnapshotter+controllerserver	执行数据卷的备份操作
driver registrar + volumemanager + node server	注册csi插件，创建csinode对象