Kubernetes 1.36 为数据库备份找回失去的保障
内容提要
Kubernetes 传统 CSI 快照按单个 PVC 逐一创建，多卷应用（如数据库数据与日志分离）会因写入时间差导致快照彼此不一致，恢复时才暴露。Kubernetes v1.36 正式推出 VolumeGroupSnapshot，通过标签选择器将相关 PVC 分组，由 CSI 驱动原子性地一次性快照，无需冻结应用。Velero 等备份工具已支持，使多卷备份真正一致。
延伸解读
多卷备份不一致的根源
传统 CSI 快照以单个 PVC 为对象，备份工具按顺序逐个创建。在快照 A 和 B 之间，应用仍在写入，可能导致 B 上的日志引用了 A 上未捕获的数据。每个快照单独看都健康，但整体描述了一个从未存在过的状态。这种不一致在恢复时才会暴露，且应用越繁忙、卷越多，不一致窗口越大。
VolumeGroupSnapshot 如何恢复一致性
Kubernetes v1.36 正式推出 VolumeGroupSnapshot，通过标签选择器将相关 PVC 分组，由 CSI 驱动原子性地一次性快照所有卷，无需冻结应用。它包含 VolumeGroupSnapshotClass、VolumeGroupSnapshot 和 VolumeGroupSnapshotContent 三个对象。标签选择器让组边界以 Kubernetes 原生方式表达，能适应卷的增减或调整。
备份工具的支持与恢复逻辑
Velero 等备份工具已支持 VolumeGroupSnapshot，将逐个快照改为按组快照。组快照会展开为每个成员卷的独立快照，恢复时仍逐个 PVC 重建，但所有成员共享同一时间点。这使一致性保证基于上游标准，而非某个工具的专有方案。
生产环境注意事项
组快照支持取决于 CSI 驱动，需检查驱动发行说明并提前创建 VolumeGroupSnapshotClass。原子性保证受存储后端能力限制，应通过实际恢复验证，而非仅看成功状态。单卷或独立卷仍适合单独快照。建议审计现有备份，多卷应用可能已存在未测试的不一致恢复点。
Q&A
Kubernetes 1.36 中 VolumeGroupSnapshot 是什么？
VolumeGroupSnapshot 是 Kubernetes v1.36 正式推出的新 API，它通过标签选择器将多个相关的 PVC 分组，由 CSI 驱动原子性地一次性快照，确保多卷应用（如数据库）的备份一致性。
为什么传统的 CSI 快照会导致多卷应用备份不一致？
传统 CSI 快照按单个 PVC 逐一创建，备份工具会依次对每个卷进行快照。在快照不同卷的间隔中，应用仍在写入，可能导致一个卷上的数据引用了另一个卷上未捕获的数据，从而产生不一致。
VolumeGroupSnapshot 如何保证多卷备份的一致性？
VolumeGroupSnapshot 通过标签选择器将属于同一应用的多个 PVC 分组，CSI 驱动会对所有选中的卷执行一次原子性的时间点快照，无需冻结应用，从而保证所有卷在同一时刻被捕获。
Velero 如何支持 VolumeGroupSnapshot？
Velero 将原本“遍历 PVC 并逐个快照”的逻辑改为“将相关 PVC 分组，作为一次操作进行组快照，然后跟踪每个卷成员用于恢复”。组快照会分解为单个卷快照，但所有成员共享同一时间点。
在什么情况下应该使用 VolumeGroupSnapshot？
当正确性依赖于多个卷共享同一时间点时，应使用 VolumeGroupSnapshot，例如数据库的数据和日志卷。对于单卷工作负载或真正独立的卷，仍可使用单个 PVC 快照。
在生产环境使用 VolumeGroupSnapshot 需要注意哪些限制？
需要注意：组快照支持取决于 CSI 驱动，需确认驱动已实现；原子性保证依赖于存储后端，应通过恢复验证；此外，应审计现有备份，因为多卷应用可能一直存在不一致的恢复点。
