K8S 1.12大特性最快最深度解析：Kubernetes CSI Snapshot（上）_设计模式_weixin

前言

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 还原数据卷，以及演示如何使用这两种特性，敬请期待。