本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.27:引入卷组快照 API
卷组快照作为 Alpha 功能在 Kubernetes v1.27 中引入。此功能引入了一个 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 kind 被定义为 CustomResourceDefinitions (CRD)。这些 CRD 必须安装在 Kubernetes 集群中,以便 CSI 驱动程序支持卷组快照。
我如何使用 Kubernetes 卷组快照?
卷组快照在 external-snapshotter 仓库中实现。实现卷组快照意味着添加或更改了几个组件
- 为 VolumeGroupSnapshot 和两个支持 API 添加了新的 CustomResourceDefinitions。
- 卷组快照控制器逻辑已添加到通用快照控制器中。
- 卷组快照验证 webhook 逻辑已添加到通用快照验证 webhook 中。
- 添加了将 CSI 调用发送到快照器 sidecar 控制器的逻辑。
卷快照控制器、CRD 和验证 webhook 每个集群部署一次,而 sidecar 则与每个 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:
CreateVolumeGroupSnapshot
、DeleteVolumeGroupSnapshot
和GetVolumeGroupSnapshot
。 - 添加组控制器能力
CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT
。
有关更多详细信息,请参阅 CSI 规范和 Kubernetes-CSI 驱动程序开发者指南。
尽可能使用 CSI 卷驱动程序,它提供了一种建议的机制来部署容器化的 CSI 驱动程序以简化过程。
作为此推荐部署过程的一部分,Kubernetes 团队提供了许多 sidecar(辅助)容器,包括已更新以支持卷组快照的 external-snapshotter sidecar 容器。
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)。我们随时欢迎新的贡献者。
我们还定期举行数据保护工作组会议。欢迎新成员加入我们的讨论。