Kubernetes 存储选型：Longhorn 与 Rook/Ceph 对比¶

一份面向公开读者的技术选型参考。不针对任何特定集群，目的是帮你在给 Kubernetes 选持久化存储时，搞清楚两者的适用边界，而不是比出"谁更强"。

0. 先分清三种存储形态¶

讨论选型之前，先明确你要的是哪一种，否则很容易拿错方案对比：

形态	访问模式	典型用途	代表实现
块存储（Block）	通常 `ReadWriteOnce`	数据库、消息队列、单 Pod 独占写	Ceph RBD、Longhorn、云盘（CBS/EBS/PD）
文件存储（File）	`ReadWriteMany`	多 Pod 共享读写、CI 缓存、共享配置、媒体库	CephFS、NFS、云文件存储（CFS/EFS）
对象存储（Object）	S3 API	备份、日志、大数据、制品库	Ceph RGW、MinIO、S3/OSS/COS

关键点：RWX（多 Pod 同时读写）在块存储上不能原生实现，必须由文件系统或 NFS 网关来提供。这一点决定了后面很多差异。

1. 两个项目速览¶

1.1 Longhorn¶

定位：轻量级、纯 Kubernetes 原生的分布式块存储。
出身：Rancher Labs 发起，现为 CNCF 孵化（Incubating）项目。
架构：
每个卷是一个"微服务"，由 Longhorn Engine + 若干副本（Replica）组成；
副本以快照链的方式保存增量，运行在普通 Pod 里；
对上层暴露前端：内核设备（/dev/longhorn/...）和 iSCSI target。
一个 3 副本的卷，大致对应 4 个容器（1 个控制器 + 3 个副本）。
接口：只做块存储（RWO）。RWX 是通过 share-manager（一个 NFS 服务器 Pod 转发块卷）实现的，官方文档在 1.7.x 版本中仍将其列在 Experimental Features 下。
管理面：纯 CRD + 自带 UI，没有"集群外"的概念。

1.2 Rook + Ceph¶

定位：在 Kubernetes 上运行并管理 Ceph——一个通用的分布式存储系统。
出身：Rook 是 CNCF 毕业（Graduated）项目；Ceph 本身是 Linux 基金会项目（不属于 CNCF），已有二十年以上历史。
架构：
Rook 是 operator：通过 CephCluster、CephFilesystem、CephBlockPool 等 CR 声明式管理 Ceph；
Ceph 由一组守护进程组成：mon（集群大脑/一致性）、mgr（管理/指标）、osd（数据盘，一块盘一个 OSD）、mds（CephFS 元数据服务）；
数据分布由 CRUSH 算法决定，副本（或纠删码）按故障域（host/rack/chassis）分散。
接口：三种一起给——
RBD：块存储（RWO）；
CephFS：POSIX 共享文件系统（RWX，原生）；
RGW：对象存储，兼容 S3 API。
管理面：Ceph 有自己的 Dashboard / CLI；Rook 负责把它们部署在 k8s 里。

2. 能力对比¶

维度	Longhorn	Rook / Ceph
存储形态	仅块存储	块 + 文件 + 对象
RWX 共享文件	有，但走 NFS 转发（share-manager），官方标注实验特性	原生 POSIX（CephFS）
对象存储（S3）	❌	✅（RGW）
冗余机制	多副本（卷级）	多副本或纠删码（EC）
副本故障域	按节点分散	可细到 host / rack / chassis（CRUSH）
空间效率	副本制：3 副本 = 3 倍空间	副本制，或 EC（如 4+2 ≈ 1.5 倍，可容忍 2 盘故障）
单节点可用	✅ 天生支持	⚠️ 可运行，但无冗余、无 mon quorum，不建议生产
节点故障不丢数据	需要 ≥3 节点 + 3 副本	需要 ≥3 节点 + 副本 3（或 EC）
多 K8s 集群共享	❌ 每个集群一套独立实例	✅ external cluster 模式（consumer 只装 CSI）
规模定位	官方目标是海量卷；社区实践多见于中小规模集群	PB 级、上千 OSD、大规模生产
运维复杂度	低：概念少，纯 CRD + UI	高：mon/mgr/osd/mds/pool/PG/CRUSH 一整套
性能特征	走 iSCSI/NBD + 副本链，小 IO 延迟相对更高	RBD 路径更短、CephFS 原生并发，通常更优
快照 / 备份	原生集成，支持 S3/NFS 备份目标	RBD/CephFS 快照，备份生态丰富但需配置
图形界面	自带 UI，简单直观	Ceph Dashboard（能力更强，概念更多）
CNCF 状态	Incubating	Graduated（Rook）

说明：性能一栏只给方向，不给绝对结论——同一批硬件下差异很大，选型应基于自己的 POC 实测。

3. 各自的真实优势¶

3.1 Longhorn 的优势¶

轻：没有 mon/pool/PG/CRUSH 这些概念，一个卷就是一组 Pod，学习成本低。
单节点/小集群友好：天生支持单节点部署，开发测试环境上手极快。
纯 K8s 原生：全部是 CRD，升级、扩容、扩副本都是 k8s 操作，没有"外部存储系统"这层心智负担。
运维简单：UI 直观，快照/备份与 S3 集成开箱即用。
与 Rancher 生态整合好：如果本来就在用 Rancher，体验顺畅。

3.2 Ceph 的优势¶

一套存储、三种接口：块、文件、对象同时提供，省掉维护多套存储系统。
原生共享文件系统：CephFS 是真正的 POSIX 分布式文件系统，多客户端并发能力和语义完整性都优于"块卷 + NFS 转发"。
纠删码：冷数据/大容量场景可以显著降低冗余开销（副本制 3 倍 vs EC 约 1.5 倍）。
故障域更细：CRUSH 能按机架/机箱做数据分布，跨机架容灾比"仅按节点"更强。
规模上限高：PB 级容量、上千 OSD 有大量生产案例。
多集群共享：通过 Rook 的 external cluster 模式，一套 Ceph 可以服务多个 k8s 集群，consumer 侧不需要自己的 OSD。
生态成熟：Ceph 被 OpenStack、公有云、运营商大量使用，工具链与排障资料丰富。

4. 怎么选：按场景给结论¶

4.1 决策树¶

需要对象存储（S3）吗？
├─ 是  → Ceph（RGW）
└─ 否
   └─ 需要原生 RWX 共享文件、且并发/语义要求高吗？
      ├─ 是 → Ceph（CephFS）
      └─ 否
         └─ 有多个 K8s 集群要共享同一套存储吗？
            ├─ 是 → Ceph（external cluster）
            └─ 否
               └─ 规模是否较大（PB 级 / 上百 OSD），或需要 EC 省空间/机架级容灾？
                  ├─ 是 → Ceph
                  └─ 否 → Longhorn

4.2 分场景建议¶

场景	推荐	理由
本地开发 / 单节点 / 边缘小环境	Longhorn	轻量、单节点原生支持，装完即用
3–10 节点的中小生产集群，只要块存储	Longhorn	运维成本低，3 副本即可满足节点级冗余
需要多 Pod 共享读写（RWX）且性能敏感	CephFS	原生文件系统，避免 NFS 转发瓶颈
需要 S3 兼容对象存储	Ceph（RGW）或 MinIO	Ceph 可与块/文件共用一套硬件
大规模（PB 级、上百 OSD）	Ceph	CRUSH 扩展性与成熟度
多个 K8s 集群共享一套存储	Ceph（external cluster）	Longhorn 无此能力
冷数据多、想省空间	Ceph（纠删码）	EC 比多副本省 40%+ 空间
需要机架级容灾	Ceph	CRUSH 支持 rack 级故障域

4.3 一个重要的反模式¶

不要为了"用 Ceph"而在每个 K8s 集群里各装一套。 如果目标是多集群共享，正确做法是：

建一套独立的 Ceph（≥3 节点，节点带本地盘做 OSD）；
各 K8s 集群以 consumer 身份通过 Rook external cluster 模式接入，只部署 CSI；
存储容量和 OSD 只维护这一套。

每集群各装一套的结果是：N 倍硬件、N 倍运维，而且数据彼此隔离，共享不了。

5. 常见误区¶

"Longhorn 的 RWX 等于 CephFS" 不是。Longhorn 的 RWX 是 share-manager 把一个块卷通过 NFS 暴露出去，本质仍是块存储 + NFS 网关；CephFS 是原生分布式文件系统。高并发、强一致、元数据密集的场景差距明显。
"Ceph 一定更快" 不一定。Ceph 的优势建立在多节点、多 OSD、并行分布之上；单节点单盘时这些优势无法发挥。任何性能结论都应该基于自己的 POC。
"副本数越多越安全" 副本每加一份，容量利用率就降一档（3 副本 = 33%）。真正的安全来自副本跨故障域，而不是盲目堆副本数。
"多集群就是每个集群装一套" 见 4.3。多集群共享存储应该用 external cluster。
"在 Ceph Dashboard 里建了卷，K8s 就能用" 不能直接对应。K8s 的存储入口是 PVC + StorageClass（动态供给）；Ceph Dashboard 管的是 Ceph 集群本身。要把已有 Ceph 卷接进 k8s，需要用静态 PV（staticVolume: "true" + rootPath），且静态卷通常不支持在线扩容/快照。
"Rook 是 CNCF 毕业项目，所以什么场景都该用它" 毕业只说明项目成熟、社区治理完善，不代表它适合所有规模。单节点、小集群用 Ceph 往往是过度设计。

6. 做 POC 时建议验证的指标¶

选型最终要靠数据，建议至少测这几项：

随机读写 IOPS / 延迟（4K、64K，读写分开）
顺序吞吐（大块）
多 Pod 并发下的表现（尤其是 RWX 场景）
故障注入：杀掉一个节点 / 一块盘，验证数据可用性与恢复时间
扩容操作：加盘、扩 PVC、扩副本的实际耗时与业务影响
运维演练：升级、备份恢复、监控告警是否完善

7. 参考资料¶

Longhorn 官方文档：https://longhorn.io/docs/
Rook 官方文档：https://rook.io/docs/rook/latest-release/
Ceph 官方文档：https://docs.ceph.com/
Rook external cluster：https://rook.io/docs/rook/latest-release/CRDs/Cluster/external-cluster/
CNCF 项目全景：https://www.cncf.io/projects/

附：一句话总结¶

Longhorn：K8s 原生的轻量块存储，适合单节点到中小规模集群，运维简单。
Rook/Ceph：通用分布式存储平台，适合大规模、多集群、多接口（块/文件/对象）、需要 EC 与细粒度故障域的场景，代价是运维复杂度。
选型的核心不是"谁更强"，而是"你的规模、接口需求、故障域要求，落在谁的能力区间里"。