【Rook / CSI】RBD 供给路径：StorageClass 到 CreateVolume 到 image
内容提要
本文探讨Rook上RBD动态供给路径：PVC Pending时，需排查StorageClass的provisioner命名（须与Operator命名空间一致）、Secret、池及CreateVolume日志。StorageClass参数经external-provisioner映射为Ceph-CSI的CreateVolume，创建Format 2 image。imageFeatures须匹配节点内核能力，否则挂载失败。Bound仅表示image存在，不保证节点可挂载。
延伸解读
provisioner 命名：命名空间前缀不是装饰
Rook 默认将 CSI 驱动名设为「Operator 命名空间 + 驱动后缀」，如 rook-ceph.rbd.csi.ceph.com。若 Operator 装在 my-namespace，则必须写成 my-namespace.rbd.csi.ceph.com。前缀不一致是 PVC Pending 的常见根因：API 对象合法，但集群中不存在对应的 CSIDriver。VolumeSnapshotClass 的 driver 字段也必须与 StorageClass 的 provisioner 同名，否则快照 R
imageFeatures：供给时就要为挂载买单
Rook 官方建议：内核 ≥5.4 时可用 layering,fast-diff,object-map,deep-flatten,exclusive-lock；≤5.3 时仅用 layering。CSI 声明的 features 与节点 krbd 能力不一致时，供给阶段往往成功（Controller 节点不一定是挂载节点），失败推迟到 NodeStage，表现为 unsupported krbd Feature 或「挂上但怪」。工程纪律：以最旧可调度节点的内核能力为上限，不要在生产 SC 上打开所有 feature
Pending 归因：先分清层再下刀
PVC Events 无 provisioner 信息，更可能是 StorageClass 名错、无默认 SC；provisioner 日志反复 CreateVolume，则检查 mon endpoint、clusterID、Secret、池名；CreateVolume 成功但 Pod 不调度，与存储无关；Bound 后 MountVolume 失败，看第 7 篇的 map/features/Secret。不要用「Ceph 慢」概括所有 Pending：供给路径上多数是配置与身份问题，不是 BlueStore 延迟
回收策略与池拓扑：交接处的坑
reclaimPolicy: Delete 会走 DeleteVolume 删除 image（可能受 trash 影响）；Retain 则 image 留在池里，需手工 rbd rm 清理，否则池被「遗忘 image」占满。池的 failureDomain 与副本数决定 image 对象能否按预期分散故障域；三副本却只有两个节点 OSD 时，池可能不干净，PVC 侧只看到 CreateVolume 重试。EC 池作数据池时，需独立 replicated 元数据池 + dataPool 参数，且内核有下限。
Q&A
Rook 上 RBD 动态供给时，PVC 卡在 Pending 状态，应该从哪些方面排查？
应依次排查 StorageClass 的 provisioner 命名（必须与 Rook Operator 命名空间一致）、Secret 配置（名称和命名空间）、CephBlockPool 是否存在，以及 Ceph-CSI 的 CreateVolume 日志。PVC Events 无 provisioner 信息时，优先检查 StorageClass 名称或默认 SC；provisioner 日志反复报错时，检查 mon endpoint、clusterID、Secret 和池名。
Rook 中 StorageClass 的 provisioner 字段为什么必须包含命名空间前缀？
Rook 默认将 CSI 驱动名设置为“Operator 命名空间 + 驱动后缀”，例如 rook-ceph.rbd.csi.ceph.com。前缀必须与 Rook Operator / CSI 所在命名空间一致，否则集群中不存在对应的 CSIDriver，导致供给失败。这是多集群或复制粘贴 StorageClass 时常见的 Pending 根因。
Rook 上 RBD 动态供给时，StorageClass 中的 imageFeatures 参数有什么作用？设置不当会有什么后果？
imageFeatures 指定 RBD image 的特性位，如 layering、exclusive-lock 等。它必须与节点内核的 krbd 能力匹配。如果设置不当，供给阶段可能成功，但挂载时（NodeStage）会失败，表现为 unsupported krbd Feature 或挂载后行为异常。建议以最旧可调度节点的内核能力为上限，不要盲目开启所有特性。
Rook 中 PVC 状态变为 Bound 是否意味着节点一定能挂载该 RBD 卷？
不是。PVC Bound 只表示 RBD image 已创建成功，但不保证节点能成功挂载。挂载可能因 imageFeatures 与节点内核不匹配、Secret 错误等原因失败，这些在 NodeStage 阶段才会暴露。
Rook 上 RBD 动态供给时，StorageClass 中的 Secret 有哪些？各自的作用是什么？
主要有两类：rook-csi-rbd-provisioner 用于 Controller 侧的 Create/Delete/Expand/ControllerPublish 操作；rook-csi-rbd-node 用于 NodeStage 映射 image。它们对应 Ceph 客户端凭据。Secret 命名空间写错或 keyring 轮换后未同步，会导致间歇性 CreateVolume 或 map 失败。
Rook 上 RBD 动态供给时，CephBlockPool 的配置（如 failureDomain 和副本数）对供给有什么影响？
CephBlockPool 必须先存在，且其放置约束（如 failureDomain: host 和 replicated.size: 3）要求有足够节点和 OSD。如果池配置不满足，CreateVolume 阶段会失败或重试，PVC 会报错。这不是 CSI 本身的问题，而是池的拓扑约束。
Rook 上 RBD 动态供给时，StorageClass 的 reclaimPolicy 设置为 Retain 会有什么后果？
如果 reclaimPolicy 为 Retain，删除 PVC 后 RBD image 会保留在池中，需要运维手工清理（如 rbd rm），否则会占满池容量。多租户平台若默认 Retain 且无回收流程，可能导致池被“遗忘 image”占满。
Rook 上 RBD 动态供给时，为什么说“Pending 时先问 provisioner 名、Secret、池与 CreateVolume 日志”？
因为供给路径上多数 Pending 问题源于配置错误，如 provisioner 命名空间前缀不对、Secret 缺失或错误、池不存在等，而不是 Ceph 性能问题。通过检查这些配置和 CreateVolume 日志，可以快速定位问题，避免误判为存储故障。
