（上）K8S 1.12大特性最快最深度解析：Kubernetes CSI Snapshot

前言

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(https://github.com/kubernetes-incubator/external-storage)库中。该原型基于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还原数据卷，以及演示如何使用这两种特性，敬请期待。