Rook / CSI：K8s 上的 Ceph 编排内核
内容提要
该文章是一个关于Kubernetes存储编排的系列教程，重点介绍Rook与Ceph-CSI。内容涵盖CSI规范、Rook Operator、RBD/CephFS供给、快照克隆及升级闸门，共16篇。文章提供阅读路径和排障指南，帮助工程师理解PVC生命周期、故障定位及选型决策，强调在K8s环境中有效运维Rook-Ceph。
延伸解读
定位：编排层与内核层的分工
本系列明确将Rook/CSI定位为K8s编排层，与ceph/系列的内核机制（PG、BlueStore）互补。PVC一旦Bound，I/O仍走krbd→PG→BlueStore，编排层不重写数据面。读者需区分故障归属：写卡在PG或BlueStore查ceph/，PVC Pending或MountFailed则查本系列。
版本锚定与升级纪律
文章锚定Rook v1.20.4、Ceph-CSI v3.17.0、K8s v1.31–v1.36，并强调Rook v1.20强制Ceph-CSI Operator，升级需一次一个主版本。这提示运维者关注版本兼容性，避免CRD/sidecar错位导致的失败模式，如external-snapshotter与group snapshot CRD版本不一致。
选型考量：何时值得付Rook+Ceph的税
系列第14–16篇讨论选型，对比云CSI、Longhorn、裸Ceph/cephadm。文章暗示Rook+Ceph并非总是最优，需评估运维复杂度（如Operator、升级闸门）与收益。架构师应基于自身场景，利用排除树判断是否值得承担编排层的额外开销。
Q&A
Rook和Ceph-CSI在Kubernetes存储编排中分别扮演什么角色？
Rook是一个Kubernetes编排器，负责管理Ceph集群的生命周期（如mon/mgr/osd部署），而Ceph-CSI是容器存储接口（CSI）驱动，负责将PVC映射为RBD image或CephFS subvolume，并处理挂载、快照等操作。Rook v1.20起强制使用Ceph-CSI Operator来管理驱动。
PVC从Pending到Mounted，失败可能发生在哪些层？
失败可能发生在K8s API层（PVC/PV绑定）、CSI sidecar（如external-provisioner）、CSI Controller/Node服务、Rook Operator（CephCluster状态）、Ceph后端（如RBD image创建）或节点内核（如krbd模块缺失）。排障时需按层定位，参考系列第1-6、8、13篇。
RBD features与节点krbd能力不一致时会出现什么问题？
如果RBD image启用了节点krbd不支持的feature（如fast-diff、object-map），可能导致挂载成功但I/O异常或性能下降，甚至挂载失败。需确保StorageClass中指定的features与所有节点内核兼容，或使用支持的内核版本。
VolumeSnapshot在RBD和CephFS上分别提供什么保证？
RBD支持基于RBD快照的VolumeSnapshot，提供崩溃一致性；CephFS支持基于subvolume的快照，但语义与目录级.snap不同，且可能受MDS限制。两者都通过CSI external-snapshotter实现，但CRD版本错位可能导致失败。
Rook v1.20为什么强制使用Ceph-CSI Operator？升级时需要注意什么？
Rook v1.20起废弃了旧的ConfigMap方式管理Ceph-CSI，改用Operator（OperatorConfig/Driver）以简化部署和升级。升级时需遵循主版本纪律，一次只升一个主版本，并注意CSI CRD/sidecar版本与Rook/Ceph的兼容性，避免错位。
在Kubernetes中，何时应该选择Rook+Ceph而不是云CSI或Longhorn？
当需要自建存储、避免云厂商锁定、或需要Ceph的丰富特性（如快照、克隆、对象存储）时，Rook+Ceph合适。但若追求简单运维或云环境，云CSI或Longhorn可能更轻量。需根据团队运维能力、成本、性能要求权衡，参考系列第14-16篇。
Rook-Ceph排障时，如何定位PVC Pending或MountFailed问题？
按六轴映射：检查PVC事件、PV状态、CSI sidecar日志、Rook Operator日志、Ceph集群健康状态（如mon endpoint/Secret配置）、节点内核模块。例如，Pending可能因StorageClass不存在或provisioner未运行；MountFailed可能因krbd模块缺失或nodeplugin异常。
