k8s存储架构

数据卷挂载的过程

　　第一步：用户创建一个包含 PVC的 Pod；

　　第二步：PV Controller 会不断观察 ApiServer，如果它发现一个 PVC 已经创建完毕但仍然是未绑定的状态，它就会试图把一个 PV 和 PVC 绑定；PV Controller 首先会在集群内部找到一个适合的 PV 进行绑定，如果未找到相应的 PV，就调用 Volume Plugin 去做 Provision。Provision 就是从远端上一个具体的存储介质创建一个 Volume，并且在集群中创建一个 PV 对象，然后将此 PV 和 PVC 进行绑定；

　　第三步：通过 Scheduler 完成一个调度功能。我们知道，当一个 Pod 运行的时候，需要选择一个 Node，这个节点的选择就是由 Scheduler 来完成的。Scheduler 进行调度的时候会有多个参考量，比如 Pod 内部所定义的 nodeSelector、nodeAffinity 这些定义以及 Volume 中所定义的一些标签等。

　　第四步：如果有一个 Pod 调度到某个节点之后，它所定义的 PV 还没有被挂载（Attach），此时 AD Controller 就会调用 VolumePlugin，把远端的 Volume 挂载到目标节点中的设备上（如：/dev/vdb）；

　　第五步：当 Volum Manager 发现一个 Pod 调度到自己的节点上并且 Volume 已经完成了挂载，它就会执行 mount 操作，将本地设备（也就是刚才得到的 /dev/vdb）挂载到 Pod 在节点上的一个子目录中。同时它也可能会做一些像格式化、是否挂载到 GlobalPath 等这样的附加操作。

　　第六步就：绑定操作，就是将已经挂载到本地的 Volume 映射到容器中。例如docker -v

 

PV Controller: 负责 PV/PVC 的绑定、生命周期管理，并根据需求进行数据卷的 Provision/Delete 操作，一个 PV 只能被一个 PVC 绑定，反之亦然

 　　创建好一个 PV 以后，就处于一个 Available 的状态，当一个 PVC 和一个 PV 绑定的时候，这个 PV 就进入了 Bound 的状态，此时如果我们把 PVC 删掉，Bound 状态的 PV 就会进入 Released 的状态。一个 Released 状态的 PV 会根据自己定义的 ReclaimPolicy 字段来决定自己是进入一个 Available 的状态还是进入一个 Deleted 的状态。如果 ReclaimPolicy 定义的是 "recycle" 类型，它会进入一个 Available 状态，如果转变失败，就会进入 Failed 的状态。

　　一个创建好的 PVC 会处于 Pending 状态，当一个 PVC 与 PV 绑定之后，PVC 就会进入 Bound 的状态，当一个 Bound 状态的 PVC 的 PV 被删掉之后，该 PVC 就会进入一个 Lost 的状态。对于一个 Lost 状态的 PVC，它的 PV 如果又被重新创建，并且重新与该 PVC 绑定之后，该 PVC 就会重新回到 Bound 状态。

　　PV Controller 中主要有两个实现逻辑：一个是 ClaimWorker；一个是 VolumeWorker。ClaimWorker 实现的是 PVC 的状态迁移。再看 VolumeWorker 的操作。它实现的则是 PV 的状态迁移。

AD Controller： 负责存储设备的 Attach/Detach 操作，将设备挂载到目标节点；

 　　AD Controller 中有很多 Informer，Informer 会把集群中的 Pod 状态、PV 状态、Node 状态、PVC 状态同步到本地。在初始化的时候会调用 populateDesireStateofWorld 以及 populateActualStateofWorld 将 desireStateofWorld、actualStateofWorld 两个对象进行初始化。在执行的时候，通过 desiredStateOfWorldPopulator 进行数据同步，即把集群中的数据状态同步到 desireStateofWorld 中。reconciler 则通过轮询的方式把 actualStateofWorld 和 desireStateofWorld 这两个对象进行数据同步，在同步的时候，会通过调用 Volume Plugin 进行 attach 和 detach 操作，同时它也会调用 nodeStatusUpdater 对 Node 的状态进行更新。

　　该过程就是根据 desireStateofWorld 和 actualStateofWorld 的对比，再调用底层的接口来执行相应的操作

Volume Manager： 管理卷的 Mount/Unmount 操作、卷设备的格式化以及挂载到一些公用目录上的操作；

　　Volume Manager 是 Kubelet 中一部分，用来做本节点 Volume 的 Attach/Detach/Mount/Unmount 操作。

　　Attach/Detach 操作可以通过 "--enable-controller-attach-detach" 标签（节点标签）进行定义，如果它为 True，则由 AD Controller 来控制；若为 False，就由 Volume Manager 来做

Volume Plugins：它主要是对上面所有挂载功能的实现。PV Controller、AD Controller、Volume Manager 主要是进行操作的调用，而具体操作则是由 Volume Plugins 实现的。

　　Volume Plugins 实际上就是 PV Controller、AD Controller 以及 Volume Manager 所调用的一个库，分为 In-Tree 和 Out-of-Tree 两类 Plugins。它通过这些实现来调用远端的存储，比如说挂载一个 NAS 的操作 "mount -t nfs ***"，该命令其实就是在 Volume Plugins 中实现的，它会去调用远程的一个存储挂载到本地。

　　Kubernetes会在 PV Controller、AD Controller 以及 Volume Manager 中来做插件管理。通过 VolumePlguinMg 对象进行管理。主要包含 Plugins 和 Prober 两个数据结构。Plugins 主要是用来保存 Plugins 列表的一个对象，而 Prober 是一个探针，用于发现新的 Plugin。

Scheduler： 实现对 Pod 的调度能力，会根据一些存储相关的的定义去做一些存储相关的调度。

Flexvolume 是 Volume Plugins 的一个扩展，主要实现 Attach/Detach/Mount/Unmount 这些接口。

　　Flexvolume是可被 Kubelet 驱动的可执行文件，每一次调用相当于执行一次 shell 的 ls 这样的脚本，都是可执行文件的命令行调用，因此它不是一个常驻内存的守护进程。

　　Flexvolume 的 Stdout 作为 Kubelet 调用的返回结果，这个结果需要是 JSON 格式。

　　Flexvolume默认的存放地址为 "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/alicloud~disk/disk"。

CSI 也是为第三方存储提供数据卷实现的抽象接口。

　　Flexvolume 只是给 kubernetes 这一个编排系统来使用的，而 CSI 可以满足不同编排系统的需求，比如 Mesos，Swarm。

　　CSI 是容器化部署，可以减少环境依赖，增强安全性，丰富插件的功能。在 Kubernetes 生态中实现 operator 的时候，经常会通过 RBAC 这种方式去调用 Kubernetes 的一些接口来实现某些功能，而这些功能必须要在容器内部实现，因此像 Flexvolume 这种环境，由于它是 host 空间中的二进制程序，就没法实现这些功能。而 CSI 这种容器化部署的方式，可以通过 RBAC 的方式来实现这些功能。

　　CSI 主要包含两个部分：CSI Controller Server 与 CSI Node Server。Controller Server 是控制端的功能，主要实现创建、删除、挂载、卸载等功能；Node Server 主要实现的是节点上的 mount、Unmount 功能。