前言
CSI snapshot 是由华为在 Kubernetes 社区主导开发的存储特性，在 K8S 1.12进入Alpha阶段。接下来，我们将分为上下两篇，分别介绍snapshot的创建删除等API以及从snapshot还原数据卷，同时，我们将使用CSI hostpath 插件来演示，如何使用这两种特性。
Kubernetes CSI Snapshot（上篇）
背景
许多存储系统提供了创建存储卷“快照”（snapshot）的能力，以防止数据丢失。快照可以替代传统的备份系统来备份和还原主要数据和关键数据。快照能够快速备份数据（例如，创建GCE PD快照仅需要几分之一秒）， 并提供快速恢复时间目标（RTO）和恢复点目标（RPO）。快照还可用于数据复制、分发和迁移。 早在kubernetes 1.8版本中，卷快照系统原型已经发布,其实现位于 external-storage(github.com/kubernetes-…)库中。该原型基于 CRD 实现，提供了外部 controller 和 provisioner 两个二进制，支持 GCE PD，AWS EBS，OpenStack Cinder，GlusterFS 和 Kubernetes hostPath 等存储卷。
Kubernetes 的社区存储趋势是采用 CSI 实现存储插件，本文添加对 CSI 存储插件的快照支持。Kubernetes 的趋势是保持核心 API 尽可能小，因此我们采用 CRD 实现，并添加一个外部快照控制器来处理卷快照，external provisioner 也会升级以支持从快照创建 volume，CSI snapshot规范详情可以在https://github.com/container-storage-interface/spec/pull/224 查看。
目标
对于 Kubernetes 中的第一个快照支持版本，我们仅支持 CSI 卷插件按需创建快照。
- 目标1：实现标准化的快照操作，支持创建，列出和删除快照等 REST API。目前，API 将使用 CRD（CustomResourceDefinitions）实现。
- 目标2：实现CSI卷快照支持。
external-snapshotter将与 CSI 卷插件的其他外部组件（例如，external-attacher, external-provisioner）一起部署。 - 目标3：提供一种从快照创建新存储卷和还原现有卷的便捷方法。 以下目标本阶段将不会实现，但将在稍后阶段考虑。
- 目标4：通过提供
pre/post快照钩子来冻结/解冻应用程序和/或卸载/挂载文件系统，从而提供应用程序一致性快照。 - 目标5：提供更高级别的管理，例如备份和还原 pod 和 statefulSet，以及创建一致性的快照组。
详细设计
在此提案中，卷快照被视为 Kubernetes 管理的另一种存储资源。 因此，快照 API 和控制器遵循现有卷管理的设计模式。
- VolumeSnapshot
- VolumeSnapshotContent
- VolumeSnapshotClass
三个 API，它们与 PersistentVolumeClaim 和 PersistentVolume 以及 storageClass 的结构类似。外部快照控制器的功能类似于 in-tree 的 PV 控制器。同时建议在 PersistentVolumeClaim（PVC）API 中添加新的数据源结构，以支持从快照还原数据卷。 以下部分将详细介绍 API 和控制器设计。
Snapshot API设计
VolumeSnapshot 和 VolumeSnapshotContent API 是在 PersistentVolumeClaim 和 PersistentVolume 之后建模设计的。 在第一个版本中，VolumeSnapshot 生命周期完全独立于其来源（PVC）。 删除 PVC / PV 时，相应的 VolumeSnapshot 和 VolumeSnapshotContent 对象将继续存在。 但是，对于某些卷插件，快照依赖于其存储卷。 在未来的版本中，我们计划进行完整的生命周期管理，以便更好地处理快照与其卷之间的关系。（例如，添加finalizer，当有快照依赖于存储卷时，可防止存储卷被删除）。
VolumeSnapshot对象
VolumeSnapshotContent对象
VolumeSnapshotClass对象
我们将添加新的 API 对象 VolumeSnapshotClass，而不是复用现有的 StorageClass，以避免在 snapshot 和 volume 之间混合参数。每个 CSI 卷插件都可以拥有自己的默认 VolumeSnapshotClass。如果未提供 VolumeSnapshotClass，则将使用默认值。VolumeSnapshotClass 将为快照添加新的参数。
Snapshot Controller 设计要点
如下图所示，CSI 快照控制器体系结构由 external-snapshotter（外部快照器）组成，external-snapshotter 通过套接字与 out-of-tree CSI 卷插件进行通信（默认情况下为/ run / csi / socket，可由 -csi-address 配置）。external-snapshotter 是 Kubernetes 实现容器存储接口（CSI）的一部分。 它是一个外部控制器，用于监视 VolumeSnapshot 和 VolumeSnapshotContent 对象并创建/删除快照。
- 通常
external-snapshotter使用ControllerGetCapabilities来验证 CSI 驱动程序是否支持CREATE_DELETE_SNAPSHOT调用。 external-snapshotter负责创建/删除快照及绑定 VolumeSnapshot 和 VolumeSnapshotContent 对象。它遵循 kubernetes 控制器模式并使用 informer 来监视 VolumeSnapshot 和 VolumeSnapshotContent 创建/更新/删除事件。通过 Snapshotter == <CSI 卷插件名字>过滤掉不符合的 VolumeSnapshot 实例，并使用具有指数退避的工作队列处理这些事件。- 对于动态创建的快照，它应该关联某个 VolumeSnapshotClass。用户可以在 VolumeSnapshot API 对象中显式指定 VolumeSnapshotClass。如果用户未指定 VolumeSnapshotClass，则将使用 admin 创建的默认 VolumeSnapshotClass。这和使用默认的 StorageClass 来配置 PersistentVolumeClaim 相似。
- 对于静态绑定快照，
user/admin必须为 VolumeSnapshot 和 VolumeSnapshotContent 正确指定双向指针，以便控制器知道如何绑定它们。否则，如果 VolumeSnapshot 指向不存在的 VolumeSnapshotContent，或者是 VolumeSnapshotContent 并未指向 VolumeSnapshot，则将 VolumeSnapshot 设置为错误状态。 - 针对每一个 CSI 卷插件，external-snapshotter、external-attacher和external-provisioner 运行在同一个 sidecar 中。
- 在当前设计中，当存储系统无法创建快照时，将不会在控制器中执行重试。这是因为当快照创建的时间很重要时，用户可能不想在获取一致性快照或计划快照时重试。在将来的版本中，将添加 maxRetries 标志或重试终止时间戳，以允许用户控制是否需要重试。
本篇文章主要介绍了 snapshot 的 API 对象，以及 external-snapshotter 的架构设计和实现原理，下篇文章，我们将会介绍从snapshot 还原数据卷，以及演示如何使用这两种特性，敬请期待。