本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.27:引入卷组快照 API

Kubernetes v1.27 中引入了卷组快照作为 Alpha 功能。此功能引入了一个 Kubernetes API,允许用户为多个卷一起进行崩溃一致性快照。它使用标签选择器将多个 PersistentVolumeClaims 分组以进行快照。此新功能仅支持 CSI 卷驱动程序。

卷组快照概述

一些存储系统提供创建多个卷的崩溃一致性快照的能力。组快照表示在同一时间点拍摄的多个卷的“副本”。组快照可用于重新水化新卷(预先填充快照数据)或将现有卷恢复到之前的状态(由快照表示)。

为什么要向 Kubernetes 添加卷组快照?

Kubernetes 卷插件系统已经提供了一个强大的抽象,可以自动执行块存储和文件存储的配置、连接、挂载、调整大小和快照。

所有这些功能的基础是 Kubernetes 的工作负载可移植性目标:Kubernetes 旨在在分布式应用程序和底层集群之间创建一个抽象层,以便应用程序可以忽略它们运行的集群的细节,并且应用程序部署不需要特定于集群的知识。

已经有一个 VolumeSnapshot API,它提供了对持久卷进行快照以防止数据丢失或数据损坏的能力。但是,VolumeSnapshot API 没有涵盖其他快照功能。

一些存储系统支持一致的组快照,允许从多个卷在同一时间点进行快照,以实现写入顺序一致性。这对于包含多个卷的应用程序很有用。例如,一个应用程序可能将数据存储在一个卷中,将日志存储在另一个卷中。如果数据卷和日志卷的快照在不同的时间拍摄,则应用程序将不一致,并且如果在发生灾难时从这些快照恢复,则无法正常运行。

的确,您可以先暂停应用程序,然后从应用程序的每个卷依次获取单独的快照,然后在获取所有单独的快照后取消暂停应用程序。这样,您将获得应用程序一致的快照。

但是,有时可能无法暂停应用程序,或者应用程序暂停的成本可能太高,因此您希望减少暂停的频率。与拍摄一致的组快照相比,依次拍摄单个快照也可能需要更长的时间。出于这些原因,一些用户可能不想经常进行应用程序暂停。例如,用户可能希望每周使用应用程序暂停运行备份,并每晚在没有应用程序暂停的情况下运行备份,但具有跨组中所有卷的崩溃一致性的一致组支持。

Kubernetes 卷组快照 API

Kubernetes 卷组快照引入了 三个新的 API 对象来管理快照

VolumeGroupSnapshot
由 Kubernetes 用户(或可能是您自己的自动化)创建,以请求为多个持久卷声明创建卷组快照。它包含有关卷组快照操作的信息,例如获取卷组快照的时间戳以及是否已准备好使用。此对象的创建和删除表示创建或删除集群资源(组快照)的意愿。
VolumeGroupSnapshotContent
由快照控制器为动态创建的 VolumeGroupSnapshot 创建。它包含有关卷组快照的信息,包括卷组快照 ID。此对象表示集群上已配置的资源(组快照)。VolumeGroupSnapshotContent 对象绑定到为其创建的 VolumeGroupSnapshot,具有一对一的映射。
VolumeGroupSnapshotClass
由集群管理员创建,用于描述应如何创建卷组快照。包括驱动程序信息、删除策略等。

这三种 API 类型定义为 CustomResourceDefinitions (CRD)。必须在 Kubernetes 集群中安装这些 CRD,以便 CSI 驱动程序支持卷组快照。

如何使用 Kubernetes 卷组快照

卷组快照在 external-snapshotter 存储库中实现。实现卷组快照意味着添加或更改多个组件

  • 为 VolumeGroupSnapshot 和两个支持 API 添加了新的 CustomResourceDefinitions。
  • 卷组快照控制器逻辑已添加到通用快照控制器。
  • 卷组快照验证 Webhook 逻辑已添加到通用快照验证 Webhook。
  • 添加逻辑以使 CSI 调用进入快照器边车控制器。

卷快照控制器、CRD 和验证 Webhook 每个集群部署一次,而边车则与每个 CSI 驱动程序捆绑在一起。

因此,将卷快照控制器、CRD 和验证 Webhook 部署为集群附加组件是有意义的。我强烈建议 Kubernetes 分发商捆绑并部署卷快照控制器、CRD 和验证 Webhook 作为其 Kubernetes 集群管理过程的一部分(独立于任何 CSI 驱动程序)。

使用 Kubernetes 创建新的组快照

一旦定义了 VolumeGroupSnapshotClass 对象,并且您拥有要一起快照的卷,您可以通过创建 VolumeGroupSnapshot 对象来请求新的组快照。

组快照的来源指定了应动态创建底层组快照还是应使用预先存在的 VolumeGroupSnapshotContent。

预先存在的 VolumeGroupSnapshotContent 由集群管理员创建。它包含存储系统上可供集群用户使用的真实卷组快照的详细信息。

必须设置组快照源中的以下成员之一。

  • selector - 对要分组在一起进行快照的 PersistentVolumeClaims 的标签查询。此 labelSelector 将用于匹配添加到 PVC 的标签。
  • volumeGroupSnapshotContentName - 指定表示现有卷组快照的预先存在的 VolumeGroupSnapshotContent 对象的名称。

在以下示例中,有两个 PVC。

NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s

标记 PVC。

% kubectl label pvc pvc-0 group=myGroup
persistentvolumeclaim/pvc-0 labeled

% kubectl label pvc pvc-1 group=myGroup
persistentvolumeclaim/pvc-1 labeled

对于动态配置,必须设置一个选择器,以便快照控制器可以找到具有匹配标签的 PVC 以一起进行快照。

apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
kind: VolumeGroupSnapshot
metadata:
  name: new-group-snapshot-demo
  namespace: demo-namespace
spec:
  volumeGroupSnapshotClassName: csi-groupSnapclass
  source:
    selector:
      matchLabels:
        group: myGroup

在 VolumeGroupSnapshot 规范中,用户可以指定 VolumeGroupSnapshotClass,其中包含有关应使用哪个 CSI 驱动程序来创建组快照的信息。

作为卷组快照创建的一部分,将创建两个单独的卷快照。

snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
snapshot-2026811eb9f0787466171fe189c805a22cdb61a326235cd067dc3a1ac0104900-2023-04-26-2.20.4

如何在 Kubernetes 中使用组快照进行还原

在还原时,用户可以请求从作为 VolumeGroupSnapshot 一部分的 VolumeSnapshot 对象创建新的 PersistentVolumeClaim。这将触发预先填充指定快照数据的卷的配置。用户应重复此操作,直到从组快照的所有快照中创建所有卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc0-restore
  namespace: demo-namespace
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

作为存储供应商,如何为我的 CSI 驱动程序添加对组快照的支持?

要实现卷组快照功能,CSI 驱动程序必须

  • 实现新的组控制器服务。
  • 实现组控制器 RPC:CreateVolumeGroupSnapshotDeleteVolumeGroupSnapshotGetVolumeGroupSnapshot
  • 添加组控制器功能 CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT

有关更多详细信息,请参阅 CSI 规范Kubernetes-CSI 驱动程序开发人员指南

作为 CSI 卷驱动程序,它提供了一种建议的机制来部署容器化的 CSI 驱动程序以简化该过程。

作为此建议部署过程的一部分,Kubernetes 团队提供了许多边车(辅助)容器,包括已更新以支持卷组快照的 external-snapshotter 边车容器

external-snapshotter 监视 Kubernetes API 服务器的 VolumeGroupSnapshotContent 对象,并针对 CSI 端点触发 CreateVolumeGroupSnapshotDeleteVolumeGroupSnapshot 操作。

有哪些限制?

Kubernetes 的卷组快照的 alpha 实现具有以下限制

  • 不支持将现有 PVC 恢复到快照表示的早期状态(仅支持从快照配置新卷)。
  • 除了存储系统提供的任何保证(例如崩溃一致性)之外,没有应用程序一致性保证。有关应用程序一致性的更多讨论,请参阅此 文档

下一步是什么?

根据反馈和采用情况,Kubernetes 团队计划在 1.28 或 1.29 中将 CSI 组快照实现推送到 Beta 版。我们有兴趣支持的一些功能包括卷复制、复制组、卷放置、应用程序暂停、更改的块跟踪等。

如何了解更多信息?

如何参与?

与所有 Kubernetes 项目一样,此项目是来自不同背景的众多贡献者共同努力的成果。我谨代表 SIG Storage,衷心感谢在过去几个季度挺身而出,帮助项目达到 alpha 阶段的贡献者们。

我们还要感谢为该项目做出贡献的所有其他人,包括帮助审查 KEPCSI spec PR 的其他人。

对于那些有兴趣参与 CSI 设计和开发或 Kubernetes 存储系统任何部分的人,请加入 Kubernetes 存储特别兴趣小组 (SIG)。我们始终欢迎新的贡献者。

我们还定期举行 数据保护工作组会议。欢迎新的参与者加入我们的讨论。