【Rook / CSI】对象与 NFS：RGW 暴露边界与实验性 NFS CSI

读完 RBD/CephFS 的 PVC 路径后，容易把 Rook 想象成「K8s 里所有存储协议的统一遥控器」。对象存储与 NFS 在 Rook 里确实有 CRD 与文档，但它们进入应用的方式、成熟度与失败模式，与块/文件 CSI 不是同一条故事线。本篇只划边界：什么算本系列该钉的编排问题，什么必须回到 ceph/14 · RGW，什么该标成实验特性后停手。

本文是「Rook / CSI」系列第 10 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 9 篇 · 快照与克隆	VolumeSnapshot 语义
第 10 篇 · 对象与 NFS	RGW 边界；NFS CSI experimental
第 11 篇 · 升级闸门	Rook/Ceph/CSI 升级

版本锚定：Rook v1.20.4；Ceph-CSI v3.17.0；K8s v1.31–v1.36。对象语义默认对齐站内 Squid；Tentacle 特性另标。

一、三条接入路径，不要混成一张图

flowchart TB
  apps["K8s applications"]
  apps -->|"PVC RWO"| rbd["RBD CSI"]
  apps -->|"PVC RWX"| cephfs["CephFS CSI"]
  apps -->|"S3 SDK / gateway"| rgw["RGW via CephObjectStore"]
  apps -->|"PVC or NFS mount"| nfs["NFS CSI experimental"]
  rbd --> rados["RADOS"]
  cephfs --> rados
  rgw --> rados
  nfs --> cephfs

最后一行是关键：Rook 文档写明 NFS CSI 的后端是 CephFS + NFS Ganesha（CephNFS），不能用 RGW 当 NFS CSI 的后端。 对象协议与 NFS 导出不是同一条编排管道。

二、CephObjectStore：编排的是「网关生命周期」，不是「PVC 语义」

CephObjectStore 让 Rook Operator 部署 RGW 实例、对内接到对象池/索引池，对外暴露 Service/Endpoint（具体字段见 Rook Object Storage CRD 文档）。应用侧典型用法：

• 在 Pod 里配 S3 endpoint、access key、secret key；
• 或经 Ingress/LoadBalancer 把 RGW 暴露给集群外；
• 用 Rook 的 Object Bucket Claim 一类扩展（若启用）申请桶——这仍是对象工作流，不是块 CSI 的 CreateVolume。

与 PVC 路径的差别：

本系列不写：

• 完整 S3 API 教程、多站点 sync 操作手册；
• bucket index OMAP、LIST 归并税的重讲——见 ceph/14 与 ceph/18 排除树；
• 「在 K8s 上点一下就有 MinIO 替代品」的营销对照（对照叶留给第 14–16 篇）。

编排层要钉死的只有：CephObjectStore 健康 ≠ RBD/CephFS PVC 健康；RGW 挂了不会让 BlockPool 消失，反之亦然。排障时先分协议面。

安全与加密边界（点到为止）

Rook v1.20 发行说明含 SSE-S3 + Vault Agent 等对象加密相关增强。细节属对象安全配置，第 15 篇会收租户与加密双层税；本篇不展开 KMS 菜谱。

三、NFS CSI：experimental，且升级不承诺

Rook v1.20「CSI provisioner and driver」（NFS）开篇即：

This feature is experimental and will not support upgrades to future versions.

同页与「Ceph CSI Drivers」总述还钉：

• NFS 驱动默认关闭；RBD/CephFS 才是默认启用路径。
• 启用前必须：已有 CephFilesystem，以及 CephNFS（NFS Ganesha 服务端）。
• RGW 不能用于该 CSI 驱动。
• v1.20 下由 ceph-csi-operator 管理：RBAC 与 Driver CR 示例在 deploy/examples/csi/nfs/；Helm 则 drivers.nfs.enabled: true 且 name: rook-ceph.nfs.csi.ceph.com（命名空间前缀规则与其它驱动相同）。

对平台工程的含义：

1. 可以做实验室 / 明确知情的预发，不要把「实验性 NFS CSI」写进与 RBD 同级的生产 SLA。
2. 升级 Rook 时不要假设 NFS 驱动配置可平滑迁移——官方已提前免责。
3. 集群外或权限收敛场景，Rook 反而推荐经典「管理员建 export + K8s 普通 NFS PV」模型，降低客户端集群特权。

Provision 语义（文档叙述）：按 StorageClass 创建 NFS export，PVC 可在尚无 Pod 时就 Bound——这是 export 生命周期，不是「挂载成功」。挂载仍受 NFS 协议与 Ganesha/CephFS 后端约束；CephFS 的 MDS/caps 税不会因为换了一层 NFS 而消失，只是多了一层协议翻译。

四、本系列明确不变成什么

若目标只是「给应用一个共享目录」，优先评估：CephFS CSI RWX（成熟路径）vs 实验性 NFS CSI vs 集群外 NFS。把对象存储硬拐成文件语义，通常两头不讨好。

五、谱系、争论与开放问题

谱系：RADOS 上叠 RGW（对象）与 CephFS（POSIX）是 Ceph 长期多协议策略；NFS Ganesha 再导出 CephFS 是「协议网关」传统，不是 CSI 发明的。CSI NFS 驱动试图把 export 申请声明化，但成熟度仍落在实验标签后。

争论：K8s 应用该不该「原生说 S3」？云原生一派主张对象优先、消除共享 POSIX；数据平台一派仍要目录与锁。Rook 同时提供 ObjectStore 与 CephFS，是工程上的并存，不是学术上的统一。选型应用排除树（ceph/18），不要用「反正都是 Rook」合并协议税。

开放问题：

1. NFS CSI 若摘 experimental，升级故事与快照/克隆矩阵如何与 CephFS CSI 对齐？
2. Object Bucket Claim 与跨租户桶策略，在多 CephObjectStore 下如何避免变成第二个「隐式 Soft Multi-tenancy」？（第 15 篇方向。）

六、对象入口的网络与身份边界（编排视角）

CephObjectStore 暴露面通常是集群内 Service，再按需接 Ingress。编排上要分清：

• 数据路径：应用 → RGW → RADOS 对象/索引池；
• 控制路径：Rook reconcile RGW Deployment、池、用户 CR。

两者任一失败，症状都是「S3 不可用」，但修复入口不同。把 RGW Pod 重启当成「整集群存储恢复」会误伤仍健康的 RBD 工作负载。

身份上，对象用户与 CSI 的 rook-csi-* Secret 不是同一套。轮换 S3 密钥不会修复 PVC Pending；轮换 CSI Secret 也不会修复签名失败。多租户时，桶策略与 Namespace 边界若只靠「别把密钥提交到 Git」，没有技术强制，第 15 篇再收。

相对「每个租户一个 CephObjectStore」与「共享 RGW + 桶前缀」，前者隔离强、税高，后者相反。本系列不替读者选边，只要求：不要把隔离模型写进对象，却用文件 CSI 的习惯去排障。

七、为何本系列要单开一篇「周边」

若把对象与 NFS 完全留给 ceph/ 与外部文档，读者会在 Rook 目录里看到 CephObjectStore、CephNFS 却不知道它们与 PVC 主线的关系，容易在架构评审里画成「一个 Rook 搞定块文件对象 NFS」。单开本篇的目的是降级预期：

• 对象：编排网关与生命周期，语义教科书在 ceph/14；
• NFS CSI：实验特性，升级免责，依赖 CephFS 而非 RGW；
• 真正要投入编制的生产文件路径：CephFS CSI（第 8 篇）。

这也方便第 14–16 篇做排除树时引用：当需求是 S3，不要先问「Rook 怎么挂 PVC」；当需求是 NFS 协议，不要默认实验驱动已与 RBD 同级。

运维界面上，对象与块的告警订阅也应拆开。共享「rook-ceph Namespace 有 Error」一类聚合告警，会让 RGW 502 与 OSD 宕机抢同一值班注意力。按 CR 种类与组件标签拆路由，是便宜且高收益的编排改进。

若团队已经用外部独立 RGW 或云对象，Rook 的 CephObjectStore 可以缺省不装，以缩小爆炸半径——不是「功能不装不齐」。系列鼓励按协议裁剪安装面，而不是按营销清单装全。

实验性 NFS 若在预发验证，建议单独 Namespace/集群，避免与生产 RBD 升级绑在同一变更窗口；官方既已声明不支持升未来版本，就应假设日后可能拆掉重建 export，而不是假设可原地跟 Rook 小版本。

八、ObjectStore 与块/文件集群共置时的资源账

同一套 OSD 上共置 RGW、RBD、CephFS 是 Ceph 的卖点，也是吵闹邻居来源。编排层能做的分账有限，但至少应：

• 为对象索引池/数据池与块池使用不同 CephBlockPool/pool 声明，便于打标签与告警；
• 避免在 RGW LIST 风暴期间同时做大规模 RBD 克隆 flatten；
• 变更窗口错开：对象网关大版本与 CephFS MDS 扩容不要同一小时。

这些是运维日历问题，不是 CRD 字段问题。本系列不给「共置一定不行」的结论——ceph/18 排除树要求按机制问句判断——但共置时必须有人拥有跨协议的变更日历。只有块值班、没有对象值班的团队，不适合打开 CephObjectStore。

NFS 实验路径若与生产 CephFS 共用同一文件系统，导出与 PVC subvolume 会争同一套 MDS。预发实验应考虑独立 CephFilesystem，避免实验 export 的元数据风暴打到生产 RWX。官方既称 experimental，隔离成本应视为启用预算的一部分。

从系列边界再收一次：读完本篇，读者应能在架构图上把 S3 箭头画到 RGW，把 PVC 箭头画到 CSI，把「也许再加 NFS」画成虚线并标注 experimental。若仍画成单一「Rook 存储」方框，说明边界没有钉住，需要重读本节与 ceph/14 入口。

关于桶与 PVC 的产品隐喻：Object Bucket Claim 让对象申请看起来像 PVC，但失败模式仍是 HTTP 与索引 OMAP，不是 MountVolume。培训材料里复用「申请存储」口头禅时，要补一句协议差异，否则值班手册会串戏。

九、检查清单：画架构图前先回答

1. 应用主键协议是块、POSIX 文件，还是 S3？
2. 若是 S3：是否接受自行维护 CephObjectStore 与索引池税，或改走外部对象？
3. 若是 POSIX 共享：CephFS CSI 是否足够？是否有人认领 MDS？
4. 若「必须 NFS 协议」：能否接受 experimental 与无升级承诺？能否接受独立文件系统隔离？
5. 是否误把 RGW 当成 NFS CSI 后端？

五问都答完再画方框。答不全就停在本篇边界，去读 ceph/14 或第 8 篇，而不是先申请一排 CR。对象与 NFS 在 Rook 里「能创建」不等于「该与 RBD 默认路径同等承诺」——这是本篇唯一必须带走的结论。

独立 RGW 与 Rook 托管 RGW 的选择，还涉及证书、Ingress、WAF 与桶备份工具链；那些属于平台网络与安全，不在存储编排内核里展开。本系列只保证：你不会把对象问题错当成 PVC MountFailed。

若评审场上仍有人主张「先把 NFS CSI 开起来再说」，把官方原句放进纪要：experimental，且不支持升到未来版本。纪要胜于事后争论。预发可以试，生产默认路径应留在 RBD 与 CephFS CSI；对象走 CephObjectStore 或外部 S3，机制细节回 ceph/14。下一篇升级闸门会再次提醒：实验驱动不要与生产 Ceph 主版本跳跃绑在同一变更窗口。

启用对象网关前，还要确认监控与日志是否按 RGW 单独采集：延迟直方图、5xx 比例、索引池慢请求，都应能与 OSD 通用面板区分。否则一次桶 LIST 风暴会被当成「整个 Ceph 变慢」，错误地触发 OSD 扩容。编排边界清晰，观测边界也要清晰——后者在第 12 篇继续。

参考资料

官方文档（A）

• Rook v1.20 — Ceph CSI Drivers — 三驱动定位；NFS experimental
• Rook v1.20 — NFS CSI provisioner and driver — 不支持升未来版本；依赖 Filesystem+CephNFS；非 RGW
• Rook v1.20 — Ceph-CSI Drivers Helm Chart — drivers.nfs.enabled
• Rook v1.20 — Object Storage / CephObjectStore CRD 文档（暴露与安全设置入口）

站内

• ceph/14 · RGW
• ceph/18 · 排除树
• 第 8 篇 · CephFS CSI
• 第 14 篇 · 对照替代路径

→ 上一篇：快照与克隆 · 系列目录 · 下一篇：升级闸门