记一次cephfs插件(csi)使用的坑

部署了csi插件后，调整configmap配置(csi-config-map-sample.yaml)创建secret(注意指定ceph集群的明文信息)，然后部署storageclass，最后创建pvc测试使用

3.在虚机上压测ceph性能,read达到200M(损耗三分之一)

4.在pod上压测ceph性能，read仅能达到15M。发生了极大的性能损耗

但是使用静态pvc方式，性能和虚机上测试相近，所以我们定为到csi插件可能存在问题

参考文章：

https://github.com/rook/rook/issues/3315

https://github.com/rook/rook/issues/3619

都说 4.17 以前内核的 csi 会用 fuse 的方式使用 ceph fs ，性能不好，升级内核后解决了，并且 storageclass上也说明了挂载的方式mounter: kernel

固我们升级内核版本到4.18，再重新压测，pod性能非常接近虚机性能，解决了csi性能的瓶颈

The node plugin needs direct access to the host for making block devices and/or filesystem mounts available to the Kubernetes kubelet.

The mount point used by the CSI driver must be set to Bidirectional to allow Kubelet on the host to see mounts created by the CSI driver container. See the example below:

在集群中查看

该节点安装了com.seaweedfs.csi的csi插件

kubelet的启动命令中的根目录 --root-dir=/data1/k8s/kubelet

去查看pod对应的挂载信息发现没有挂载 seaweedfs

其中 020bb12f-1da6-11eb-85b5-8446fe72fa77 是pod对应的uid

在节点上也能看到对应的进程

当我在pod中启用

PVC的配置如下

PV如下所示

最终在pod使用时（pod uid=53fe1c36-1ff9-11eb-8a23-b008758cb2a8）

可以看出使用了 kubernetes.io~csi 类型的存储挂载，当挂载成功后显示了挂载的目录

使用命令看到的目录与文件系统上一致

---