Rook Ceph
Rook-Ceph 练习指南
Rook-Ceph 上手指南，针对纯小白编写！
本指南面向完全没有 Ceph 与分布式存储经验的同学，旨在帮助大家快速了解并实际操作 Rook-Ceph。
一、前置背景
在深入实践 Rook-Ceph 之前，我们有必要从根本上理解两个关键概念：Ceph 和 Rook-Ceph。它们分别代表了分布式存储系统的核心能力与 Kubernetes 上的自动化运维方案。
1. Ceph
Ceph 是一个开源的分布式存储系统，最初由 Sage Weil 发起，旨在解决大规模存储环境下的数据一致性、可用性与扩展性问题。与传统的集中式存储方案不同，Ceph 不依赖单点控制器，而是构建在对等节点之间的协作基础上。Ceph 的核心设计目标包括：
- 高可扩展性：支持从数 TB 到数 PB 的存储容量增长；
- 高可用性与容错性：通过副本或纠删码机制保障数据在节点宕机时依然可用；
- 统一存储模型：同时支持块设备（Block）、对象存储（Object）和文件系统（File）的访问方式。
Ceph 集群主要包含以下核心组件
| 组件 | 作用说明 |
|---|---|
| MON（Monitor） | 维护集群状态、健康检查、选主等元数据服务 |
| OSD（Object Storage Daemon） | 负责数据的真正读写、复制、恢复等核心功能 |
| MGR（Manager） | 提供监控、统计与插件扩展能力 |
| MDS（Metadata Server，可选） | 支持文件系统时用于管理目录树元数据 |
一个 Ceph 集群通常需要 3 个以上 MON 保证选主安全，多个 OSD 挂载在各节点物理磁盘上，共同提供数据存储能力。
2. Rook-Ceph
Rook 是一个基于 Kubernetes 的存储编排器（Operator），其目标是让用户像管理 Pod 一样管理存储系统。Rook-Ceph 是其最成熟、最广泛应用的后端之一，用于简化 Ceph 在 Kubernetes 上的部署与管理过程。
Rook-Ceph 把 Ceph 的部署与维护抽象为一组 Kubernetes 的自定义资源（Custom Resources），包括
| 自定义资源 | 说明 |
|---|---|
CephCluster | 表示一个完整的 Ceph 集群声明 |
CephBlockPool | 管理 Ceph 的 RBD 块存储池 |
CephFilesystem | 管理 Ceph 文件系统 |
CephObjectStore | 管理对象存储桶服务 |
通过 Operator 模式，Rook 实现了 Ceph 集群的部署、升级、故障恢复、扩缩容等生命周期管理，大大降低了传统 Ceph 安装过程的复杂性。
3. 在 Kubernetes 中使用 Ceph
Kubernetes 原生并不提供真正意义上的持久化存储。如果一个 Pod 绑定的 PVC（PersistentVolumeClaim）没有一个可靠的后端，就无法实现高可用、跨节点、自动恢复的存储能力。而 Ceph，特别是通过 Rook 集成的 Ceph，正好弥补了这个空缺。
- 可靠的数据持久化存储；
- 弹性扩展能力；
- 支持高可用的块设备和共享文件系统；
- Kubernetes 原生支持 CSI 插件与 StorageClass 动态供给。
Rook-Ceph 可以构建真正可用的云原生存储方案。
二、学习路径
Ceph 和 Rook-Ceph 涉及内容繁杂，对于入门者来说，初期的最大困难不在于缺少资料，而在于资料太多且不具备系统性、递进性。为提高效率、避免低效踩坑，建议将学习路径分为三个阶段，并着重在实践中建立对相关工具的认识。
1. 阶段一：概念建立
推荐资源
- 官方文档：https://rook.github.io/docs/rook/latest-release/Getting-Started/intro/
- 中文科普：B 站搜索 Ceph 入门系列
- ChatGPT 等查询术语
关键目标：理解 Ceph 与 Rook-Ceph 的设计动机与关系，理清核心组件职责
| 需要理解的问题 | 推荐提问方式示例 | 为什么重要 |
|---|---|---|
| Ceph 是为了解决什么问题而诞生的？ | 简要介绍 Ceph 与传统集中式存储系统的根本区别。 | 明确 Ceph 分布式 + 容错 + 去中心化的核心思想。 |
| Ceph 和 Rook-Ceph 是什么关系？ | 在 K8s 用 Rook-Ceph 是在使用 Ceph 吗？Rook 起了什么作用？ | 了解 Rook 封装了 Ceph 的运维逻辑这一概念，避免混淆两者。 |
| Ceph 的核心组件有哪些？各自负责什么？ | 说明 MON、OSD、MGR、MDS 在 Ceph 中的职责和交互。 | 明确后续所有的命令操作和故障排查入口。 |
| 什么是 RBD、对象存储、文件系统？在 Kubernetes 中用的是哪一种？ | 在 Kubernetes 使用 PVC 时，是走 Ceph 的块存储还是别的形式？ | 明确 Ceph 是块存储还是涉及云盘等其他概念。 |
| 为什么在 Kubernetes 中部署 Ceph 要用 Rook？ | 不通过 Rook，是否也能直接部署 Ceph？差别是什么？ | 理解 Kubernetes 与传统架构的差异，特别是声明式资源这一思想。 |
2. 阶段二：环境熟悉
基本目标
- 学会在 K8s 中进入 toolbox，执行基本诊断与状态命令；
- 能阅读并理解 ceph status、osd tree 等命令的含义；
- 初步学会使用 kubectl 管理 Rook 的资源对象。
关键目标：理解 Rook-Ceph 部署后集群中有哪些资源，掌握 toolbox 与 K8s 对象之间的连接关系，能独立完成基础查询
| 需要理解的问题 | 推荐提问方式示例 | 为什么重要 |
|---|---|---|
| 如何进入 toolbox，它到底连接的是哪里？ | rook-ceph-tools 这个 Pod 是如何连接 Ceph 集群的？是不是也在运行 Ceph？ | 避免误以为 toolbox 是 Ceph 本体，而不是远程客户端。 |
执行 ceph status 出来的 HEALTH_WARN 是什么意思？如何继续追踪？ | ceph health detail 中出现 mon quorum lost 是什么情况？ | 每个诊断输出都包含问题线索，必须懂得如何逐级定位。 |
| Ceph 是如何将磁盘变成存储资源的？OSD 和硬盘是什么关系？ | OSD 是如何与物理磁盘对应的？多个 OSD 可以共享磁盘吗？ | 学习后续处理 ceph osd down 或磁盘故障时的操作逻辑。 |
| Ceph 的 Pool 是什么？为何每个 PVC 都对应 Pool？ | 为什么我们需要多个 Pool？Pool 的副本数和性能空间有何关系？ | Pool 是分区资源的单位，不理解就无法调优性能或容灾策略。 |
| Kubernetes 中的 StorageClass 与 Ceph 的 BlockPool 是如何绑定的？ | 从 PVC 到 Ceph RBD，资源是如何逐层映射的？谁创建了 RBD？ | 理清 K8s → Rook → Ceph 的控制链路，分析数据存储位置和负载归属。 |
3. 阶段三：动手演练
基本目标
- 掌握 Ceph 集群日常维护的基本操作；
- 能完成从新建存储池到绑定 PVC 并运行应用的流程；
- 能独立排查大部分常见故障（至少能定位原因）。
关键目标：能创建和操作 Pool、RBD、PVC，处理常见错误，掌握 Rook 升级与 Ceph 操作链条
| 需要理解的问题 | 推荐提问方式 | 为什么重要 |
|---|---|---|
| 如何判断某个 RBD 已正确创建并被某个 PVC 绑定？ | 如何从 PVC 反查对应的 Ceph RBD 名称？ | 学习确认存储是否正确配置，特别是排查挂载失败时。 |
| Pool 的副本数设置对性能与容错的影响？ | 在三副本池中，是否一定消耗三倍空间？如果只用两台机器怎么办？ | 理解 Pool 参数对性能与容量的影响是调优的核心技能。 |
| 创建快照后如何恢复？是否影响原有数据？ | Ceph RBD 快照 rollback 会覆盖原数据吗？如何演示恢复操作？ | 快照是实验/测试时的关键工具，常用于防止误删误操作。 |
| 为什么 rook-ceph-osd-xxx pod 会挂掉？如何分析？ | 一个 OSD pod 启动失败，如何从日志或 ceph 命令分析原因？ | 这类问题频繁出现，必须掌握日志诊断和硬件映射逻辑。 |
| Rook 升级过程中有哪些关键指标要观察？ | 从 v1.14 升级到 v1.15 时，哪些 pod 应该先更新，哪些资源不可变？ | 学习进行无中断升级，保障存储数据不丢失。 |
技巧
- 做实际创建→挂载→写入→删除的完整流程；
- 不怕试错，尤其在测试环境中故意制造 OSD down/MON 故障等；
- 多让大模型解释报错信息、CRD 字段用途。
三、常用命令
1. 基础信息查看与健康检查
| 操作 | 命令 | 用途说明 |
|---|---|---|
| 查看整体健康状态 | ceph -s 或 ceph status | 确保集群为 HEALTH_OK 状态，否则需分析警告内容 |
| 查看集群空间使用情况 | ceph df | 可判断哪些 pool 占用最多空间 |
| 查看所有组件版本 | ceph versions | 验证升级后版本是否统一 |
| 查看集群主机节点拓扑 | ceph osd tree | 判断 OSD 分布，识别故障节点时尤为关键 |
| 查看 MON 信息 | ceph mon dump | 验证 quorum 数与故障恢复需要 |
| 查看集群告警详情 | ceph health detail | 获取每条报警的具体信息和组件定位 |
2. OSD 操作
| 操作 | 命令 | 用途说明 |
|---|---|---|
| 查看所有 OSD 列表 | ceph osd ls | 确认 OSD 编号 |
| 查看 OSD 状态 | ceph osd stat | 检查是否所有 OSD up/in |
| 查看某 OSD 详细状态 | ceph osd dump | 常用于定位 OSD in/out 情况 |
| 标记某 OSD 下线 | ceph osd out <id> | 计划下线磁盘/维护节点时使用 |
| 重新上线某 OSD | ceph osd in <id> | 恢复使用磁盘或误操作恢复 |
| 手动标记某 OSD 为宕机 | ceph osd down <id> | 处理故障恢复场景的测试操作 |
| 触发 OSD 重平衡 | ceph osd reweight-by-utilization | 数据分布不均时使用 |
3. Pool 管理
| 操作 | 命令 | 用途说明 |
|---|---|---|
| 查看已有 pool | ceph osd pool ls | 快速了解当前的存储布局 |
| 查看 pool 详情 | ceph osd pool get <pool> all | 检查副本数、编码方式等参数 |
| 创建 pool | ceph osd pool create mypool 128 128 | 实验环境可尝试不同大小 pool |
| 删除 pool | ceph osd pool delete mypool mypool --yes-i-really-really-mean-it | 小心使用，仅用于实验环境 |
| 设置副本数为 3 | ceph osd pool set mypool size 3 | 保证数据冗余度，但提高空间消耗 |
4. RBD 操作练习
| 操作 | 命令 | 用途说明 |
|---|---|---|
| 创建 RBD 镜像 | rbd create myrbd --size 1024 --pool mypool | 以 MB 为单位，绑定 PVC 前需创建镜像 |
| 查看镜像 | rbd ls -p mypool | 确认是否成功创建 |
| 获取镜像信息 | rbd info mypool/myrbd | 查看镜像大小、使用情况 |
| 删除镜像 | rbd rm mypool/myrbd | 清理测试用镜像，释放空间 |
| 快照创建 | rbd snap create mypool/myrbd@snap1 | 可用于测试快照与恢复功能 |
| 回滚快照 | rbd snap rollback mypool/myrbd@snap1 | 模拟误删后数据恢复 |
5. 文件系统操作（仅在部署 MDS 后可用
| 操作 | 命令 | 用途说明 |
|---|---|---|
| 创建文件系统 | ceph fs new myfs myfs_metadata myfs_data | 支持类似 NFS 的共享挂载 |
| 查看所有文件系统 | ceph fs ls | 检查文件系统是否生效 |
| 查看文件系统状态 | ceph fs status | 检查活跃 MDS 节点和客户端连接数 |
四、练习场景
1. 场景一：为大模型训练服务创建独立数据卷
实验室部署了一个基于 PyTorch 的大模型训练服务，每个用户希望使用独立的数据存储卷挂载到训练容器中。你作为管理员，需要
- 创建一个名为
ml-training-pool的块存储池，专门用于模型训练数据； - 将该池绑定为 Kubernetes 中的一个 StorageClass，供用户在 PVC 中调用；
- 创建一个 PVC，并确认它成功绑定并在 Ceph 集群中创建了对应的 RBD 镜像；
- 使用 toolbox 查看该块设备的状态、容量等详细信息，确认其可用性。
2. 场景二：模拟节点磁盘故障与 Ceph 数据再平衡过程
为了演练 Ceph 在生产环境下的容错能力，你需要模拟一个 OSD 节点的异常下线，并观察 Ceph 的自愈机制是否生效。
- 在现有集群中挑选一个 OSD，并将其标记为
out，模拟该磁盘离线； - 观察 Ceph 是否触发数据迁移、再平衡以及健康状态变化；
- 查看 OSD tree 和集群状态变化，记录副本重建与容量重新分布过程；
- 模拟故障修复后将该 OSD 标记为
in，观察系统恢复过程。
3. 场景三：使用快照与回滚进行训练数据保护与恢复
在大模型训练前，你希望为用户的训练数据卷提供一次可恢复的快照，以防误删。模拟场景如下
- 在已有的块存储卷（对应 PVC）上创建一个快照，命名为
@pretrain； - 假设用户误删了重要训练数据或中途写入了异常数据；
- 使用 Ceph 的快照回滚功能，将该 RBD 卷恢复到训练前的快照状态；
- 验证回滚后的数据一致性，并理解快照对系统性能和容量的影响。
4. 场景四：部署共享卷支持分布式训练日志收集
实验室计划开展分布式训练实验，多个 Pod 实例需将训练日志写入同一个目录。你需要
- 创建一个 Ceph 文件系统（CephFS），并通过 MDS 服务提供 POSIX 接口；
- 配置一个支持 ReadWriteMany 的 StorageClass，供多个 Pod 同时挂载使用；
- 创建一个 PVC，并挂载到多个 Pod，模拟日志并发写入场景；
- 验证写入的数据是否一致、是否存在写入冲突或权限异常。
5. 场景五：模拟存储池容量即将耗尽的应对策略
在训练任务密集提交的高峰期，你发现某个 Ceph 块存储池的剩余容量即将不足。你需要
- 使用 toolbox 查看各 Pool 的使用率与副本配置；
- 分析当前 Pool 中有哪些 RBD 镜像是空置、未绑定的，考虑清理回收；
- 若确实容量不足，尝试调整某些 Pool 的副本数，从 3 副本降为 2（仅限测试场景）；
- 评估扩容可行性，增加新节点或 OSD，观察系统是否自动重平衡。
6. 场景六：清理废弃的镜像与 Pool，释放存储空间
你发现集群中存在多个不再使用的 PVC 及其对应 RBD 镜像，用户未能手动清理。你需要
- 确认这些 PVC 所在的 Pod 是否已经被删除；
- 查找这些 PVC 所绑定的 RBD 镜像并确认未再被挂载；
- 使用 toolbox 删除这些镜像，并清理不再使用的 BlockPool（若无依赖）；
- 再次检查集群总容量变化，确保空间回收成功。