本文发布已超过一年。旧文章可能包含过时内容。请确认页面中的信息自发布以来没有变得不准确。
Kubernetes 1.27:引入卷组快照 API
卷组快照作为 Alpha 功能引入 Kubernetes v1.27 版本。此功能引入了一个 Kubernetes API,允许用户对多个卷同时进行崩溃一致性快照。它使用标签选择器来对多个 PersistentVolumeClaim
进行分组以进行快照。此新功能仅支持 CSI 卷驱动程序。
卷组快照概述
某些存储系统提供创建多个卷崩溃一致性快照的能力。卷组快照代表了在同一时间点对多个卷进行的“复制”。卷组快照既可以用于重新生成新卷(预先填充快照数据),也可以用于将现有卷恢复到以前的状态(由快照表示)。
为什么要在 Kubernetes 中添加卷组快照?
Kubernetes 卷插件系统已经提供了一个强大的抽象,可以自动化块存储和文件存储的供应、挂载、附加、调整大小和快照。
所有这些功能的支撑是 Kubernetes 的工作负载可移植性目标:Kubernetes 旨在创建分布式应用与底层集群之间的抽象层,使应用无需感知其运行的集群细节,且应用部署不需要集群特定知识。
已有一个 VolumeSnapshot API 提供了对持久卷进行快照的能力,以防止数据丢失或损坏。然而,VolumeSnapshot API 未涵盖其他快照功能。
某些存储系统支持一致性卷组快照,允许在同一时间点对多个卷进行快照,以实现写入顺序一致性。这对于包含多个卷的应用非常有用。例如,一个应用可能将数据存储在一个卷中,日志存储在另一个卷中。如果在不同时间对数据卷和日志卷进行快照,那么当发生灾难时,如果从这些快照进行恢复,应用将无法保持一致性,也无法正常运行。
的确,您可以先暂停应用,然后逐个对应用所属的每个卷进行单个快照,并在完成所有单个快照后恢复应用。通过这种方式,您可以获得应用一致性快照。
然而,有时可能无法暂停应用,或者暂停应用的成本太高,因此您希望减少暂停应用的频率。相比于拍摄一致性卷组快照,逐个拍摄单个快照可能需要更长的时间。出于这些原因,一些用户可能不希望频繁地暂停应用。例如,用户可能希望每周进行一次暂停应用的应用一致性备份,而每晚进行不暂停应用但支持一致性卷组的崩溃一致性备份。
Kubernetes 卷组快照 API
Kubernetes 卷组快照引入了 三个新的 API 对象 用于管理快照:
VolumeGroupSnapshot
- 由 Kubernetes 用户(或您自己的自动化工具)创建,用于请求为多个持久卷声明创建卷组快照。它包含有关卷组快照操作的信息,例如拍摄卷组快照的时间戳以及是否可用。创建和删除此对象表示创建或删除集群资源(即卷组快照)的意愿。
VolumeGroupSnapshotContent
- 由快照控制器为动态创建的 VolumeGroupSnapshot 创建。它包含有关卷组快照的信息,包括卷组快照 ID。此对象代表集群上的已供应资源(即卷组快照)。VolumeGroupSnapshotContent 对象与其创建的 VolumeGroupSnapshot 对象一一对应。
VolumeGroupSnapshotClass
- 由集群管理员创建,用于描述如何创建卷组快照,包括驱动程序信息、删除策略等。
这三种 API 类型被定义为 CustomResourceDefinitions (CRDs)。CSI 驱动程序需要在 Kubernetes 集群中安装这些 CRD 才能支持卷组快照。
如何使用 Kubernetes 卷组快照
卷组快照在 external-snapshotter 仓库中实现。实现卷组快照需要添加或修改几个组件:
- 添加了用于 VolumeGroupSnapshot 和两个支持 API 的新的 CustomResourceDefinitions。
- 卷组快照控制器逻辑被添加到通用快照控制器中。
- 卷组快照验证 Webhook 逻辑被添加到通用快照验证 Webhook 中。
- 添加逻辑以向 snapshotter 边车控制器发出 CSI 调用。
卷快照控制器、CRD 和验证 Webhook 每个集群部署一次,而边车容器则与每个 CSI 驱动程序捆绑在一起。
因此,将卷快照控制器、CRD 和验证 Webhook 作为集群插件部署是合理的。我强烈建议 Kubernetes 发行商将其卷快照控制器、CRD 和验证 Webhook 打包并部署为 Kubernetes 集群管理过程的一部分(独立于任何 CSI 驱动程序)。
使用 Kubernetes 创建新的卷组快照
定义好 VolumeGroupSnapshotClass 对象并拥有需要一起进行快照的卷后,您可以通过创建 VolumeGroupSnapshot 对象来请求新的卷组快照。
卷组快照的源指定是应该动态创建底层卷组快照,还是使用预先存在的 VolumeGroupSnapshotContent。
预先存在的 VolumeGroupSnapshotContent 由集群管理员创建。它包含存储系统上真实卷组快照的详细信息,可供集群用户使用。
卷组快照源中的以下成员之一必须设置:
selector
- 对将要分组进行快照的 PersistentVolumeClaim 进行标签查询。此 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
对于动态供应,必须设置一个 selector,以便快照控制器可以找到具有匹配标签的 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 spec 中,用户可以指定 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:
CreateVolumeGroupSnapshot
、DeleteVolumeGroupSnapshot
和GetVolumeGroupSnapshot
。 - 添加卷组控制器能力
CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT
。
更多详情请参阅 CSI 规范和 Kubernetes-CSI 驱动程序开发者指南。
使 CSI 卷驱动程序尽可能简单,它提供了一种建议机制来部署容器化的 CSI 驱动程序以简化过程。
作为推荐部署过程的一部分,Kubernetes 团队提供了许多边车(helper)容器,包括已更新以支持卷组快照的 external-snapshotter 边车容器。
external-snapshotter 监视 Kubernetes API 服务器上的 VolumeGroupSnapshotContent
对象,并针对 CSI 端点触发 CreateVolumeGroupSnapshot
和 DeleteVolumeGroupSnapshot
操作。
有哪些限制?
Kubernetes 卷组快照的 Alpha 实现具有以下限制:
- 不支持将现有 PVC 恢复到快照表示的早期状态(仅支持从快照供应新卷)。
- 除了存储系统提供的任何保证(例如崩溃一致性)之外,不提供应用一致性保证。有关应用一致性的更多讨论,请参阅此文档。
下一步是什么?
根据反馈和采用情况,Kubernetes 团队计划在 1.28 或 1.29 版本中将 CSI 卷组快照实现推向 Beta 版。我们感兴趣支持的一些功能包括卷复制、复制组、卷放置、应用暂停、更改块跟踪等。
我如何了解更多信息?
如何参与?
与所有 Kubernetes 项目一样,这个项目也是由来自不同背景的众多贡献者共同努力的成果。我谨代表 SIG Storage 向最近几个季度挺身而出帮助项目达到 Alpha 阶段的贡献者表示衷心感谢:
- Alex Meade (ameade)
- Ben Swartzlander (bswartz)
- Humble Devassy Chirammal (humblec)
- James Defelice (jdef)
- Jan Šafránek (jsafrane)
- Jing Xu (jingxu97)
- Michelle Au (msau42)
- Niels de Vos (nixpanic)
- Rakshith R (Rakshith-R)
- Raunak Shah (RaunakShah)
- Saad Ali (saad-ali)
- Thomas Watson (rbo54)
- Xing Yang (xing-yang)
- Yati Padia (yati1998)
我们还要感谢所有为该项目做出贡献的人,包括帮助评审 KEP 和 CSI 规范 PR 的其他人。
对于有兴趣参与 CSI 或 Kubernetes 存储系统任何部分的设计和开发的开发者,欢迎加入 Kubernetes 存储特别兴趣小组 (SIG)。我们随时欢迎新的贡献者。
我们还定期举行数据保护工作组会议。欢迎新成员加入我们的讨论。