cephfs目录共享给多个pod使用

Posted 2023-05-16

参考技术A

本篇文章将介绍如何将cephfs的一个目录共享给多个pod使用，更进一步，多个pod之间虽共享一个目录，但可以隔离使用。

写这篇文章的起因是业务部门有多个云原生应用同时产生日志。这些日志放到一个大的目录下管理比如logs/，并且不同的应用所产生的日志存放在不同的目录下。

k8s访问cephfs的方式之一便是通过ceph-csi访问。ceph-csi提供了动态和静态的方式。

静态方式 由存储管理员显式地创建pv，开发者通过pvc获得符合容量要求和访问模式的pv，并和pod关联，达到使用存储的要求。但这样存在一些弊端，比如需要使用不同的pv时，管理员要分别手动构建pv。

动态方式 存储管理员不需要显式地创建pv，而是创建storageClass。由开发者声明pvc，由storageClass生成合适的pv。但是pv关联的路径使用uuid规则创建，如需将后台存储的目录和pod对应并不是很直观。

搭建了一个minikube的k8s系统环境（版本V1.21.0）和ceph存储(版本16.2.4)，完成ceph-csi的配置。

不需要配置storageClass。只需要配置一个pv、一个pvc和两个pod。

在cephfs后端创建一个可使用的子卷，实质上是在cephfs内的/volumes（该目录是ceph-csi默认使用的目录）下面创建一系列子目录用来共享。

首先创建一个子卷的组（相当于创建一个上层目录，后面的子卷都是该目录下的子目录）。命令如下：

该命令的源格式为：

这条命令简单的效果是在cephfs后台会创建一个 /volumes/data 的路径。以后所有属于该组的子卷都在该目录下。

然后创建一个子卷名称为data，该卷的大小为1GB大小，size的单位是bytes。命令如下：

该命令的源格式为：

文件系统后台实际创建 /volumes/data/logs/dda798fb-2160-4aca-b810-3bbf7bbdd394 ，即在子卷下面还有一个子目录，目录使用uuid命名。该uuid命名的目录配置了和size一致的配额。即pv的大小。

该pv文件名称为 cephfs-static-pv1.yaml 。pv里的内容：

1、 storageClassName: standard ，如果不加该句，pvc在apply之后会一直处于pending状态，通过describe pvc 可以看到 “Cannot bind to requested volume storageClassName: does not match” 的消息。官方文档少了这条说明。
2、 persistentVolumeReclaimPolicy: Retain ，当pvc被释放后，PV将会被保留（不清理和删除）。
3、rootPath可以通过getpath命令获取： ceph fs subvolume getpath cephfs logs data ，源命令格式为 ceph fs subvolume getpath <文件系统名称> <子卷名称> <子卷组> 。获取命令的结果带来uuid的子目录，这个uuid目录是带配额的，该配额和pv中描述的大小一致。
4、删除pv和pvc不会删除文件系统后台的子卷，需要额外执行命令删除。

应用该静态pv

结果

在pod创建前创建pvc，该pvc名称为cephfs-static-pvc1.yaml。volumeName和以上创建的pv相对应。

应用该pvc

查看所创建的pvc

创建两个pod分别使用 logs/data/dda798fb-2160-4aca-b810-3bbf7bbdd394 目录下面的 dir4 目录和 dir5 目录。每次在创建pod的时候需要指定一个subPath。

第一个pod配置，指定使用dir4目录。

使用volumeMounts中的参数 subPath 。 subPath 在实际存储后端会建立一个子目录，可以使容器在挂载数据卷时指向数据卷内部的一个子路径，而不是直接指向数据卷的根路径。第二个pod配置。指定使用dir5目录。

两个pod创建后，在ceph后台可以看到路径如下

查看挂载情况

在两个pod内各创建一个文件

使用查看命令，可以看到每个pod的 /var/lib/www 中只有自己创建的内容。

cephfs文件系统后端也分别在两个目录内创建了对应的文件

创建一个storageClass和pvc，这里省去两个pod的创建过程。

动态的storageClass配置如下：

pvc的配置

在底层文件系统中展现的结构 /volumes/csi/csi-vol-<uuid>/<uuid> 两次uuid的值不相同。

pod创建过程类似，修改 claimName 内的pvc内容。

动态的方式使用uuid分配，底层路径和pod之间的关系不那么明显，使用静态卷+subPath的方式能够预知到所使用的路径，也做到了应用之间的隔离。

目前发现的一个问题是无论用kernel方式还是fuse方式挂载，在一个Node上对应某个卷的挂载点只有一个，多个pod会同时访问一个客户端程序。可能造成caps过多，性能竞争的问题。（以下是通过 ceph daemon session ls 查看到的结果。在我的例子中两个pod共用一个ceph-fuse客户端）

CephFS Provisioner出现 Input/Output Error

k8s版本：v1.13.0-rc.1
ceph版本：luminous 12.2.10
node节点内核版本：centos7 3.10.0-862.el7.x86_64

问题：使用external-storage提供的CephFS Provisioner出现pod无法挂载pvc的问题
查看相关节点kubelet的日志发现如下错误

解决方法：升级centos7系统内核至4.18.9-1.el7.elrepo.x86_64问题解决
参考链接：
https://github.com/kubernetes-incubator/external-storage/issues/345