Geekly articles weekly

在Kubernetes中引入卷快照的Alpha版本



注意事项 佩雷夫 ：最初的文章最近发表在Kubernetes博客上，由Google和华为（徐静，杨星，Saad Ali）的员工撰写，如果您对K8的功能和与之相关的问题感兴趣，您肯定会在该项目的GitHub上看到他们的活动。与数据存储。 工程师讨论了卷快照的用途，其当前功能以及使用它们的基础知识。

Kubernetes v1.12引入了对卷快照的支持的Alpha版本。 此功能使您可以创建和删除卷的快照，以及通过Kubernetes API使用系统的“本机”方式从快照中创建新卷。

什么是快照？


许多存储系统（例如Google Cloud永久磁盘，Amazon Elastic Block Storage和许多本地存储系统）都提供了为永久卷创建快照（“快照”）的功能。 快照是在特定时间点的卷的副本。 它可用于提供一个新卷（已经用快照中的数据填充）或将现有卷还原到以前的状态（在快照中显示）。

为什么要将快照添加到Kubernetes？


Kubernetes卷插件系统中已经提供了强大的抽象功能，可以自动配置，连接和安装块和文件存储。

提供所有这些功能是Kubernetes的工作负载容忍目标的一部分：Kubernetes旨在在充当分布式系统的应用程序和基础集群之间创建抽象级别，以便应用程序独立于运行它们的特定集群，并且不需要应用程序部署任何特定于群集的知识。

Kubernetes Storage SIG已将快照操作确定为各种有状态工作负载的关键功能。 例如，数据库管理员可能想在对其数据库执行任何操作之前先对其数据库进行快照。

通过使Kubernetes API成为调用快照操作的标准方式，Kubernetes用户可以使用它们，而无需解决方法（以及手动调用特定于存储系统的操作）。 取而代之的是，让用户有机会将快照操作嵌入他们的工具和策略中，这是一种冷静的理解，即无论底层存储如何，一切都将适用于任何Kubernetes集群。

此外，这些Kubernetes原语用作基本构建块，为开发用于存储管理（例如保护，复制和数据迁移）的更高级企业级功能开辟了道路。

哪些卷插件支持Kubernetes中的快照？


Kubernetes支持三种类型的批量插件：in-tree，Flex和CSI。 有关详细信息，请参见Kubernetes Volume Plugin FAQ 。

仅CSI驱动程序支持快照（树内或Flex均不支持快照）。 要利用此功能，请确保在Kubernetes群集中部署了实现快照支持的CSI驱动程序。

在撰写本博文时（2018年10月9日- 大约翻译 ） ，以下CSI驱动程序支持快照：


对其他驱动程序快照的支持正在开发中，应尽快提供。 有关CSI以及如何部署CSI驱动程序的更多详细信息，在出版物“ Kubernetes Goes Beta的容器存储接口（CSI）”中进行了描述 （另请参见注释“ 理解容器存储接口（在Kubernetes等）中 ”的翻译） - 大约翻译 ） 。

Kubernetes快照API


为了管理快照，Kubernetes Volume Snapshots以与Kubernetes Persistent Volumes API中相同的方式引入了三个新的API对象：

  • VolumeSnapshot
    • 由Kubernetes用户创建，以请求指定卷的快照。 包含有关快照操作的信息，例如删除快照的时间戳以及快照是否准备就绪。
    • 与PersistentVolumeClaim对象类似，创建和删除该对象表示用户希望创建或删除群集资源（快照）。
  • VolumeSnapshotContent
    • 成功创建快照后，由CSI驱动程序创建。 包含有关快照的信息，包括其ID。
    • 像PersistentVolume对象一样，它表示群集已经提供的资源（快照）。
    • 与PersistentVolumeClaim和PersistentVolume对象类似，创建快照时， VolumeSnapshotContent对象VolumeSnapshotContent附加到VolumeSnapshot创建快照的VolumeSnapshotContent （使用一对一映射）。
  • VolumeSnapshotClass
    • 由集群管理员定义，以描述可以创建哪些快照。 包括驱动程序信息，用于访问快照的机密等。

需要注意的是，与Kubernetes中的主要Persistent Volume对象不同，这些快照对象被定义为CustomResourceDefinitions（CRD） 。 Kubernetes项目正在逐步摆脱API服务器中预定义的资源类型，而采用一种模型，其中API服务器独立于API对象。 这种方法允许您在其他项目中（除了Kubernetes之外）重用API服务器，并且使用者（例如Kubernetes）可以将其所需的资源类型设置为CRD。

支持快照的CSI驱动程序将自动安装必要的CRD。 Kubernetes最终用户只需要验证群集中是否部署了支持快照的CSI驱动程序。

除了这些新对象之外，现有的PersistentVolumeClaim一个新的DataSource字段：

 type PersistentVolumeClaimSpec struct { AccessModes []PersistentVolumeAccessMode Selector *metav1.LabelSelector Resources ResourceRequirements VolumeName string StorageClassName *string VolumeMode *PersistentVolumeMode DataSource *TypedLocalObjectReference }

创建新卷时，此字段（处于Alpha版本状态）允许您自动使用现有快照中的数据填充它。

Kubernetes快照要求


在Kubernetes中使用卷快照之前，您必须：

  • 确保实现快照的CSI驱动程序已在群集上部署并运行；
  • 通过新功能门启用Kubernetes Volume Snapshotting功能（默认情况下对于Alpha版本禁用）：
    • 为API Server --feature-gates=VolumeSnapshotDataSource=true设置以下标志：-- --feature-gates=VolumeSnapshotDataSource=true

在创建快照之前，还必须确定要使用的CSI驱动程序，这是通过创建VolumeSnapshotClass对象并在VolumeSnapshotClass字段中指定CSI驱动程序来完成的。 在下面的VolumeSnapshotClass示例中，此驱动程序是com.example.csi-driver 。 每个快照提供程序至少需要一个VolumeSnapshotClass对象。 也可以为每个CSI驱动程序定义一个默认的VolumeSnapshotClass这可以通过在类定义中设置snapshot.storage.kubernetes.io/is-default-class: "true"注释来完成：

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: default-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" snapshotter: com.example.csi-driver apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotClass metadata: name: csi-snapclass snapshotter: com.example.csi-driver parameters: fakeSnapshotOption: foo csiSnapshotterSecretName: csi-secret csiSnapshotterSecretNamespace: csi-namespace

必须根据CSI驱动程序文档设置所有必需的参数。 在上面的示例中，在创建和删除快照期间， fakeSnapshotOption: foo参数和所有提及的机密将传递给CSI驱动程序。 默认情况下， CSI external-snapshotter保存csiSnapshotterSecretName和csiSnapshotterSecretNamespace参数密钥。

最后，在创建快照之前，必须通过CSI驱动程序创建卷，并在其中填充要在其中查看的数据（有关如何使用CSI卷的详细信息，请参阅此出版物 ）。

在Kubernetes中创建新快照


一旦定义了VolumeSnapshotClass对象并且该对象VolumeSnapshotClass要从中删除快照的卷，就可以通过创建VolumeSnapshot对象来执行此操作。

快照的来源由两个参数确定：

  • kind -这里显示了PersistentVolumeClaim ；
  • name -PVC对象的实际名称。

可以理解，为其创建快照的卷的名称空间由VolumeSnapshot对象的名称空间确定。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: new-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass source: name: mypvc kind: PersistentVolumeClaim

VolumeSnapshot规范可以VolumeSnapshot一个VolumeSnapshotClass ，其中包含有关将使用哪个CSI驱动程序来创建快照的信息。 如先前所报道，在创建VolumeSnapshot对象之后VolumeSnapshot fakeSnapshotOption: foo参数和所有提到的VolumeSnapshotClass机密将在CreateSnapshot调用中传递给CSI插件com.example.csi-driver 。

响应于这样的请求，CSI驱动程序获取卷的快照，然后自动创建一个代表新快照的VolumeSnapshotContent对象，并将该对象附加到VolumeSnapshot ，以备使用。 如果CSI驱动程序无法创建快照并返回错误，则快照控制器将在VolumeSnapshot对象的状态中报告此错误，并且不会进行新的尝试（此行为与Kubernetes中的其他控制器不同-实现该行为是为了避免在不可预测的时间创建快照） 。

如果未指定快照类，则外部快照者将尝试查找默认类并将其用于创建的快照。 在这种情况下， snapshotter在默认类中指向的CSI驱动程序应与PVC存储类中的provisioner程序所指向的CSI驱动程序相对应。

请注意，Kubernetes快照的Alpha版本不保证一致性。 为了确保快照中的完整数据，有必要在删除应用程序之前对其进行适当的准备（停止应用程序，冻结文件系统等）。

要VolumeSnapshot创建VolumeSnapshot对象并将其与VolumeSnapshotContent关联，可以使用kubectl describe volumesnapshot ：

  • Ready应为true ，这将指示已准备好使用卷快照。
  • Creation Time字段显示实际拍摄快照的Creation Time 。
  • Restore Size字段是还原快照的最小卷大小。
  • 规范中的“ Snapshot Content Name字段指向为此快照创建的VolumeSnapshotContent对象。

将现有快照导入Kubernetes


可以通过手动创建一个代表该快照的VolumeSnapshotContent对象，将现有快照导入Kubernetes。 由于VolumeSnapshotContent是不与命名空间绑定的API对象，因此只有系统管理员才有权创建它。

创建VolumeSnapshotContent对象时，用户可以创建另一个指向该对象的对象VolumeSnapshot 。 在检查VolumeSnapshot和VolumeSnapshotContent之间是否存在连接和正确性之后，外部快照VolumeSnapshot器控制器会将快照标记为就绪。 建立此连接后，快照即可在Kubernetes中使用。

必须使用以下表示预配置快照的字段创建VolumeSnapshotContent对象：

  • csiVolumeSnapshotSource标识快照的信息：
    • snapshotHandle名称/标识符。 必填项
    • driver-用于此卷的CSI驱动程序。 必填字段。 必须与控制器（快照控制器）中snapshotter的名称匹配；
    • creationTime和restoreSize对于预配置的卷，这些字段是可选的。 创建快照后，外部快照程序控制器将自动更新它们。
  • volumeSnapshotRef指向应将此对象（即VolumeSnapshotContent ）附加到的VolumeSnapshot对象的指针：
    • name和namespace -绑定了内容的VolumeSnapshot对象的名称和名称空间；
    • UID可选（用于预先准备的卷）字段。 绑定后，外部快照程序控制器将自动更新此字段。 如果用户定义了该字段，则需要确保它与发生绑定的快照的UID相匹配。 如果没有这样的对应关系，则认为内容无关紧要（孤立对象），因此控制器将删除该内容和关联的快照。
  • snapshotClassName是一个可选字段。 绑定后，外部快照器控制器将自动对其进行更新。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: static-snapshot-content spec: csiVolumeSnapshotSource: driver: com.example.csi-driver snapshotHandle: snapshotcontent-example-id volumeSnapshotRef: kind: VolumeSnapshot name: static-snapshot-demo namespace: demo-namespace

必须创建VolumeSnapshot对象，以便用户可以使用快照。 在其中：

  • snapshotClassName卷的快照类的名称。 可选字段。 如果已设置，则snapshotter类中的snapshotter字段应与快照控制器的名称匹配。 如果未设置，则控制器将查找默认快照类；否则，控制器将查找默认快照类。
  • snapshotContentName快照卷内容的名称。 预先准备的卷的必填字段。

 apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: static-snapshot-demo namespace: demo-namespace spec: snapshotClassName: csi-snapclass snapshotContentName: static-snapshot-content

创建这些对象后，快照控制器将绑定它们，将“ Ready字段（在“ Status ）设置为True ，表示快照已准备就绪。

从Kubernetes中的快照准备新卷


要创建一个预填充了快照对象中数据的新卷，请使用PersistentVolumeClaim的new dataSource字段。 它具有三个参数：

  • VolumeSnapshot代表快照源的VolumeSnapshot对象的名称；
  • VolumeSnapshot应该设置为VolumeSnapshot ;
  • apiGroup应该是snapshot.storage.k8s.io 。

假定源的名称空间（ VolumeSnapshot ）与PersistentVolumeClaim的名称空间匹配。

 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-restore Namespace: demo-namespace spec: storageClassName: csi-storageclass dataSource: name: new-snapshot-demo kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 1Gi

创建PersistentVolumeClaim对象时，它将调用新卷的配置，该新卷已预填充了来自指定快照的数据。

如果我是存储开发人员，如何为我的CSI驱动程序添加快照支持？


为了提供对快照的支持，应将其他控制器功能添加到CSI驱动程序： CREATE_DELETE_SNAPSHOT和LIST_SNAPSHOTS ，以及其他RPC控制器： CreateSnapshot ， DeleteSnapshot ， ListSnapshots 。 有关详细信息，请参见CSI规范 。

尽管Kubernetes提供了打包和部署CSI Volume Driver的最基本准则 ，但是还是建议使用一种机制在Kubernetes中部署任意容器化的CSI驱动程序，以简化此过程。

作为建议的部署过程的一部分，Kubernetes团队建议使用各种附带（即辅助）容器，包括带有外部快照器的附带容器。

提到的外部快照程序监视API服务器中的VolumeSnapshot和VolumeSnapshotContent对象，并为CSI端点调用CreateSnapshot和DeleteSnapshot 。 带有CSI external-provisioner的sidecar容器也已更新，以支持使用新的PVC dataSource字段从快照进行卷恢复。

为了支持快照功能，建议存储制造商在外部置备器之外，还通过外部快照程序部署sidecar容器，并将CSI驱动程序放在StatefulSet ，如下图所示：



在此部署示例中，有两个sidecar容器，一个外部供应器和一个外部快照器，并且CSI驱动程序与StatefulSet容器内的CSI主机路径插件一起部署。 CSI主机路径是一个示例插件，不适用于生产环境。

alpha版本的局限性是什么？


Kubernetes中快照实现的Alpha版本具有以下限制：

  • 不支持将现有卷回滚到快照代表的先前状态（仅支持从快照配置新卷）。
  • 快照中的现有PersistentVolumeClaim不支持就地还原： 通过快照配置新卷是可行的，但不会更新现有的PersistentVolumeClaim ，使其指向新卷，并且PVC回滚到较早的状态（仅支持通过新PV / PVC使用从快照创建的新卷）。
  • 快照一致性的保证不会超出存储系统提供的保证（例如，删除时的完整性）。

接下来是什么？


Kubernetes团队计划根据收到的反馈和技术的适应性，将CSI快照的实现引入1.13或1.14版的beta版本。

如何找出更多细节？


请参阅k8s.io/docs/concepts/storage/volume-snapshots和kubernetes-csi.imtqy.com/docs上的其他快照文档。

译者的PS


另请参阅我们的博客：

Source: https://habr.com/ru/post/zh-CN426133/

More articles:


All Articles