【Rook / CSI】选型收束：排除树、开放问题与系列边界关闭
内容提要
本文为“Rook/CSI：K8s上的Ceph编排内核”系列终章，聚焦选型收束。通过排除树机制判断何时该用Rook，明确其甜区为私有云/裸金属需RADOS语义场景，苦区为公有云叠Rook等。关闭与ceph/18的续作边界，列出不该跑Rook的否证条件，并给出ADR友好收束建议，强调先排除再选择，附版本钉与开放问题。
延伸解读
排除树：从“看场景”到可证伪判据
文章用排除树把选型从“各有优劣看场景”变成一系列可证伪的机制问题。每个节点都对应一个具体判据，比如是否需要RADOS语义、是否在公有云托管盘上、能否同时运维PVC六轴和Ceph五轴等。这种做法的好处是，每个决策点都能被明确记录和复核，而不是依赖模糊的经验。对于读者来说，这意味着在选型时，可以沿着树逐层自问，找到自己真正所处的分支，从而避免因品牌偏好或惯性而做出错误选择。
苦区警示：公有云叠Rook与无人懂PG/CSI
文章明确列出Rook的苦区，包括公有云叠Rook、无人懂PG/CSI、把Longhorn与Ceph当同义词、跳主版本升级等。这些场景下，Rook不仅不能带来收益，反而会增加运维负担和故障风险。例如，在公有云托管盘上再叠Rook，相当于双重税收，既付了云盘费用，又付了Rook的编排成本。读者应警惕这些常见误区，避免在不符合条件的环境中强行使用Rook。
ADR友好收束：用否证条件防止惯性续跑
文章强调选型结论应写入ADR，并附上否证条件，例如迁云、编制减员、Ceph改独立生命周期等。一旦触发这些条件，就必须重跑排除树，而不是以历史惯性继续使用Rook。这种做法将选型决策从一次性选择变为持续可审查的过程，有助于在环境变化时及时调整架构，避免因技术债累积而陷入被动。读者在制定自己的选型文档时，也应明确列出触发重新评估的条件。
Q&A
在Kubernetes中，什么时候应该使用Rook来部署Ceph？
当需要RADOS语义（如RBD和CephFS在同一集群），且Ceph生命周期必须绑定在K8s内，同时团队能同时运维PVC六轴和Ceph五轴，并能执行特性对齐和升级门禁时，Rook是合适的选择。典型场景是私有云或裸金属环境。
在公有云上使用Rook部署Ceph有什么问题？
在公有云虚机使用托管盘时，再叠加Rook会形成双层税（云盘税+Rook税），因此应直接使用云CSI，避免在云盘上做OSD再套Rook。
哪些情况下不应该运行Rook？
以下情况不应运行Rook：数据面不需要RADOS；公有云托管盘已够用；Ceph必须独立于K8s生命周期；编制上撑不住六轴+五轴；不能执行升级主版本纪律或features门禁；把Rook当“点一下就有Ceph”且无人读观测排障文档。
Rook和Ceph系列的分工边界是什么？
Ceph系列覆盖PG/BlueStore/peering等RADOS内核问题；Rook/CSI系列覆盖CSI RPC、sidecar、Rook CRD、CSI Operator等编排问题。两者不再互相推诿，分工明确。
Rook选型时如何用排除树做决策？
排除树通过一系列可证伪的机制问题引导决策：先问是否需要RADOS语义，若不需要则看是否需要块存储，进而考虑云CSI或Longhorn；若需要RADOS，则评估团队能力、生命周期绑定、特性门禁等，最终决定是否使用Rook。
Rook/CSI系列有哪些开放问题？
开放问题包括：feature能力能否在调度前失败；mon endpoint/Secret漂移闭环；fencing冷却与应用RTO；sidecar直方图与Ceph slow ops的自动归因；加密双税的合规逼迫下的可测量代价。
如何将Rook选型决策写入ADR？
将排除树进ADR，写清卡在哪一叶机制判据，附否证条件（如迁云、编制减员、Ceph改独立生命周期、强制双加密、关闭fencing等）。示例句：若块存储迁到公有云托管盘，或存储值班从双方言编制降为零，则Rook+Ceph-CSI叶必须重跑排除树，禁止以历史惯性续跑。
Rook/CSI系列中，版本锚定是什么？
版本锚定为：Rook v1.20.4；Ceph-CSI v3.17.0；K8s v1.31–v1.36；Ceph后端Squid v19.2.x / Tentacle v20.2.1+。
