社区的同学们，谁来做一下这个特性：client 分离

[heymingwei]

背景

目前 CSI 的 node pod 集成了 cubefs client，当有挂载请求过来时，会启动一个 client 来挂载到对应的位置上，所以当前的架构是 csi 的挂载控制进程和 client 进程在同一个 pod 中。
这就带来了一些问题，比如：

• CSI 无法升级（一旦升级，pod 需要重启，则 client 进程会被 kill，则当前节点无法正常提供存储服务）
• client CPU/Memory 资源无法精准控制（因为所有 client 都在同一个 pod 里，每个 client 需要的资源不一样，所以无法预估整个 pod 的资源）
• 故障域无法隔离（因为所有 client 都在一个 pod 里，所以一旦这个 pod 异常，则这个节点上的业务都会遭遇异常）

而如果将 client 的进程分离出来，则以上问题都会得到更好的解决。

[heymingwei]

挂载卷
总体思路：当有挂载请求过来时，CSI 控制进程在当前节点中生成一个 client pod，用户可以在 pvc 的 yaml 中定义一下这个 client pod 的资源（cpu/memory）。用户每挂载一个 pvc 则生成一个 client pod，如果挂载同一个 pvc 则不会额外再生成一个 client pod，在同一个节点上同一个 pvc 只会有一个 client pod，这样可以达到节约资源的目的。

具体过程如下：
CSI 接到 stage 请求后，查看 pvc 对应的 client pod 是否已经生成；
如果 client pod 已经生成，则直接返回；
如果 client pod 没有生成，则进行创建一个 client pod，镜像信息从 csi controller 上获取，pod 的资源限制信息从 pvc 上获取，如果没有则默认最大1c1g，然后返回；
CSI 接收 publish 请求，查看当前节点对应的 cm 配置中是否已经有此 publish 路径记录；
如果没有 publish 记录，则在 cm 配置中添加上此 pvc 的 publish 记录，接着往下走；
如果已经有 publish 记录，则直接检查 publish 对应的挂载点是否已经是个 mountpoint，如果是，则返回 ok；如果还不是 mountpoint 则返回 busycode，等待下一次 publish 请求的到来；

client pod 生成后，内部会有一个协程间隔获取（1s 一次）当前节点的 cm 记录，与自身的挂载信息进行比对，如果有变动则会进行挂载或者卸载。

当 CSI 挂载控制进程在 cm 配置上添加一条记录后，client pod 通过 cm 对比有所感知，则会将 client 挂载到对应的位置上。

这样整个挂载过程就完成了。

卸载卷
总体思路：当有卸载卷请求过来时，CSI 控制进程会在 cm 上将对应的记录进行删除，client pod 如果发现相关记录已经删除，则将相关挂载点进行卸载，当 CSI 收到 unstage 请求时，则将 client pod 进行删除。

具体过程如下：
CSI 接收到 unpublish 请求后，查看 cm 对应的配置是否已经删除，如果没有删除，则进行删除，如果已经删除，则查看相关挂载路径是否是个 mountpoint，如果不是则返回成功；如果是个 mountpoint 则返回 busycode，等待下一次 unpublish 请求过来。
CSI 接收到 unstage 请求，一般 unstage 请求是所有挂载点都已经清理完毕，k8s 认为当前 pvc 已经没有挂载点了，可以进行最后的清理了。所以这个请求到来后，可以直接将 client pod 进行删除。

因为 client pod 里面会有 cm 挂载记录对比机制，所以它可以根据这个进行卸载相关的挂载点。

[heymingwei]

我来做这个特性吧

[Monkeyman520]

您好，请问这个请求的进度如何，请问我是否可以参与这个 feature 的开发？如果可以，我应该从哪个分支开始？

[heymingwei]

还没开始。你也可以参与的，按照这个思路去做就行。从 master 分支就行。 @Monkeyman520