定义
Rook 是一个开源的云原生存储编排器，为 Kubernetes 提供管理分布式存储系统的平台、框架与支撑组件[1]。它的工作对象是已有成熟存储系统，核心形态是把这些系统转化为可在 Kubernetes 上运行的云原生服务，而不是从零重新实现一套存储引擎。
在 Rook 目前支持的存储提供者中，Ceph 是唯一被评为稳定级别的一个，对应接口组为 ceph.rook.io/v1；Cassandra 与 NFS 提供者已迁出到独立仓库分别维护[3]。Ceph 是分布式存储系统，同时提供文件、块和对象 3 种存储形态，并已在大规模生产集群中部署[1]。
Rook 采用 Apache 2.0 许可证发布[2]。
原理
Rook 以 Kubernetes 的 Operator 模式实现自动化。运维人员通过自定义资源(CRD)描述期望的存储形态，例如存储集群、池、文件系统和对象存储；Operator 则持续观察实际状态并与期望状态比对，发现偏差后不断纠正[4]。这种方式把存储层也用 YAML 清单声明出来，使存储与应用可以按同一套方式管理[4]。
在具体组件层面，Operator 负责启动并监控 Ceph 的 mon 进程 Pod、以 DaemonSet 形式部署的 OSD，以及 MGR、MDS 等守护进程；它还会创建用于管理存储池、对象存储和文件系统的 CRD，并初始化运行这些服务所需的 Pod 与其他资源[5]。集群规模变化或守护进程失效时，Operator 会相应调整，必要时重新选举 mon[5]。
Kubernetes 与 Ceph 之间的数据通路由 CSI 承担。Ceph-CSI 以 Go 语言实现 CSI 规范的 gRPC 服务端，把 CSI 调用转换为 Ceph 操作：控制器部分负责卷与快照的生命周期、扩容和挂载流程，节点插件部分以 DaemonSet 形式在每个节点运行，处理挂载与卸载[4]。Ceph-CSI 为 RBD、CephFS 和 NFS 提供各自的驱动路径，其中 RBD 面向块工作负载，CephFS 提供可被多个 Pod 共享的文件存储[4]。
Rook 主要使用 Go 语言编写，而 Ceph 本身由 C++ 实现，数据路径保持 Ceph 原生实现不变[5]。Rook 在 Ceph 之上做了面向管理者的简化，把放置组、CRUSH 映射等概念隐藏起来，改用物理资源、池、卷、文件系统和桶这类更直观的对象来表达；需要精细调整时，仍可通过 Ceph 工具进行高级配置[5]。
发展历程
Rook 的项目雏形在 2016 年出现于公司内部，最初的目标是利用运行在廉价通用硬件上的软件定义存储，为本地环境提供成本更低的存储方案，当时使用的代号是“Castle”。由于这一名称难以注册商标，团队改用国际象棋中形似城堡的棋子名称 Rook 作为对外品牌。
值得注意的是，最早的公开版本 v0.1 并未以 Kubernetes 作为主要运行环境，而是一个名为 rookd 的命令行守护进程，可运行在一组 Linux 主机上，并使用基于 etcd 的内置编排逻辑。随着 Kubernetes 的编排能力逐渐显现优势，项目很快放弃了独立运行的 rookd，转为只在 Kubernetes 内运行。
2018 年 1 月 29 日，CNCF 技术监督委员会投票接纳 Rook 成为第 15 个托管项目，也是该基金会首个存储类项目，当时定级为 inception 级别。同年 12 月，Rook v0.9 版本中的 Ceph operator 被宣布为稳定，此后长期作为生产存储平台使用[1]。
2020 年，CNCF 投票决定 Rook 晋级为毕业级项目，评审涉及安全实践、生产部署、开放治理和测试框架等方面；此前 Rook 已由 Trail of Bits 完成第三方安全审计。截至该里程碑，项目的 GitHub 星标从 3.4 千增长到 7.7 千，贡献者由 90 人增至 280 人以上，容器下载量由 1600 万增长到 1.76 亿以上。
Rook v1.3 发布时，Ceph 支持版本已包含 Nautilus v14.2.5 或更新版本与 Octopus v15.2.0 或更新版本，同时移除了对 Mimic 的支持。该版本还引入了池级别压缩配置、基于 PVC 的 OSD 以及对 Ceph-CSI v2.0 驱动的最低版本要求。CockroachDB、EdgeFS 和 YugabyteDB 这 3 个提供者在 v1.6 中被移出 Rook[6]。
应用
Rook 的典型用途是在 Kubernetes 集群中提供持久化存储，使有状态工作负载摆脱对云厂商托管存储服务的依赖[4]。它支持多种部署拓扑：超融合模式把 Ceph 的 Pod 与应用放在同一批节点上，通过资源请求、限制、亲和性与容忍度控制资源分配；专用存储节点模式用污点和容忍度把 Ceph 隔离出来；外部 Ceph 模式则把已有 Ceph 集群接入 Kubernetes，让 Kubernetes 主要承担控制面与策略角色[4]。
部署完成后，应用可通过 3 种方式使用存储：块存储供单个 Pod 以读写一次方式挂载，共享文件系统供多个 Pod 同时读写，对象存储则在集群内外提供兼容 S3 的访问端点[7]。Rook 也提供用于调试的 toolbox Pod 以及 kubectl 插件，便于查看集群状态与排查问题[7]。
Rook 有较多的生产部署案例。加利福尼亚电信与信息技术研究所运行过一个 170 个存储节点、2.3 PB 容量的 Rook 集群；挪威劳工与福利局用其支撑面向约 400 万用户的服务；Discogs 曾以 32 个节点、133 TB 容量的集群运行其音乐数据库业务。Rook 的部署工具包 kURL 也把 Rook 作为默认附加组件，用于离线环境中的高可用存储。
局限
Rook 本身不新建存储引擎，其数据可靠性与性能取决于所编排的存储系统，尤其是 Ceph 的表现。因此 Rook 无法绕开 Ceph 在生产环境中的调优与容量规划要求，例如集群健康状态仍需通过 ceph status 等 Ceph 工具确认，mon 需达到法定人数、至少 3 个 OSD 处于 up 且 in 状态才算健康[7]。
部署存在环境与版本约束。以 Ceph 集群为例，需要节点提供未被分区或格式化的裸设备、裸分区、LVM 逻辑卷、加密设备等本地存储中的至少一种；官方文档仅列出 Kubernetes v1.32 至 v1.37 属于受支持版本，硬件架构限于 amd64/x86_64 与 arm64[7]。官方还提示测试时应使用虚拟机，避免在本地设备可能被误用的主机系统上运行[7]。
在支持范围上，Rook 各存储提供者的成熟度并不一致，被视为稳定的只有 Ceph 提供者，其余接口组可能处于 Alpha、Beta 或已弃用状态[8]。历史上曾纳入的 CockroachDB、EdgeFS、YugabyteDB 等提供者已在 v1.6 移除，说明其支持的存储后端集合会随版本收缩[6]。此外，官方强调应使用正式发布的版本，主干分支构建的版本可能随时变更甚至移除功能，且不提供兼容性支持[3]。
参见
-
Kubernetes —— Rook 运行所依托的容器编排平台，其 Operator 与 CRD 机制是 Rook 自动化的基础。
-
Ceph —— Rook 编排的参考存储系统，提供文件、块与对象存储。
-
CSI —— Kubernetes 接入存储的标准接口，Ceph-CSI 是 Rook 场景下的数据通路实现。
-
云原生计算基金会 —— 托管 Rook 的基金会，Rook 为其毕业级项目。
-
软件定义存储 —— Rook 所依赖的存储理念，用通用硬件与软件实现存储功能。
-
Operator 模式 —— Rook 实现声明式存储运维所采用的 Kubernetes 扩展模式。
参考资料
- Rook¶ [引用日期2026-10-14]
- Features of Rook [引用日期2026-10-14]
- rook [引用日期2026-10-14]
- Orchestrierung-fuer-Block-File-und-Object-Storage-mit-Rook [引用日期2026-10-14]
- Ceph [引用日期2026-10-14]
- <img alt="Rook" src="Documentation/media/logo [引用日期2026-10-14]
- Quickstart [引用日期2026-10-14]
- rook [引用日期2026-10-14]