Rook 文件系统动态供给：从 CephFS 手动卷到 PVC/StorageClass 自动化编排

云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载导读本文围绕 Rook 仓库中的设计文档 dynamic-provision-filesystem.md 展开深入剖析文件系统动态供给Filesystem Dynamic Provisioning这一设计提案的动机、用户经验演进与实现思路。读者将掌握为何要在 Kubernetes 中通过 PVC StorageClass 消费 CephFS、设计文档中描述的rook.io/filesystem外部 provisioner 工作方式以及这一设计在当前 Rook 中如何被 CSI 驱动方案cephfs.csi.ceph.com所落地与演进。背景CephFS 消费的痛点与动态供给的价值在 Rook 早期版本中应用要挂载一个 CephFS 共享文件系统必须直接在 Pod/Deployment 的 volume 定义里手工填写 CephFS 卷插件所需的全部输入包括 monitor 地址、Ceph 用户、密钥引用等。设计文档明确指出其中部分输入非常笨重且需要一些 hacky 的命令才能获取Some of this inputs are very cumbersome and required hacky commands to obtain them。动态供给方案的核心思路是把存储供给职责从应用开发者手中剥离出来交给集群管理员定义的 StorageClass并通过 Kubernetes 原生的 PVC 机制完成消费。设计文档列举了三大收益深度贴合 Kubernetes APIPVC/PV 机制天然带来卷回收策略reclaim policy设置、供给过程的 RBAC 控制、访问模式accessMode定义等能力应用清单与存储类型解耦Pod 只需引用 PVC无论底层换成块存储还是文件系统Pod 清单都无需改动管理员与用户职责分离用户不必关心metadataPool、erasureCoded、亲和性affinity、容忍toleration等底层细节只需创建文件系统 PVC 并引用一个符合需求的 StorageClass。设计文档还追溯了这一概念的社区来源外部存储项目 kubernetes-incubator/external-storage 中的 cephfs 供给器已经实现了类似能力Rook 可以借鉴同一模式社区也通过 issuerook/rook#1125表达了明确诉求。现状体验手动指定 CephFS 卷设计文档用一个 MySQL Deployment 示例展示了改造前的消费体验用户需要在volumes段逐项填写monitors、user、secretRef等信息。apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: strategy: type: Recreate template: spec: containers: - image: mysql:5.6 name: mysql env: - name: MYSQL_ROOT_PASSWORD value: changeme ports: - containerPort: 3306 name: mysql volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage cephfs: monitors: - monitor1 - monitor2 - monitor3 user: admin secretRef: name: rook-admin这种方式的弊端是显而易见的monitor 列表会随集群拓扑变化而变动admin 用户与密钥的获取需要手工操作任何一个参数填错都会导致挂载失败。设计文档的结论是用户必须自己找出这些值并确保每个参数都正确提供。目标体验只用 PVC 消费文件系统引入动态供给后创建文件系统存储只需创建一个 PVC 对象与 Kubernetes 中其他所有存储供给方式保持一致apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myfsdata spec: storageClassName: rook-filesystem-simple path: /myData # 未提供时使用根路径 / accessModes: - ReadWriteMany消费该存储的 Pod 清单则简化为apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: strategy: type: Recreate template: spec: containers: - image: mysql:5.6 name: mysql env: - name: MYSQL_ROOT_PASSWORD value: changeme ports: - containerPort: 3306 name: mysql volumeMounts: - name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: - name: mysql-persistent-storage persistentVolumeClaim: claimName: myfsdata设计文档特别强调了一个关键体验消费方 Pod 清单无论挂载的是文件系统还是块设备看起来都是一样的。这正是动态供给对应用开发者最重要的价值——存储形态的切换不再需要改动应用部署清单。StorageClass管理员定义供给策略PVC 示例中引用的rook-filesystem-simple是一个 StorageClass 对象。动态供给的存储会通过 StorageClass 获取如何供给存储的细节与配置StorageClass 由集群管理员创建。设计文档给出的文件系统 StorageClass 示例如下apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-filesystem-simple provisioner: rook.io/filesystem parameters: fsName: myFS # 要使用的文件系统名称其中被引用的文件系统myFS需要管理员通过 CephFilesystem CRD 预先创建。例如一个具备更高可用性HA的rook-filesystem-goldapiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-filesystem-gold provisioner: rook.io/filesystem parameters: fsName: mySuperHAFS通过定义多个 StorageClass 对象管理员可以为用户提供多种文件系统选项用户按需引用与自身需求匹配的 StorageClass 即可。实现方案基于 external-provisioner 的供给器设计文档给出了实现思路复用 Kubernetes 生态的 external-provisioner 控制器来监听 PVC 对象——Rook 当时已经在块设备供给中使用了该控制器。实现逻辑与块设备供给高度类似监听 PVCprovisioner 监听类型为rook.io/filesystem的 PVC 对象解析参数PVC 创建时provisioner 从 StorageClass 中解析文件系统信息如fsName创建卷源根据解析结果构造包含全部所需信息的 volume source如path、monitors、user、secretRef等回收清理PVC 被删除时对应的文件系统底层组件mds、data pools 等随之删除。当前演进设计落地为 Ceph CSI 动态供给值得说明的是这份设计文档提出的rook.io/filesystem独立 provisioner 方案在当前 Rook 代码库中已被更为成熟的Ceph CSI 驱动方案取代——CephFS 的动态供给能力由cephfs.csi.ceph.com驱动提供。从源码看Rook 的 CSI 配置在 pkg/operator/ceph/csi/config.go 中定义了cephFSDriverSuffix cephfs.csi.ceph.comconfig.go并在 pkg/operator/ceph/csi/secrets.go 中为 CephFS 供给器创建专用的 Ceph 用户client.csi-cephfs-provisionersecrets.go。这一演进保留了设计文档的所有核心理念——PVC 驱动的消费体验、StorageClass 承载供给策略、管理员与用户职责分离——但将供给实现从自定义 external-provisioner 迁移到了标准 CSI 架构。设计文档中复用 external-provisioner 控制器的思路与 CSI 架构中 sidecar 容器如csi-provisioner承担的角色在思想上一脉相承。当前的 StorageClass 形态Rook 当前示例仓库中的 CephFS StorageClass 位于 deploy/examples/csi/cephfs/storageclass.yaml相比设计文档的极简形态它承载了完整的 CSI 供给参数apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-cephfs provisioner: rook-ceph.cephfs.csi.ceph.com # csi-provisioner-name parameters: # clusterID 是 rook 集群所在命名空间 clusterID: rook-ceph # namespace:cluster # 卷将创建于其中的 CephFS 文件系统名称 fsName: myfs # 卷将创建于其中的 Ceph pool # provisionVolume: true 时必填 pool: myfs-replicated # 密钥包含 Ceph admin 凭据由 operator 自动生成于集群同一命名空间 csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph # namespace:cluster csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph # namespace:cluster csi.storage.k8s.io/controller-publish-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/controller-publish-secret-namespace: rook-ceph # namespace:cluster csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph # namespace:cluster # (可选) 设为 true 以使用 KMS 中的密钥加密每个卷 # encrypted: true # (可选) 通过指定与 KMS ConfigMap 匹配的唯一 ID 使用外部 KMS 加密 # encryptionKMSID: kms-config-id # (可选) 驱动可使用 ceph-fuse (fuse) 或 ceph 内核客户端 (kernel) # mounter: kernel reclaimPolicy: Delete allowVolumeExpansion: true mountOptions: # uncomment the following line for debugging #- debug可以看到fsName参数从设计文档一路沿用到 CSI 时代provisioner的命名从rook.io/filesystem演变为带集群命名空间前缀的namespace.cephfs.csi.ceph.com。这与设计文档管理员定义 StorageClass、用户按需引用的职责划分完全一致。当前的 PVC 形态对应的 PVC 示例位于 deploy/examples/csi/cephfs/pvc.yaml--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: cephfs-pvc labels: group: snapshot-test spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: rook-cephfs相比设计文档的 PVC 示例当前实现取消了 PVC 上的path字段挂载子路径改为通过 VolumeMount 的subPath等机制处理并增加了resources.requests.storage容量声明——CephFS 的 CSI 驱动会通过目录配额quota来落实该容量上限参见 filesystem-storage.md 的 Quotas 章节。完整实操路径从 CephFilesystem 到 PVC综合当前仓库文档 filesystem-storage.md 与 ceph-csi-drivers.md一条完整的文件系统动态供给链路如下创建底层文件系统通过 CephFilesystem CRD 创建myfs定义 metadataPool、dataPools 与 MDS 配置示例见 filesystem.yaml等待 MDS 就绪kubectl -n rook-ceph get pod -l approok-ceph-mds确认 mds 实例 Running创建 StorageClass应用 deploy/examples/csi/cephfs/storageclass.yaml指定clusterID、fsName与密钥引用创建 PVC应用 deploy/examples/csi/cephfs/pvc.yaml声明访问模式与容量应用消费 PVCPod 中通过persistentVolumeClaim.claimName引用 PVC即可完成挂载。这套链路正是设计文档愿景的最终实现用户层面只面对PVC StorageClass两个抽象底层 CephFS 的 pool、MDS、monitor 等细节全部由 Rook operator 与 CSI 驱动透明处理。小结dynamic-provision-filesystem.md是一份典型的体验驱动设计文档先指出手工 CephFS 卷的痛点再给出 PVC 化的目标体验最后落到 external-provisioner 的实现草图。它提出的PVC 消费 StorageClass 配置 供给/回收自动化框架最终在 Rook 中以 Ceph CSI 驱动的形式完整落地并延续了fsName等核心参数的语义。对于希望理解 Rook 文件系统存储设计脉络的读者这篇设计文档与当前 filesystem-storage.md、ceph-filesystem-crd.md 及 cephfs 示例目录 互为补充构成从设计到实践的全景视图。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Kubespray 如何启用 AWS EBS CSI Driver 并验证 StorageClass 与 PVC 动态供给Kubespray 如何启用 AWS EBS CSI Driver 并验证 StorageClass 与 PVC 动态供给 如果你的 Kubernetes 集云原生容器编排DevOps运维终极免费离线绘图工具draw.io桌面版完全使用指南终极免费离线绘图工具draw.io桌面版完全使用指南 还在为网络不稳定而无法绘制专业图表烦恼吗draw.io桌面版为你提供了完美的离线绘图解决方案。这款基于桌面应用图形学Parselmouth核心功能解析Praat算法的Pythonic实现Parselmouth核心功能解析Praat算法的Pythonic实现 Parselmouth是一个将Praat算法以Pythonic方式实现的强大工具库它创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考