云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载Rook 的 Ceph 存储编排通常会在创建CephFilesystem/CephObjectStore自定义资源CR时同步创建并管理底层的 Ceph pool、Ceph 文件系统CephFS等逻辑资源。但对于希望自行管理 pool 的团队Rook 提供了一种外部管理模式在FilesystemSpec与ObjectStoreSpec中省略 metadata/data pool 字段即可让 Rook 只负责运行守护进程容器MDS、RGW而把 pool 与文件系统的生命周期完全交给用户例如由管理员手工创建、或由外部工具编排。本文基于仓库中的设计文档 design/ceph/external-management.md结合当前版本的源码实现讲解这一特性的设计动机、使用方式与底层行为。设计背景为什么需要可选的 Pool 管理在设计文档发布时的 Rook 0.8 版本中创建一个Filesystem或ObjectStore会连带创建对应的 Ceph 文件系统与 pool删除 CR 也会连带删除这些逻辑资源。这种全权托管模型在以下场景成立Ceph 集群的配置完全处于 Rook 可配置的子集范围内且用户不会在带外out of band修改 pool 的配置。但该模型存在三类典型痛点需要使用 Rook 子集之外的 Ceph 功能用户希望先手工创建 pool再让 Rook 仅为文件系统运行守护进程容器MDS pod。需要保留带外修改用户外部修改了 pool 的配置例如副本数希望 Rook 尊重这一新配置而不是在 reconcile 时改回与CephFilesystem设置一致的值。风险规避诉求担心对 Rook 配置的误编辑会永久删除 Ceph pool希望 pool 只能通过带确认提示的命令式接口删除。核心提案pool 字段留空即跳过逻辑资源管理设计文档给出的方案非常简洁当FilesystemSpec以及ObjectStoreSpec中的 metadata 与 data pool 字段留空时Rook 将不对该文件系统/对象存储做任何 Ceph 逻辑资源pool 与 CephFS的管理。同时定义了三个配套语义动态切换pool 字段可以初始为非空、之后改为空。这种情况下即使 Rook 此前已经创建了逻辑资源在删除 Rook 文件系统时也不会删除这些逻辑资源。不可部分管理如果 metadata/data 字段中任意一个非空则两者都必须非空。Rook 不会对一个文件系统或对象存储部分管理其 pool。先决条件省略 pool 后名为myfs的 CephFS 必须已存在于 Ceph 集群中否则 Rook 不会启动任何 MDS pod。改动前后配置对比改动前pool 始终指定apiVersion: ceph.rook.io/v1 kind: Filesystem metadata: name: myfs namespace: rook-ceph spec: metadataPool: replicated: size: 3 dataPools: - erasureCoded: dataChunks: 2 codingChunks: 1 metadataServer: activeCount: 1 activeStandby: true改动后pool 可省略Rook 不创建任何 pool 或 CephFSapiVersion: ceph.rook.io/v1 kind: Filesystem metadata: name: myfs namespace: rook-ceph spec: metadataServer: activeCount: 1 activeStandby: true注意示例中的kind: Filesystem对应设计文档写作时的 CRD 命名在当前仓库中该 CRD 已演进为CephFilesystem见 pkg/apis/ceph.rook.io/v1/types.go实际使用时请以仓库中生成的 CRD 与示例文件为准。源码实现空 pool 判断如何贯穿整个生命周期该设计在当前仓库中已完全落地。以 CephFS 为例判断逻辑统一基于len(fs.Spec.DataPools) ! 0由于 metadata 与 data pool 不可部分指定dataPools 是否为空即可代表整体是否省略创建路径pkg/operator/ceph/file/filesystem.gocreateFilesystem中mds.NewCluster(...).Start()总是先执行MDS 容器照常运行随后仅当len(fs.Spec.DataPools) ! 0时才调用doFilesystemCreate去执行 pool 创建与fs new。删除路径pkg/operator/ceph/file/filesystem.godeleteFilesystem中仅当len(fs.Spec.DataPools) ! 0且PreserveFilesystemOnDelete未设置时才会调用cephclient.RemoveFilesystem从 Ceph 中移除文件系统省略 pool 的 CR 删除时不会触碰任何既有逻辑资源。校验路径pkg/operator/ceph/file/filesystem.govalidateFilesystem中注释明确写道 No data pool means that we expect the fs to exist already无 data pool 意味着我们预期该文件系统已存在直接返回 nil跳过 pool spec 校验与重名校验。这套逻辑经由控制器 pkg/operator/ceph/file/controller.go 的 reconcile 流程validateFilesystem→createFilesystem/deleteFilesystem分别见其中 L356、L502、L512 附近驱动构成校验-创建/删除闭环。对象存储侧的实现对称性设计文档要求ObjectStoreSpec也支持相同的省略语义当前仓库同样已实现ObjectStoreSpec中MetadataPool与DataPool均为可选的PoolSpec见 pkg/apis/ceph.rook.io/v1/types.go。校验时允许空 pool spec因为它们可能已由 ceph mgr 等外部途径创建pkg/operator/ceph/object/rgw.go空判断由EmptyPoolreflect.DeepEqual(pool, cephv1.PoolSpec{})见同文件 L353-L355完成。创建时若 data/metadata pool 为空则只检查 RGW 所需的一组池rgw.control、rgw.meta、rgw.buckets.data等见 pkg/operator/ceph/object/objectstore.go 与CreateObjectStorePools中EmptyPool分支 L799-L812是否已存在缺失即报错绝不代为创建。删除时若两个 pool 字段均为空则跳过 pool 删除pkg/operator/ceph/object/objectstore.go日志明确输出 skipping removal of pools since not specified in the object store。与相关特性的协同preservePoolsOnDelete/preserveFilesystemOnDelete这两组保留开关定义见 pkg/apis/ceph.rook.io/v1/types.go与省略 pool是互补的两条路径——前者在 Rook 已托管 pool 时保留它们后者从一开始就不托管 pool。典型示例见 deploy/examples/filesystem.yaml。外部集群external cluster模式仓库中file/mirror、file/subvolumegroup等控制器对 external 集群采取不删除、由管理员手工管理的策略见 pkg/operator/ceph/file/subvolumegroup/controller.go与本设计Rook 只跑容器、逻辑资源归用户的哲学一致。需要说明的是外部管理省略 pool与外部集群external cluster即 Rook 只编排一个既有 Ceph 集群是两个不同的概念前者关注单个 CR 是否托管逻辑资源后者关注整个集群是否由 Rook 引导创建。迁移与影响评估设计文档明确指出无需迁移。既有文件系统与对象存储在创建时总是显式设置了 pool 字段因此升级后它们仍由 Rook 继续托管行为不变。受影响面仅限于 Rook Operator需要在FilesystemSpec/ObjectStoreSpec的 pool 省略时跳过逻辑资源管理——如上文所示这一逻辑在当前源码的创建、删除、校验三条路径中均已实现。使用建议在配置外部管理模式时请遵循以下实践预先在 Ceph 侧创建好 pool 与 CephFS可用ceph fs new或radosgw-admin再提交省略 pool 字段的 CRmetadata 与 data pool 必须同时省略或同时指定避免出现 Rook 部分托管的情况若后续从托管切换为省略把 pool 字段置空Rook 将放弃对这些逻辑资源的删除权需确认这是预期行为结合PreservePoolsOnDelete、PreserveFilesystemOnDelete等开关可构建托管但保留与从不托管两种渐进式管理策略。通过该特性Rook 成功将运行守护进程容器与管理 Ceph 逻辑资源解耦使需要精细控制 pool 的团队如使用 Rook 子集之外的 Ceph 功能、需要保留带外配置、或要求命令式删除确认的团队也能安全使用 Rook 的编排能力。赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Ceph mgr rook 编排器模块在 Kubernetes 中借助 Rook 统一管理 Ceph 集群Ceph mgr rook 编排器模块在 Kubernetes 中借助 Rook 统一管理 Ceph 集群 本指南讲解 Ceph 的 rook mgr 模块存储分布式文件系统对象存储后端高可用Rook 的 Ceph 配置管理演进从 ceph.conf 到 Ceph 集中式配置存储Rook 的 Ceph 配置管理演进从 ceph.conf 到 Ceph 集中式配置存储 本文基于 Rook 仓库中的设计文档 ceph config upd云原生存储容器编排运维Formula.js测试策略确保函数计算结果准确性的完整指南Formula.js测试策略确保函数计算结果准确性的完整指南 Formula.js作为JavaScript版的Excel公式函数库其 测试策略 对于保证函数数据分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考