上面我们指定了一个存储快照类longhorn需要创建这个对象

前文我们介绍了通过 Longhorn UI 可以对卷进行快照，备份恢复等功能，此外我们还可以通过 Kubernetes 来实现对卷的管理，比如可以在集群上通过 CSI 来实现快照，备份恢复，克隆，扩容等功能支持。

CSI 卷快照

Kubernetes 从 1.12 版本开始引入了存储卷快照功能，在 1.17 版本进入 Beta 版本，和 PV，PVC 两个资源对象类似，Kubernetes 提供了 VolumeSnapshotContent，VolumeSnapshot，VolumeSnapshotClass 三个资源对象用于卷快照管理。

概念

VolumeSnapshotContent 是基于某个 PV 创建的快照，类似于 PV 的资源概念，VolumeSnapshot 是用户对卷快照的请求，类似于持久化声明 PVC 的概念，VolumeSnapshotClass 对象可以来设置快照的特性，屏蔽 VolumeSnapshotContent 的细节，为 VolumeSnapshot 绑定提供动态管理，就像 StorageClass 的类概念。

但是在使用该功能时，需要注意以下几点:

VolumeSnapshot，VolumeSnapshotContent 和 VolumeSnapshotClass 资源对象是 CRDs， 不属于核心 APIVolumeSnapshot 支持仅可用于 CSI 驱动作为 VolumeSnapshot 部署过程的一部分，Kubernetes 团队提供了一个部署于控制平面的快照控制器，并且提供了一个叫做 csi—snapshotter 的 Sidecar 容器，和 CSI 驱动程序一起部署，快照控制器会去监听 VolumeSnapshot 和 VolumeSnapshotContent 对象，并且负责创建和删除 VolumeSnapshotContent 对象csi—snapshotter 监听 VolumeSnapshotContent 对象，并且触发针对 CSI 端点的 CreateSnapshot 和 DeleteSnapshot 的操作，完成快照的创建或删除CSI 驱动可能实现，也可能没有实现卷快照功能，CSI 驱动可能会使用 csi—snapshotter 来提供对卷快照的支持，详见 CSI 驱动程序文档

VolumeSnapshotContents 和 VolumeSnapshots 的生命周期包括资源供应，资源绑定，对使用 PVC 的保护机制和资源删除等各个阶段，这两个对象会遵循这些生命周期。

资源供应:与 PV 的资源供应类似，VolumeSnapshotContent 也可以以静态或动态两种方式供应资源。

静态供应:集群管理员会预先创建好一组 VolumeSnapshotContent 资源，类似于手动创建 PV动态供应:基于 VolumeSnapshotClass 资源，当用户创建 VolumeSnapshot 申请时自动创建 VolumeSnapshotContent，类似于 StorageClass 动态创建 PV

资源绑定:快照控制器负责将 VolumeSnapshot 与一个合适的 VolumeSnapshotContent 进行绑定，包括静态和动态供应两种情况，VolumeSnapshot 和 VolumeSnapshotContent 之间也是一对一进行绑定的，不会存在一对多的情况。

对使用中的PVC的保护机制:当存储快照 VolumeSnapshot 正在被创建且还未完成时，相关的 PVC 将会被标记为正被使用中，如果用户对 PVC 进行删除操作，系统不会立即删除 PVC，以避免快照还未做完造成数据丢失，删除操作会延迟到 VolumeSnapshot 创建完成或被终止的情况下完成。

资源删除:对 VolumeSnapshot 发起删除操作时，对与其绑定的后端 VolumeSnapshotContent 的删除操作将基于删除策略 DeletionPolicy 的设置来决定，可以配置的删除策略有:

Delete:自动删除 VolumeSnapshotContent 资源对象和快照的内容Retain:VolumeSnapshotContent 资源对象和快照的内容都将保留，需要手动清理

我们这里的 Longhorn 系统在部署完成后创建了3个 csi—snapshotter 的 Pod:

。 kubectl get pods —n longhorn—systemNAME READY STATUS RESTARTS AGEcsi—snapshotter—86f65d8bc—9t7dd 1/1 Running 5 2d17hcsi—snapshotter—86f65d8bc—d6xbj 1/1 Running 5 2d17hcsi—snapshotter—86f65d8bc—dncwv 1/1 Running 5 2d17h......

这其实是启动的3个副本，同一时间只有一个 Pod 提供服务，通过 leader—election 来实现的选主高可用，比如当前这里提供服务的是 csi—snapshotter—86f65d8bc—dncwv，我们可以查看对应的日志信息:

上面的命令会安装上面提到的3个 Snapshot CRDs:

grep snapshotvolumesnapshotclasses.snapshot.storage.k8s.io 2022—02—23T05:31:34Zvolumesnapshotcontents.snapshot.storage.k8s.io 2022—02—23T05:31:34Zvolumesnapshots.snapshot.storage.k8s.io 2022—02—23T05:31:34Z

安装完成后再去查看上面的 csi—snapshotter 相关的 Pod 日志就正常了。CRDs 安装完成后还不够，我们还需要一个快照控制器来监听 VolumeSnapshot 和 VolumeSnapshotContent 对象，同样 external—snapshotter 项目中也提供了一个 Common Snapshot Controller，执行下面的命令一键安装:

# 修改 deploy/kubernetes/snapshot—controller/setup—snapshot—controller.yaml 镜像地址为 cnych/csi—snapshot—controller:v5.0.0，默认为 gcr 镜像。 kubectl —n kube—system kustomize deploy/kubernetes/snapshot—controller

这里我们将快照控制器安装到了 kube—system 命名空间下，启动两个副本，同样同一时间只有一个 Pod 提供服务:

。 kubectl get pods —n kube—system —l app=snapshot—controllerNAME READY STATUS RESTARTS AGEsnapshot—controller—677b65dc6c—288w9 1/1 Running 0 3m22ssnapshot—controller—677b65dc6c—zgdcm 1/1 Running 0 39s

到这里就将使用 CSI 来配置快照的环境准备好了。

测试

下面我们仍然以前面的 mysql—pvc 这个卷为例来说明下如何使用卷快照功能:

。 kubectl get pvc mysql—pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql—pvc Bound pvc—ec17a7e4—7bb4—4456—9380—353db3ed4307 1Gi RWO longhorn 2d18h

要创建 mysql—pvc 的快照申请，首先需要创建一个 VolumeSnapshot 对象:

# snapshot—mysql.yamlapiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotmetadata: name: mysql—snapshot—demospec: volumeSnapshotClassName: longhorn source: persistentVolumeClaimName: mysql—pvc# volumeSnapshotContentName: test—content

其中就两个主要配置参数:

上面我们指定了一个存储快照类 longhorn，当然需要创建这个对象:

# snapshotclass.yamlapiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotClassmetadata: name: longhorn # annotations: # 如果要指定成默认的快照类 # snapshot.storage.kubernetes.io/is—default—class: "true"driver: driver.longhorn.iodeletionPolicy: Delete

每个 VolumeSnapshotClass 都包含 driver，deletionPolicy 和 parameters 字段，在需要动态配置属于该类的 VolumeSnapshot 时使用。

driver:表示 CSI 存储插件驱动的名称，这里我们使用的是 Longhorn 插件，名为 driver.longhorn.iodeletionPolicy:删除策略，可以设置为 Delete 或 Retain，如果删除策略是 Delete，那么底层的存储快照会和 VolumeSnapshotContent 对象一起删除，如果删除策略是 Retain，那么底层快照和 VolumeSnapshotContent 对象都会被保留parameters:存储插件需要配置的参数，由 CSI 驱动提供具体的配置参数

如果想将当前快照类设置成默认的则需要添加 snapshot.storage.kubernetes.io/is—default—class: "true" 这样的 annotations。

现在我们直接创建上面的两个资源对象:

kubectl apply —f snapshotclass.yamlvolumesnapshotclass.snapshot.storage.k8s.io/longhorn created kubectl apply —f snapshot—mysql.yamlvolumesnapshot.snapshot.storage.k8s.io/mysql—snapshot—demo created kubectl get volumesnapshotclassNAME DRIVER DELETIONPOLICY AGElonghorn driver.longhorn.io Delete 43s

这个时候会动态为我们创建一个 VolumeSnapshotContent 对象:

。 kubectl get volumesnapshotcontentNAME READYTOUSE RESTORESIZE DELETIONPOLICY DRIVER VOLUMESNAPSHOTCLASS VOLUMESNAPSHOT VOLUMESNAPSHOTNAMESPACE AGEsnapcontent—1119649a—d4f2—447f—a21a—e527f202e43e true 1073741824 Delete driver.longhorn.io longhorn mysql—snapshot—demo default 97s

自动创建的 VolumeSnapshotContent 对象内容如下所示:

apiVersion: snapshot.storage.k8s.io/v1kind: VolumeSnapshotContentmetadata: name: snapcontent—1119649a—d4f2—447f—a21a—e527f202e43espec: deletionPolicy: Delete driver: driver.longhorn.io source: volumeHandle: pvc—ec17a7e4—7bb4—4456—9380—353db3ed4307 volumeSnapshotClassName: longhorn volumeSnapshotRef: apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot name: mysql—snapshot—demo namespace: default resourceVersion: "4967456" uid: 1119649a—d4f2—447f—a21a—e527f202e43estatus: creationTime: 1645597546000000000 readyToUse: true restoreSize: 1073741824snapshotHandle: bs://pvc—ec17a7e4—7bb4—4456—9380—353db3ed4307/backup—f5f28fd624a148ed

并且也会进行一次对应的 Backup 操作，备份的信息通过 snapshotHandle 进行指定的，格式为 bs://backup—/backup—:

这样我们就完成了通过 CSI 实现卷的快照管理功能。

CSI 卷恢复

Kubernetes 对基于快照创建存储卷在 1.17 版本更新到了 Beta 版本，要启用该特性，就需要在 kube—apiserver，kube—controller—manager 和 kubelet 的 Feature Gate 中启用 ——feature—gates=...，VolumeSnapshotDataSource，然后就可以基于某个快照创建一个新的 PVC 存储卷了，比如现在我们来基于上面创建的 mysql—snapshot—demo 这个对象来创建一个新的 PVC:

# restore—mysql.yamlapiVersion: v1kind: PersistentVolumeClaimmetadata: name: mysql—restore—pvcspec: storageClassName: longhorn accessModes: — ReadWriteOnce resources: requests: storage: 1Gi dataSource: apiGroup: snapshot.storage.k8s.io kind: VolumeSnapshotname: mysql—snapshot—demo

上面的 PVC 对象和我们平时声明的方式基本一致，唯一不同的是通过一个 dataSource 字段配置了基于名为 mysql—snapshot—demo 的存储快照进行创建，创建上面的资源对象后同样会自动创建一个 PV 与之绑定:

。 kubectl get pvc mysql—restore—pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql—restore—pvc Bound pvc—e4ddd985—31a8—4570—b393—dcedec3b0d95 1Gi RWO longhorn 17s

在 Longhorn UI 中去查看该卷，可以看到该卷的实际大小并不为0，这是因为我们是从快照中创建过来的，相当于从上面的快照中恢复的数据:

卷克隆

除了基于快照创建新的 PVC 对象之外，CSI 类型的存储还支持存储的克隆功能，可以基于已经存在的 PVC 克隆一个新的 PVC，实现方式也是通过在 dataSource 字段中来设置源 PVC 来实现。

克隆一个 PVC 其实就是对已存在的存储卷创建一个副本，唯一的区别是，系统在为克隆 PVC 提供后端存储资源时，不是新建一个空的 PV，而是复制一个与原 PVC 绑定 PV 完全一样的 PV。

从 Kubernetes API 的角度看，克隆的实现只是在创建新的 PVC 时， 增加了指定一个现有 PVC 作为数据源的能力源 PVC 必须是 bound 状态且可用的

用户在使用该功能时，需要注意以下事项:

克隆仅适用于 CSI 驱动克隆仅适用于动态供应克隆功能取决于具体的 CSI 驱动是否实现该功能要求目标 PVC 和源 PVC 必须处于同一个命名空间只支持在相同的 StorageClass 中两个存储卷的存储模式要一致

同样我们来对前面的 mysql—pvc 这个存储卷进行克隆操作，对应的 PVC 声明如下所示:

apiVersion: v1kind: PersistentVolumeClaimmetadata: name: mysql—clone—pvcspec: accessModes: — ReadWriteOnce storageClassName: longhorn resources: requests: storage: 1Gi # 必须大于或等于源的值 dataSource: kind: PersistentVolumeClaimname: mysql—pvc

该 PVC 和源 PVC 声明一样的配置，唯一不同的是通过 dataSource 指定了源 PVC 的名称，直接创建这个资源对象，结果是 mysql—clone—pvc 这个新的 PVC 与源 mysql—pvc 拥有相同的数据。

。如果在备份过程中创建或编辑了Kubernetes对象，它们可能不会包含在备份中，这种情况可能会发生。。 kubectl get pvc mysql—clone—pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql—clone—pvc Bound pvc—58eab5f0—a386—435c—91f4—0c26f7935695 1Gi RWO longhorn 31s

在 Longhorn UI 页面中也可以看到对应的卷:

一旦新的 PVC 可用，被克隆的 PVC 就可以像其他 PVC 一样被使用了，也可以对其进行克隆，快照，删除等操作。

卷动态扩容

我们知道对于存储来说扩容是一个非常重要的需求，对于 Kubernetes 中的卷动态扩容同样也是需要的基本功能，PV 要做扩容操作是需要底层存储支持该操作才能实现，Longhorn 底层是支持卷扩容操作的，但是要求扩展的卷必须处于 detached 状态才能操作，有两种方法可以扩容 Longhorn 卷:修改 PVC 和使用 Longhorn UI。需要注意的是，集群备份不是严格的原子备份。

通过 Longhorn UI 操作比较简单，直接在页面中选择要扩容的卷，在操作中选择 Expand Volume 进行操作即可:

要通过 PVC 来进行扩容首先需要 PVC 由 Longhorn StorageClass 进行动态供应，并且在 StorageClass 中 allowVolumeExpansion 属性设置为 true，建议使用这种方法，因为 PVC 和 PV 会自动更新，并且在扩容后都会保持一致。比如上面使用的 mysql—clone—pvc 这个卷使用的 longhorn 这个 StorageClass 中就已经配置了 allowVolumeExpansion: true，然后直接修改 mysql—pvc 这个卷下面的 spec.resources.requests.storage 值即可:

kubectl get pvc mysql—clone—pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql—clone—pvc Bound pvc—58eab5f0—a386—435c—91f4—0c26f7935695 1Gi RWO longhorn 40m

修改后可以查看该 PVC 的 events 信息:

。 kubectl describe pvc mysql—clone—pvc......Events: Type Reason Age From Message — — — — ...... Normal Resizing 14s external—resizer driver.longhorn.io External resizer is resizing volume pvc—58eab5f0—a386—435c—91f4—0c26f7935695 Warning ExternalExpanding 14s volume_expand Ignoring the PVC: didn't find a plugin capable of expanding the volume， waiting for an external controller to process this PVC.Normal VolumeResizeSuccessful 2s external—resizer driver.longhorn.io Resize volume succeeded

可以看到通过 external—resizer 组件实现了 Resize 操作，查看 PVC 和 PV 的大小验证:

kubectl get pvc mysql—clone—pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmysql—clone—pvc Bound pvc—58eab5f0—a386—435c—91f4—0c26f7935695 2Gi RWO longhorn 43m

可以看到 PVC 和 PV 中的容量都变成了 2Gi，证明扩容成功了，通过 Longhorn UI 也可以查看到卷扩容成功了:

。