2. CSI驱动与VolumeSnapshot：CSI规范对快照的支持、CSI Driver与VolumeSnapshot的交互流程

Kubernetes 从 v1.12 引入 Volume Snapshot 的 alpha 支持，并在 v1.20 正式 GA。其底层依赖 CSI（Container Storage Interface）规范对快照操作的原生定义。理解 CSI 驱动如何实现快照能力，以及控制面与数据面的交互流程，是掌握 VolumeSnapshot 版本差异校验的基础。

2.1 CSI规范对快照的支持

CSI 规范自 v1.0 起定义了 CreateSnapshot、DeleteSnapshot、ListSnapshots 三个 RPC 方法，以及对应的 VolumeSnapshotContent 资源模型。CSI 驱动必须实现这些 RPC 才能被 Kubernetes 快照控制器调用。

2.2 CSI Driver与VolumeSnapshot的交互流程

一次完整的 VolumeSnapshot 创建流程涉及 API Server、快照控制器（snapshot-controller）、CSI 驱动（CSI Driver） 以及 存储后端 四个角色。下图展示了核心交互步骤：

2.3 交互步骤详解

1. 用户创建 VolumeSnapshot 对象：用户通过 kubectl 或 API 创建 VolumeSnapshot CR，指定 source（PVC 名称）和 volumeSnapshotClassName。
2. snapshot-controller 监听并协调：控制器 watch 到 VolumeSnapshot 对象后，查找对应的 VolumeSnapshotClass，并调用 CSI 驱动的 CreateSnapshot RPC。
3. CSI Driver 调用存储后端：CSI 驱动将 RPC 请求转换为存储后端的快照 API（如 AWS EBS CreateSnapshot、Ceph RBD snap create）。
4. 存储后端返回快照标识：后端创建完成后返回 snapshot_id 和 creation_time。
5. CSI Driver 返回响应：CSI 驱动将后端返回的信息封装为 CreateSnapshotResponse，包含 snapshot_id、ready_to_use、creation_time 等字段。
6. snapshot-controller 创建 VolumeSnapshotContent：控制器根据 CSI 响应创建 VolumeSnapshotContent 对象，绑定到 VolumeSnapshot，并更新状态为 ReadyToUse。

2.4 CSI Driver Sidecar 容器角色

CSI 驱动通常以 DaemonSet 形式部署，但快照相关的控制面操作由 csi-snapshotter sidecar 容器完成。该 sidecar 负责：

• 监听 VolumeSnapshotContent 对象的创建/删除事件
• 调用 CSI 驱动的 Unix Domain Socket 执行快照 RPC
• 将 CSI 响应写回 VolumeSnapshotContent 的 status 字段

2.5 快照删除与回收流程

VolumeSnapshot 的删除流程与创建类似，但方向相反：

1. 用户删除 VolumeSnapshot 对象（或设置 deletionPolicy: Delete）
2. snapshot-controller 检测到删除事件，调用 CSI 驱动的 DeleteSnapshot RPC
3. CSI 驱动通知存储后端删除快照数据
4. 存储后端确认删除后，CSI 驱动返回成功响应
5. snapshot-controller 删除对应的 VolumeSnapshotContent 对象

当 deletionPolicy: Retain 时，VolumeSnapshotContent 会保留在集群中，但 VolumeSnapshot 对象被删除，用户需要手动管理 VolumeSnapshotContent 的生命周期。