云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载导读本文基于 Rook 仓库中的设计文档 design/ceph/ceph-volume-provisioning.md 展开系统阐述 Rook 如何放弃自研的 OSD 供给provisioning逻辑转而以 Ceph 官方镜像内置的ceph-volumeCLI 作为 OSD 配置与启动的底层引擎并配合设计文档 design/ceph/dedicated-osd-pod.md 所确立的一个 OSD 一个 Pod模型形成Operator 编排 Provision Job 准备 Deployment 激活的完整流水线。读完本文你将掌握Rook 中 OSD 从设备发现到ceph-osd启动的完整时序、ceph-volume lvm batch与ceph-volume lvm activate的实际调用方式、通过 Cluster CRD 配置多 OSD 单盘、LVM 直供、dmcrypt 加密等新特性的方法以及 Rook 如何在多版本 Ceph 混跑场景下做能力探测与向后兼容。一、背景Legacy 自研供给的痛点在采用ceph-volume之前Rook 自己实现 OSD 供给逻辑复杂度集中体现在四个方面见设计文档 Legacy Design 一节Bluestore 设备分区需要自行对设备进行分区metadata 设备编排当 WAL 与 DB 位于独立设备与数据盘分离时需要自行完成分区和配置目录与设备的双轨支持既支持目录directory又支持裸设备deviceBluestore 与 Filestore 双存储后端两种 store 类型都要支持。这些能力大多已经被ceph-volume覆盖。因此设计文档的核心结论是Rook 应移除自身的供给代码完全依托ceph-volume来配置和运行 Ceph OSD。从当前仓库源码可以印证这一演进方向。供给逻辑集中实现在 pkg/daemon/ceph/osd/volume.go其中configureCVDevices()是供给入口它内部依据设备类型与配置拆分为 raw 模式initializeDevicesRawMode与 LVM 模式initializeDevicesLVMMode两条路径最终统一调用ceph-volume完成准备再无自研分区逻辑。二、ceph-volume 供给流程设计ceph-volume是ceph/ceph镜像内置的 CLI 工具负责配置并运行 Ceph OSD。设计文档指出引入ceph-volume后顶层流程与 one-osd-per-pod 设计 中 Create new OSDs 一节保持一致不需要额外新增 Job 或 Pod。OSD 供给的事件序列如下Cluster CRD 指定要在哪些节点/设备上配置 OSDOperator 在需要配置 OSD 的每个节点上启动一个 provisioning Jobprovisioning Job 负责检测应配置哪些设备调用ceph-volume lvm batch在节点上准备 OSD。默认用一条命令携带所有设备除非针对 LVM 和分区有更具体的设置调用ceph-volume lvm list获取 OSD 配置结果并将结果存入 ConfigMap交给 Operator 做下一步Operator 为每个已供给的 OSD 启动一个 Deployment容器入口点为rook加载记录 OSD 配置的 ConfigMap包含 ID、FSID、bluestore/filestore 等信息调用ceph-volume lvm activate激活 OSD它会挂载配置目录如/var/lib/ceph/osd-0并使用 tempfs 挂载。必要时向命令传递--bluestore、--filestore、OSD_ID、OSD_FSID等参数通过ceph-osd启动 OSD 守护进程当ceph-osd退出时rook随之退出Pod 由 Kubernetes 自动重启。2.1 源码中的供给 Job 实现设计文档描述的 provisioning Job 在当前仓库中的落地位置是 pkg/operator/ceph/cluster/osd/provision_spec.gomakeJob()为每个待供给节点构建batch.JobJob 名称由provisionJobName()生成并使用NodeSelector将 Job 绑定到目标节点provisionPodTemplateSpec()挂载宿主机/devdevices卷、/run/udevudev卷非 PVC 场景还会挂载宿主机根文件系统rootfs用于在容器内校验宿主机是否安装了 LVM 包provisionOSDContainer()生成名为provision的容器命令为rook ceph osd provision镜像即spec.cephVersion.imageCeph 镜像内含ceph-volume。供给容器以 privileged 方式运行privileged: true、runAsUser: 0这是因为它必须直接访问宿主机/dev下的块设备。加密场景下Pod 还会设置HostIPC true源码注释说明ceph-volume --dmcrypt使用的cryptsetup会通过信号量与宿主机 udev 同步。2.2 源码中的设备发现与可用性判定Provision()见 pkg/daemon/ceph/osd/daemon.go首先做硬件发现非 PVC 场景下仍以lsblk为底层手段clusterd.DiscoverDevicesWithFilter源码注释明确指出理想情况下应改用ceph-volume inventory但它存在无法暴露可用分区和 LV 等限制对应 Ceph tracker issue 43579故未采用。随后getAvailableDevices()依据以下规则过滤设备已挂载Mountpoint非空的设备跳过带文件系统签名的设备跳过crypto_LUKS与mpath_member在 PVC 场景下例外已检测到 bluestore 签名bluestore block device见getOsdUUIDImpl的设备视为已有 OSD 而跳过分区设备会通过 udev 信息PopulateDeviceUdevInfo补全元数据。可见 检测设备 这一步在 Rook 侧与ceph-volume侧是分工的设备筛选由 Rook 基于lsblk/udev 完成设备制备prepare与结果列举list由ceph-volume完成。2.3 源码中的激活与守护进程启动设计文档描述的 activate ceph-osd 流程在StartOSD()pkg/daemon/ceph/osd/daemon.go中有精确对应// 创建配置挂载目录 /var/lib/ceph/osd/ceph-osdID // PVC 场景先 vgchange -an / -ay 切换卷组激活状态 // 然后激活 OSD ceph-volume, lvm, activate, --no-systemd, storeFlag, osdID, osdUUID // 最后启动守护进程 ceph-osd, cephArgs...storeFlag形如--bluestore由StoreConfig.GetStoreFlag()生成见 pkg/operator/ceph/cluster/osd/config/config.go与设计文档中 OSD options 如--bluestore、--filestore按需传递 的描述一致。ceph-osd退出后StartOSD返回容器进程结束Pod 由 Kubernetes 重启——这正是设计文档第 4 步的行为。三、ceph-volume 带来的新特性设计文档明确ceph-volume为 Rook 带来三项新能力单设备多 OSD一个设备上可以运行多个 OSD特别适合 NVME 这类高性能设备LVM 上的 OSD既可以消费已有 LVM 逻辑卷也可以在裸设备上自动配置 LVMdmcrypt 加密对 OSD 数据进行 dmcrypt 加密。3.1 新特性在源码中的落地形态当前源码中StoreConfigpkg/operator/ceph/cluster/osd/config/config.go承载了这些特性对应的配置键配置键StoreConfig 字段说明osdsPerDeviceOSDsPerDevice单盘 OSD 数量默认 1仅允许设置为 ≥1 的值encryptedDeviceEncryptedDevice是否用 dmcrypt 加密字符串true才生效metadataDeviceMetadataDevice指定非旋转介质作为 bluestore 的 block.db 设备deviceClassDeviceClass设备对应的 CRUSH device classwalSizeMBWalSizeMBWAL 大小MBdatabaseSizeMBDatabaseSizeMBDB 大小MBinitialWeightInitialWeightOSD 初始 CRUSH weightprimaryAffinityPrimaryAffinityOSD primary affinitystoreTypeStoreType存储后端见下文storeType支持的值定义在 pkg/apis/ceph.rook.io/v1/storage.gobluestore默认与bluestore-rdr。设计文档成文年代还存在 filestore 选项但当前仓库已不再提供 filestoreIsValidStoreType()只认可 bluestore 系列这与设计文档 目录支持将逐步淘汰 的方向一致。3.2 底层命令参数对照ceph-volume调用集中在 pkg/daemon/ceph/osd/volume.go 顶部定义的常量中可与设计文档的新特性逐一对应osdsPerDeviceFlag --osds-per-device crushDeviceClassFlag --crush-device-class encryptedFlag --dmcrypt databaseSizeFlag --block-db-size dbDeviceFlag --db-devices cephVolumeCmd ceph-volume cephVolumeMinDBSize 1024 // 1GBLVM 模式initializeDevicesLVMMode基础命令为ceph-volume --log-path path lvm batch --prepare --bluestore --yes加密时追加--dmcrypt无 metadata 设备的场景为每个设备单独追加--osds-per-device N与设备路径并支持--report预演校验有 metadata 设备时把多个数据设备聚合为一次 batch 调用追加--db-devices mdPath整盘/LV 场景或退回lvm prepare --data ... --block.db ... --block.db-size ...分区场景。Raw 模式initializeDevicesRawMode基础命令为ceph-volume raw prepare --bluestore逐设备追加--data device同样支持--osd-idOSD 迁移恢复与--crush-device-class。结果列举GetCephVolumeLVMOSDs执行ceph-volume lvm list lv --format jsonGetCephVolumeRawOSDs执行ceph-volume raw list [block] --format json解析出osd_id、osd_uuid、ceph_fsid、设备路径、store 类型等信息最终封装为oposd.OSDInfo交由 Operator 创建 Deployment。值得注意的细节设计文档描述的lvm list在实现中已被扩展为同时支持lvm list与raw list两套列举供给结果也不是写入独立 ConfigMap而是通过 OrchestrationStatus 记录UpdateNodeOrPVCStatusOperator 据此获知每个节点/PVC 上已生成的 OSD 集合。此外volume.go中的ensurePreparedDevicesListed()会对刚 prepared 却未出现在 raw list 结果中的设备逐个补查ceph-volume raw list device规避 Ceph 20.2.x 在 udev 数据未填充或存在亚 4KiB 块设备时 list 结果为空的问题防止 prepare Job 静默少报 OSD。3.3 raw 模式与 LVM 模式的选择规则源码中的allowRawMode()与isSafeToUseRawMode()揭示了两种模式的边界raw 模式不支持加密EncryptedDevicetrue时禁用raw 模式不支持单盘多 OSDosdsPerDevice 1时禁用raw 模式不支持非 PVC 场景下的整盘 metadata 设备raw 模式不支持 LVM 逻辑卷设备出于内核 Atari 分区误报问题Ceph 16.2.6 时对整盘禁用 raw 模式见 pkg/daemon/ceph/osd/volume.go 中相关注释与 issue 7940 的引用。由于设计文档重点描述的lvm batch路径仍在广泛使用LVM 模式的lvmPreReq()还会在宿主机上校验lvm2包是否存在并通过UpdateLVMConfig()改写/etc/lvm/lvm.conf关闭udev_sync/udev_rules/use_lvmetad打开allow_changes_with_duplicate_pvsPVC 场景下把扫描范围限定为/mnt并设置设备 filter。四、Cluster CRD 中的新配置项设计文档给出了两个层次的配置示例全局storage.config与节点/设备级storage.nodes。这些示例必须完整保留因为它们是新特性对用户暴露的全部入口。4.1 全局配置storage: config: # whether to encrypt the contents of the OSD with dmcrypt encryptedDevice: true # how many OSDs should be configured on each device. only recommended to be greater than 1 for NVME devices osdsPerDevice: 1 # the class name for the OSD(s) on devices crushDeviceClass: ssd4.2 节点/设备级配置当需要比裸设备更灵活的布局时可以在指定节点上使用 LVM 或分区名。以下属性同时适用于 bluestore 与 filestore OSDstorage: nodes: - name: node2 # OSDs on LVM设计文档遗留的开放问题logicalDevice 设置需要在 0.9 之后重新评估 # 以及是否应归入更通用的 storage node config 设置之下 logicalDevices: # bluestore: DB、WAL、Data 位于各自独立的 LV - db: db_lv1 wal: wal_lv1 data: data_lv1 dbVolumeGroup: db_vg walVolumeGroup: wal_vg dataVolumeGroup: data_vg # bluestore: DB、WAL、Data 位于同一个 LV - volume: my_lv1 volumeGroup: my_vg # filestore: data 与 journal 位于同一个 LV - data: my_lv2 dataVolumeGroup: my_vg # filestore: data 与 journal 位于不同的 LV - data: data_lv3 dataVolumeGroup: data_vg journal: journal_lv3 journalVolumeGroup: journal_vg # 设备同时支持 filestore 与 bluestore 配置取决于 config.storeType 设置 # 可在全局、节点或设备级设置 devices: # OSD on a raw device - name: sdd # OSD on a partition分区支持是新增能力 - name: sdf1 # Multiple OSDs on a high performance device - name: nvme01 config: osdsPerDevice: 5设计文档对上述 LVM/分区选项的态度非常坦诚并保留了几个开放问题在这个复杂度层级下它是否真的有用用户是否有更简单的 LVM 配置方式用户真的需要如此多的灵活性吗选项过多会给维护带来负担。这些问题的演进结果可以从当前仓库得到部分答案目录directory供给在新版本中已不再是主流路径storeType只保留 bluestore 系而设计文档中的logicalDevices设想并未直接成为今天的 CRD 字段取而代之的是devices含metadataDevice、databaseSizeMB、osdsPerDevice、deviceClass等按设备覆盖配置以及基于 PVC 的storageClassDeviceSets。读者可对照 deploy/examples/cluster.yaml 中storage.config的注释示例storage: # cluster level storage configuration and selection useAllNodes: true useAllDevices: true config: # crushRoot: custom-root # specify a non-default root label for the CRUSH map # metadataDevice: md0 # specify a non-rotational storage so ceph-volume will use it as block db device of bluestore. # databaseSizeMB: 1024 # uncomment if the disks are smaller than 100 GB # osdsPerDevice: 1 # this value can be overridden at the node or device level # encryptedDevice: true # the default value for this option is false # deviceClass: myclass # specify a device class for OSDs in the cluster nodes: # - name: 172.17.4.201 # devices: # - name: sdb # - name: nvme01 # multiple osds can be created on high performance devices # config: # osdsPerDevice: 5 # - name: /dev/disk/by-id/ata-ST4000DM004-XXXX # devices can be specified using full udev paths # config: # configuration can be specified at the node level which overrides the cluster level config # - name: 172.17.4.301 # deviceFilter: ^sd.4.3 配置优先级配置的作用域优先级在 pkg/apis/ceph.rook.io/v1/storage.go 的ResolveNode()注释中有明确约定节点级节点自身定义的 config优先级最高集群级storage.config次之默认值兜底。具体实现为resolveNodeConfig()遍历父作用域集群的 config凡是节点未显式定义的键就把集群级值补入节点 config。设备级覆盖则在StoreConfig.ToStoreConfig()与appendDeviceClassArg()等处体现例如osdsPerDevice在设备级被单独解析并覆盖全局值见initializeDevicesLVMMode中device.Config.OSDsPerDevice 1的判定。设备级deviceClass也会优先于节点/全局deviceClass生效。五、向后兼容策略设计文档明确指出 Rook 必须继续支持集群中已存在的各种类型 OSDv0.8 时代创建的 OSD无论是 filestore 还是 bluestore、运行在目录还是设备上在升级到 v0.9 及以后都必须持续运行。由于ceph-volume只支持处理此前未被 Rook 配置过的设备兼容策略如下CRD 中指定directory时Rook 继续直接供给 OSD在目录上创建新 OSD 的支持将被弃用。目录可能仍用于测试场景但不再是主线场景。Legacy 设计中目录常被用于 LVM 之上而现在 LVM 已被直接支持。v0.9 中目录支持仍然保留但文档会引导用户改用设备供给对 Rook 已配置的存量设备跳过ceph-volume按旧方式启动 OSD新设备一律用ceph-volume供给。当前仓库对这条策略的延续体现在两处一是getAvailableDevices()会对已带 bluestore 签名的设备直接跳过避免重复供给二是configureCVDevices()的幂等检查——当设备列表为空说明设备此前已 prepared时不再执行 prepare而是直接通过ceph-volume lvm list/raw list返回既有 OSD 信息。这与存量设备不再走 prepare 流程的兼容目标一脉相承。六、版本检测如何判定镜像内 ceph-volume 的能力Rook 依赖的ceph-volume功能非常新luminous 与 mimic 早期版本尚不具备。例如 Rook 需要执行ceph-volume lvm batch --prepare devices其中batch命令与--prepare标志都是较晚才加入的。虽然最新的ceph-volume改动很快会被合入 luminous 与 mimicRook 仍需知道自己运行的镜像是否包含所需功能。设计文档给出的探测方案是用全部所需标志运行命令但不传任何设备以规避测试时的副作用ceph-volume lvm batch --prepare判定规则若标志受支持ceph-volume退出码为0若标志不受支持ceph-volume退出码为2。由于 Rook 要编排不同版本的 Ceph它至少初期必须能运行那些ceph-volume功能不完整的镜像。当未检测到受支持的ceph-volume版本时Rook 回退执行 legacy 代码供给设备。从当前源码看这条 版本探测 回退 的设计已经演进为更精细的能力分层不再以单一命令探测整体能力而是按特性逐项决策——raw 模式是否可用由allowRawMode()依据加密、osdsPerDevice、metadata 设备等因素判定无法使用 raw 模式的设备自动落到 LVM 模式LVM 模式又区分整盘 batch、--db-devicesbatch、分区lvm prepare等不同命令形态。无论走哪条路径最终对 Ceph 版本的适配都统一收敛到对ceph-volume的稳定调用上这正是设计文档 replace own provisioning code and rely on ceph-volume 的长期目标。七、延伸阅读设计文档原文design/ceph/ceph-volume-provisioning.md一 OSD 一 Pod 的顶层流程design/ceph/dedicated-osd-pod.mdceph-volume 调用的核心实现pkg/daemon/ceph/osd/volume.goOSD 激活与守护进程启动pkg/daemon/ceph/osd/daemon.goprovisioning Job 的 Pod 规格生成pkg/operator/ceph/cluster/osd/provision_spec.goStoreConfig 与配置键定义pkg/operator/ceph/cluster/osd/config/config.goStoreTypebluestore/bluestore-rdr与配置优先级pkg/apis/ceph.rook.io/v1/storage.go可复制的集群级配置示例deploy/examples/cluster.yaml赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook 文件系统动态供给从 CephFS 手动卷到 PVC/StorageClass 自动化编排Rook 文件系统动态供给从 CephFS 手动卷到 PVC/StorageClass 自动化编排 导读 本文围绕 Rook 仓库中的设计文档 dynamic云原生存储容器编排运维OneUptime SCIM 2.0 身份供给集成指南项目与状态页的用户自动供给、取消供给及 Entra ID / Okta 配置OneUptime SCIM 2.0 身份供给集成指南项目与状态页的用户自动供给、取消供给及 Entra ID / Okta 配置 OneUptime 是一款可观测性后端运维前端云原生微服务AI AgentCeph ceph-volume simple activate 详解接管已部署 OSD 的激活机制与实战操作Ceph ceph volume simple activate 详解接管已部署 OSD 的激活机制与实战操作 导读 本文围绕 Ceph 官方文档 doc/c存储分布式文件系统对象存储后端高可用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考