通过 Kubernetes CSI 实现 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的“类”概念。

卷快照能力为 Kubernetes 用户提供了一种标准的方式来在指定时间点复制卷的内容，并且不需要创建全新的卷，比如数据库管理员可以在执行编辑或删除之类的修改之前对数据库执行备份。

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

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

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

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

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

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

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

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

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

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

➜kubectlgetpods-nlonghorn-systemNAMEREADYSTATUSRESTARTSAGEcsi-snapshotter-86f65d8bc-9t7dd1/1Running5(126mago)2d17hcsi-snapshotter-86f65d8bc-d6xbj1/1Running5(126mago)2d17hcsi-snapshotter-86f65d8bc-dncwv1/1Running5(126mago)2d17h......

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

➜kubectllogs-fcsi-snapshotter-86f65d8bc-dncwv-nlonghorn-system......E022304:36:33.5705671reflector.go:127]github.com/kubernetes-csi/external-snapshotter/client/v3/informers/externalversions/factory.go:117:Failedtowatch*v1beta1.VolumeSnapshotClass:failedtolist*v1beta1.VolumeSnapshotClass:theservercouldnotfindtherequestedresource(getvolumesnapshotclasses.snapshot.storage.k8s.io)E022304:37:03.7734471reflector.go:127]github.com/kubernetes-csi/external-snapshotter/client/v3/informers/externalversions/factory.go:117:Failedtowatch*v1beta1.VolumeSnapshotContent:failedtolist*v1beta1.VolumeSnapshotContent:theservercouldnotfindtherequestedresource(getvolumesnapshotcontents.snapshot.storage.k8s.io)

可以看到提示没有 VolumeSnapshotClass和 VolumeSnapshotContent资源，这是因为这两个资源都是 CRDs，并不是 Kubernetes 内置的资源对象，而我们在安装 Longhorn 的时候也没有安装这两个 CRDs，所以找不到，要通过 CSI 来实现卷快照功能自然就需要先安装 CRDs，我们可以从 https://github.com/kubernetes-csi/external-snapshotter 项目中来获取：

➜gitclonehttps://github.com/kubernetes-csi/external-snapshotter➜cdexternal-snapshotter&&gitcheckoutv5.0.1➜kubectlkustomizeclient/config/crd|kubectlcreate-f-

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

➜kubectlgetcrd|grepsnapshotvolumesnapshotclasses.snapshot.storage.k8s.io2022-02-23T05:31:34Zvolumesnapshotcontents.snapshot.storage.k8s.io2022-02-23T05:31:34Zvolumesnapshots.snapshot.storage.k8s.io2022-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-nkube-systemkustomizedeploy/kubernetes/snapshot-controller|kubectlcreate-f-

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

➜kubectlgetpods-nkube-system-lapp=snapshot-controllerNAMEREADYSTATUSRESTARTSAGEsnapshot-controller-677b65dc6c-288w91/1Running03m22ssnapshot-controller-677b65dc6c-zgdcm1/1Running039s

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

测试

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

➜kubectlgetpvcmysql-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-pvcBoundpvc-ec17a7e4-7bb4-4456-9380-353db3ed43071GiRWOlonghorn2d18h

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

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

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

volumeSnapshotClassName：指定 VolumeSnapshotClass的名称，这样就可以动态创建一个对应的 VolumeSnapshotContent与之绑定，如果没有指定该参数，则属于静态方式，需要手动创建 VolumeSnapshotContent。persistentVolumeClaimName：指定数据来源的 PVC 名称。volumeSnapshotContentName：如果是申请静态存储快照，则需要通过该参数来指定一个 VolumeSnapshotContent。

上面我们指定了一个存储快照类 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。

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

➜kubectlapply-fsnapshotclass.yamlvolumesnapshotclass.snapshot.storage.k8s.io/longhorncreated➜kubectlapply-fsnapshot-mysql.yamlvolumesnapshot.snapshot.storage.k8s.io/mysql-snapshot-democreated➜kubectlgetvolumesnapshotclassNAMEDRIVERDELETIONPOLICYAGElonghorndriver.longhorn.ioDelete43s➜kubectlgetvolumesnapshotNAMEREADYTOUSESOURCEPVCSOURCESNAPSHOTCONTENTRESTORESIZESNAPSHOTCLASSSNAPSHOTCONTENTCREATIONTIMEAGEmysql-snapshot-demotruemysql-pvc1Gilonghornsnapcontent-1119649a-d4f2-447f-a21a-e527f202e43e43s43s

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

➜kubectlgetvolumesnapshotcontentNAMEREADYTOUSERESTORESIZEDELETIONPOLICYDRIVERVOLUMESNAPSHOTCLASSVOLUMESNAPSHOTVOLUMESNAPSHOTNAMESPACEAGEsnapcontent-1119649a-d4f2-447f-a21a-e527f202e43etrue1073741824Deletedriver.longhorn.iolonghornmysql-snapshot-demodefault97s

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

apiVersion:snapshot.storage.k8s.io/v1kind:VolumeSnapshotContentmetadata:name:snapcontent-1119649a-d4f2-447f-a21a-e527f202e43espec:deletionPolicy:Deletedriver:driver.longhorn.iosource:volumeHandle:pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307volumeSnapshotClassName:longhornvolumeSnapshotRef:apiVersion:snapshot.storage.k8s.io/v1kind:VolumeSnapshotname:mysql-snapshot-demonamespace:defaultresourceVersion:"4967456"uid:1119649a-d4f2-447f-a21a-e527f202e43estatus:creationTime:1645597546000000000readyToUse:truerestoreSize:1073741824snapshotHandle:bs://pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307/backup-f5f28fd624a148ed

其中的 source.volumeHandle字段的值是在后端存储上创建并由 CSI 驱动在创建存储卷期间返回的 Volume 的唯一标识符，在动态供应模式下需要该字段，指定的是快照的来源 Volume 信息，volumeSnapshotRef下面就是和关联的 VolumeSnapshot对象的相关信息。当然这个时候我们在 Longhorn UI 界面上也可以看到上面我们创建的这个快照了，快照名称为 snapshot-1119649a-d4f2-447f-a21a-e527f202e43e，后面的 ID 与上面的 VolumeSnapshotContent名称保持一致：

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

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

CSI 卷恢复

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

#restore-mysql.yamlapiVersion:v1kind:PersistentVolumeClaimmetadata:name:mysql-restore-pvcspec:storageClassName:longhornaccessModes:-ReadWriteOnceresources:requests:storage:1GidataSource:apiGroup:snapshot.storage.k8s.iokind:VolumeSnapshotname:mysql-snapshot-demo

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

➜kubectlgetpvcmysql-restore-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-restore-pvcBoundpvc-e4ddd985-31a8-4570-b393-dcedec3b0d951GiRWOlonghorn17s

在 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 中（可以使用默认的）两个存储卷的存储模式（VolumeMode）要一致

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

apiVersion:v1kind:PersistentVolumeClaimmetadata:name:mysql-clone-pvcspec:accessModes:-ReadWriteOncestorageClassName:longhornresources:requests:storage:1Gi#必须大于或等于源的值dataSource:kind:PersistentVolumeClaimname:mysql-pvc

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

➜kubectlgetpvcmysql-clone-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-58eab5f0-a386-435c-91f4-0c26f79356951GiRWOlonghorn31s

在 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 这个卷（处于 detached状态）使用的 longhorn 这个 StorageClass 中就已经配置了 allowVolumeExpansion: true，然后直接修改 mysql-pvc 这个卷下面的 spec.resources.requests.storage值即可：

➜kubectlgetpvcmysql-clone-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-58eab5f0-a386-435c-91f4-0c26f79356951GiRWOlonghorn40m➜kubectlpatchpvcmysql-clone-pvc-p"{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}"

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

➜kubectldescribepvcmysql-clone-pvc......Events:TypeReasonAgeFromMessage-------------------------......NormalResizing14sexternal-resizerdriver.longhorn.ioExternalresizerisresizingvolumepvc-58eab5f0-a386-435c-91f4-0c26f7935695WarningExternalExpanding14svolume_expandIgnoringthePVC:didn"tfindaplugincapableofexpandingthevolume;waitingforanexternalcontrollertoprocessthisPVC.NormalVolumeResizeSuccessful2sexternal-resizerdriver.longhorn.ioResizevolumesucceeded

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

➜kubectlgetpvcmysql-clone-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-58eab5f0-a386-435c-91f4-0c26f79356952GiRWOlonghorn43m➜kubectlgetpvpvc-58eab5f0-a386-435c-91f4-0c26f7935695NAMECAPACITYACCESSMODESRECLAIMPOLICYSTATUSCLAIMSTORAGECLASSREASONAGEpvc-58eab5f0-a386-435c-91f4-0c26f79356952GiRWODeleteBounddefault/mysql-clone-pvclonghorn43m

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

原文链接：https://kube100.com/d/9

关键词： 提供服务 一个新的