【Rook / CSI】快照与克隆：VolumeSnapshot 语义、扩容与 CRD 错位
内容提要
本文探讨Rook/CSI中K8s VolumeSnapshot API与Ceph快照机制的语义差异，指出RBD、CephFS subvolume和目录.snap快照粒度不同，VolumeSnapshot Ready状态并不代表应用一致性。重点分析external-snapshotter与CRD版本错位导致的快照故障，以及扩容、克隆、恢复演练中的操作纪律和责任划分。
延伸解读
快照语义差异：Ready 不等于一致
文章指出，K8s VolumeSnapshot 的 Ready 状态仅代表卷级时间点创建成功，并不保证应用一致性。RBD、CephFS subvolume 和目录 .snap 三种快照粒度不同，协作方式各异，常见误解是将其混为一谈。对于数据库等负载，需应用级 quiesce 或逻辑备份，不能单押 Ready 条件。
CRD 版本错位：快照故障的隐形杀手
external-snapshotter sidecar 与集群中 group snapshot CRD 版本不匹配时，即使未使用组快照功能，也可能导致单卷快照长期不 Ready。故障现象是 Ceph 健康但快照全坏，且 ceph -s 查不出问题。升级 Rook/CSI 时，应将快照 CRD/控制器纳入检查单，与 Ceph 镜像升级同等对待。
扩容与快照叠加的操作纪律
生产环境组合操作（先快照再扩容、从快照恢复等）需注意 RBD 对带快照 image 的容量边界敏感，避免有 snap 时缩容再扩容。扩容前确认快照保留需求，恢复演练使用新 PVC + dataSource，大规模克隆后安排 flatten 或清理，避免父盘无法删除。CephFS 扩容后应用看到新大小可能有延迟，需等待校验。
责任切割：备份链路中的角色划分
备份链路中，快照控制器和 CSI 负责创建卷级时间点，Ceph 负责保留 snap 可见性，应用所有者负责 quiesce 和恢复演练，平台负责版本对齐和容量策略。缺少应用所有者一行，所有 Ready 快照都会在恢复演练中暴露缺口。平台可用策略强制逻辑备份注解，但不能用 VolumeSnapshot 代替应用一致性保证。
Q&A
Kubernetes VolumeSnapshot 的 Ready 状态是否代表应用一致性？
不代表。VolumeSnapshot Ready 只表示卷级快照创建成功，不保证应用数据一致性。对于数据库等应用，需要应用级 quiesce 或逻辑备份来确保一致性。
RBD、CephFS subvolume 和目录 .snap 快照在粒度上有什么区别？
RBD VolumeSnapshot 针对整个 image；CephFS CSI VolumeSnapshot 针对整个 subvolume（对应 PVC 的子树）；CephFS .snap 目录快照针对用户创建的目录子树。粒度不同，协作机制也不同。
external-snapshotter 与 CRD 版本错位会导致什么故障？
会导致 VolumeSnapshot 长期不 Ready，甚至普通单卷快照也受影响。sidecar 在监视 group snapshot CRD 失败时可能拖垮工作队列，造成全局性快照功能障碍。
在 Rook 中，如何从 VolumeSnapshot 恢复或克隆 PVC？
创建新 PVC 时，将 dataSource 指向 VolumeSnapshot 或兼容的快照内容。RBD 走 clone/从 snap 建 image 路径，CephFS 走 subvolume 快照克隆语义。注意静态 PV 不支持动态操作。
Rook 中 PVC 扩容的前提条件是什么？
StorageClass 需设置 allowVolumeExpansion: true，并配置 controller-expand-secret。文件系统类型需在支持集合内，且节点与驱动版本匹配。缩容通常不支持。
在备份链路中，应用所有者应承担什么责任？
应用所有者负责应用级 quiesce、逻辑备份和恢复演练，不能仅依赖 VolumeSnapshot Ready 状态。平台无法用 VolumeSnapshot 代替应用一致性保证。
为什么恢复演练的标题应明确机制（如 RBD 或 CephFS）？
因为不同机制的前置、成功标准和数据校验方法不同。例如 RBD 恢复后需校验文件系统 journal，CephFS .snap 需校验目录子树和硬链接。使用同一份检查清单会导致虚假通过。
