【Rook / CSI】编排全景：五轴坐标系与 16 篇路线
内容提要
本文介绍Rook v1.20与Ceph-CSI在Kubernetes上的编排内核，填补RADOS与PVC挂载间的缺口。提出五条坐标系：CSI RPC、Sidecar、Operator/CRD、数据面归属、升级闸门，并强调三个不变量。规划16篇系列文章，聚焦故障归因与升级路径，不重写底层存储细节。
延伸解读
五轴坐标系的排障价值
文章提出用五条坐标系（CSI RPC、Sidecar、Operator/CRD、数据面归属、升级闸门）来定位故障，强调先“点名轴”再下钻模块，而不是盲目重装或改参数。例如，PVC Pending 可能涉及 provisioner 名错误、mon endpoint 未就绪或池不存在，需按轴逐一排查。这种结构化方法有助于避免在错误层调参，提升排障效率。
Rook v1.20 的配置迁移要点
Rook v1.20 起，Ceph-CSI Operator 成为配置 CSI 的唯一支持路径，CSI 设置从 rook-ceph-operator-config 中移除，新装必须使用 OperatorConfig 和 Driver CR。若遗漏 csi-operator.yaml 或 Helm 侧漏装 ceph-csi-drivers chart，会导致 CSI 控制面缺 ServiceAccount 或 Driver CR，表现为 ctrlplugin 起不来。升级时需注意相邻主版本限制和 HEALTH_ERR
控制面与数据面的分离
文章强调 PVC Bound 只代表供给契约完成，实际 I/O 仍走 RADOS 路径（如 krbd 或 CephFS 内核客户端）。因此，挂载成功但延迟异常时，应优先检查数据面（如 PG peering、MDS caps），而非编排层。这种分离有助于正确归因故障，避免将数据面问题误判为编排问题。
Q&A
Rook v1.20 中配置 CSI 的唯一支持路径是什么？
Rook v1.20 起，配置 CSI 的唯一支持路径是使用 Ceph-CSI Operator 和 OperatorConfig/Driver CR，旧的 rook-ceph-operator-config 键值方式不再支持。
PVC 长时间 Pending 且 Events 指向 provisioner，应该优先排查哪个轴？
应该优先排查 CSI RPC 轴，因为 PVC Pending 且 Events 指向 provisioner 通常意味着供给阶段（CreateVolume）有问题，而不是 Ceph 集群本身的问题。
Rook 升级时为什么必须一次一个主版本？
Rook 官方升级路径仅支持正式 release 之间的相邻主线升级（如 v1.19.x → v1.20.x），跳主版本不在支持面内，可能导致兼容性问题。
RBD 卷挂载成功后，I/O 路径是怎样的？
挂载成功后，I/O 进入内核 krbd（或驱动配置的用户态路径），然后进入 RADOS 客户端写路径，经过 PG 到 BlueStore。
Rook 和 CSI 编排中，三个不变量是什么？
三个不变量是：1) 声明式意图在 CR/PVC，权威执行在 Operator+CSI；2) 控制面与数据面分离；3) CSI 驱动名是跨对象契约，必须一致。
Rook v1.20 中，如果 CSI 控制面缺少 ServiceAccount 或 Driver CR，会有什么表现？
CSI 控制面会缺少 ServiceAccount 或 Driver CR，表现为 ctrlplugin 起不来，而不是 RADOS 健康问题。
VolumeSnapshot 与目录级快照的语义差别是什么？
VolumeSnapshot 是整卷级别的快照，而目录级快照只针对文件系统内的目录，两者语义不同。
