CSI卷管理

CSI卷管理

目录

[TOC]

实验环境

实验环境：1、win10,vmwrokstation虚机；2、k8s集群：3台centos7.61810虚机，1个master节点,2个node节点k8sversion：v1.22.2containerd:csi-attacher-5f46994f7-4q44p:把卷附加到pod上csi-provisioner-6ccbfbf86f-9vg87：提供卷的csi-resizer-6dd8bd4c97-k59rx：卷扩容csi-snapshotter-86f65d8bc-6kbmn：做卷快照

1.CSI 卷快照

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

(1)概念

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 驱动程序文档。

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

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

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

2、资源绑定：快照控制器负责将 VolumeSnapshot与一个合适的 VolumeSnapshotContent进行绑定，包括静态和动态供应两种情况，VolumeSnapshot和 VolumeSnapshotContent之间也是一对一进行绑定的，不会存在一对多的情况。 对使用中的PVC的保护机制：当存储快照 VolumeSnapshot正在被创建且还未完成时，相关的 PVC 将会被标记为正被使用中，如果用户对 PVC 进行删除操作，系统不会立即删除 PVC，以避免快照还未做完造成数据丢失，删除操作会延迟到 VolumeSnapshot创建完成（readyToUse状态）或被终止（aborted状态）的情况下完成。

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

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

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

$kubectl get pods -n longhorn-systemNAMEREADYSTATUSRESTARTSAGEcsi-snapshotter-86f65d8bc-6kbmn1/1Running24(25h ago) 6d16hcsi-snapshotter-86f65d8bc-9w4xr1/1Running17(3d4h ago) 6d16hcsi-snapshotter-86f65d8bc-dqbdz1/1Running15(5d1h ago) 6d16h......

这其实是启动的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(get volumesnapshotclasses.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(get volumesnapshotcontents.snapshot.storage.k8s.io)

可以看到提示没有 VolumeSnapshotClass和 VolumeSnapshotContent资源，这是因为这两个资源都是 CRDs，并不是 Kubernetes 内置的资源对象，而我们在安装 Longhorn 的时候也没有安装这两个 CRDs，所以找不到。

(2)💘 实战演示：csi卷快照实验(测试成功)

1、安装CRDs

🍀 要通过 CSI 来实现卷快照功能自然就需要先安装 CRDs，我们可以从 external-snapshotter项目中来获取：

$gitclonehttps:$cdexternal-snapshotter&&gitcheckoutv5.0.1$kubectlkustomizeclient/config/crd|kubectlcreate-f-

现在有个问题：老师当时最新版本是v5.0.1，而现在是v4.0.1

那这里就不直接切换了，直接进行安装，应该可以把。。。

直接部署：

[root@master1 external-snapshotter]#pwd/root/external-snapshotter[root@master1 external-snapshotter]#lsCHANGELOGcloudbuild.yamlcode-of-conduct.mddeploygo.modLICENSEOWNERSpkgrelease-toolsvendorclientcmdCONTRIBUTING.mdexamplesgo.sumMakefileOWNERS_ALIASESREADME.mdSECURITY_CONTACTS[root@master1 external-snapshotter]#kubectl kustomize client/config/crd |kubectlcreate-f-

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

[root@master1 external-snapshotter]#kubectl get crd|grepsnapshotvolumesnapshotclasses.snapshot.storage.k8s.io2022-03-02T11:22:12Zvolumesnapshotcontents.snapshot.storage.k8s.io2022-03-02T11:22:12Zvolumesnapshots.snapshot.storage.k8s.io2022-03-02T11:22:12Z

安装完成后再去查看上面的 csi-snapshotter相关的 Pod 日志就正常了。

2、安装快照控制器

🍀 CRDs 安装完成后还不够，我们还需要一个快照控制器来监听 VolumeSnapshot和 VolumeSnapshotContent对象，同样 external-snapshotter项目中也提供了一个 Common Snapshot Controller，执行下面的命令一键安装：

#需要做如下修改[root@master1 external-snapshotter]#vim deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml# 修改 deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml 镜像地址为 cnych/csi-snapshot-controller:v5.0.0，默认为 gcr 镜像[root@master1 external-snapshotter]#kubectl -n kube-system kustomize deploy/kubernetes/snapshot-controller |kubectlcreate-f-serviceaccount/snapshot-controllercreatedrole.rbac.authorization.k8s.io/snapshot-controller-leaderelectioncreatedclusterrole.rbac.authorization.k8s.io/snapshot-controller-runnercreatedrolebinding.rbac.authorization.k8s.io/snapshot-controller-leaderelectioncreatedclusterrolebinding.rbac.authorization.k8s.io/snapshot-controller-rolecreateddeployment.apps/snapshot-controllercreated[root@master1 external-snapshotter]#

也可以看到这个2个pod也是leader-election的：

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

[root@master1 external-snapshotter]#kubectl get pods -n kube-system -l app=snapshot-controllerNAMEREADYSTATUSRESTARTSAGEsnapshot-controller-677b65dc6c-nzp8k1/1Running03m25ssnapshot-controller-677b65dc6c-zpxjq1/1Running03m25s

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

3、测试

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

[root@master1 ~]#kubectl get pvc mysql-pvc NAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-pvcBoundpvc-52031b79-4905-47be-b8fc-09629c25de1f1GiRWOlonghorn6d11h

1.创建VolumeSnapshot资源清单文件

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

vim 01-snapshot-mysql.yaml

# 01-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。

2.创建VolumeSnapshotClass资源清单文件

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

vim 02-snapshotclass.yaml

# 02-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.io

• deletionPolicy：删除策略，可以设置为 Delete 或 Retain，如果删除策略是 Delete，那么底层的存储快照会和 VolumeSnapshotContent对象一起删除，如果删除策略是 Retain，那么底层快照和 VolumeSnapshotContent对象都会被保留。

• parameters：存储插件需要配置的参数，有 CSI 驱动提供具体的配置参数。

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

3.部署并查看

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

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl apply -f 02-snapshotclass.yaml volumesnapshotclass.snapshot.storage.k8s.io/longhorncreated[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl apply -f 01-snapshot-mysql.yaml volumesnapshot.snapshot.storage.k8s.io/mysql-snapshot-democreated[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotclassNAMEDRIVERDELETIONPOLICYAGElonghorndriver.longhorn.ioDelete26s[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotNAMEREADYTOUSESOURCEPVCSOURCESNAPSHOTCONTENTRESTORESIZESNAPSHOTCLASSSNAPSHOTCONTENTCREATIONTIMEAGEmysql-snapshot-demotruemysql-pvc1Gilonghornsnapcontent-2338699d-d08d-42f8-8173-dfa6cb66052217s35s

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

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotcontentNAMEREADYTOUSERESTORESIZEDELETIONPOLICYDRIVERVOLUMESNAPSHOTCLASSVOLUMESNsnapcontent-2338699d-d08d-42f8-8173-dfa6cb660522true1073741824Deletedriver.longhorn.iolonghornmysql-sn

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

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotcontent -oyamlapiVersion:v1items:- apiVersion:snapshot.storage.k8s.io/v1kind:VolumeSnapshotContentmetadata:creationTimestamp:"2022-03-02T12:02:13Z"finalizers:- snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protectiongeneration:1name:snapcontent-2338699d-d08d-42f8-8173-dfa6cb660522resourceVersion:"1667159"uid:13307ef0-792f-4079-83ad-d7766949fad3spec:deletionPolicy:Deletedriver:driver.longhorn.iosource:volumeHandle:pvc-52031b79-4905-47be-b8fc-09629c25de1fvolumeSnapshotClassName:longhornvolumeSnapshotRef:apiVersion:snapshot.storage.k8s.io/v1kind:VolumeSnapshotname:mysql-snapshot-demonamespace:defaultresourceVersion:"1667035"uid:2338699d-d08d-42f8-8173-dfa6cb660522status:creationTime:1646222535000000000readyToUse:truerestoreSize:1073741824snapshotHandle:bs:kind:Listmetadata:resourceVersion:""selfLink:""

其中的 source.volumeHandle字段的值是在后端存储上创建并由 CSI 驱动在创建存储卷期间返回的 Volume 的唯一标识符，在动态供应模式下需要该字段，指定的是快照的来源 Volume 信息，volumeSnapshotRef下面就是和关联的 VolumeSnapshot对象的相关信息。

🍀 当然这个时候我们在 Longhorn UI 界面上也可以看到上面我们创建的这个快照了，快照名称为 snapcontent-2338699d-d08d-42f8-8173-dfa6cb660522，后面的 ID 与上面的 VolumeSnapshotContent名称保持一致：

并且也会进行一次对应的 Backup 操作，备份的信息通过 snapshotHandle进行指定的，格式为 bs:apiVersion: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的存储快照进行创建。

2、部署并测试

🍀 创建上面的资源对象后同样会自动创建一个 PV 与之绑定：

$kubectl apply -f 03-restore-mysql.yaml[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEhtmlBoundpvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f1GiRWXlonghorn5d8hmysql-pvcBoundpvc-52031b79-4905-47be-b8fc-09629c25de1f1GiRWOlonghorn6d13hmysql-restore-pvcBoundpvc-1b89ddf4-8647-41d1-b334-ec1c9dac658d1GiRWOlonghorn20mnfs-csi-sc-pvcBoundpvc-628c2b7d-6c51-4a4c-ac0d-87bea6ef89be20GiRWXnfs-csi7d12h

呃呃，我这个等了有一会儿才bound成功。。。

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

实验结束。😘

3.卷克隆

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

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

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

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

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

💘 实战演示：卷克隆(测试成功)

1、创建pvc.yaml

创建作进行克隆操作，对应的 PVC 声明如下所示：

vim 04-clone.yaml

#04-clone.yamlapiVersion: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拥有相同的数据。

2、部署并测试

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl apply -f 04-clone.yaml persistentvolumeclaim/mysql-clone-pvccreated[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvc mysql-clone-pvcNAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-51e9f6cf-51e2-4ea9-953b-af8ebbb723011GiRWOlonghorn36s

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

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

实验结束。😘

4.卷动态扩容

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

💘 实战演示：卷动态扩容(测试成功)

1、使用 Longhorn UI

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

2、修改 PVC

要通过 PVC 来进行扩容首先需要 PVC 由 Longhorn StorageClass 进行动态供应，并且在 StorageClass 中 allowVolumeExpansion属性设置为 true。

建议使用这种方法，因为 PVC 和 PV 会自动更新，并且在扩容后都会保持一致。

比如上面使用的 mysql-clone-pvc 这个卷（处于 detached状态）使用的 longhorn 这个 StorageClass 中就已经配置了 allowVolumeExpansion:true，然后直接修改 mysql-pvc 这个卷下面的 spec.resources.requests.storage值即可：

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvc mysql-clone-pvc NAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-51e9f6cf-51e2-4ea9-953b-af8ebbb723011GiRWOlonghorn14m[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl patch pvc mysql-clone-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}'persistentvolumeclaim/mysql-clone-pvcpatched

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

➜kubectldescribepvcmysql-clone-pvc......Events:TypeReasonAgeFromMessage-------------------------......NormalResizing14sexternal-resizerdriver.longhorn.ioExternalresizerisresizingvolumepvc-58eab5f0-a386-435c-91f4-0c26f7935695WarningExternalExpanding14svolume_expandIgnoringthePVC: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 的大小验证：

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvc mysql-clone-pvc NAMESTATUSVOLUMECAPACITYACCESSMODESSTORAGECLASSAGEmysql-clone-pvcBoundpvc-51e9f6cf-51e2-4ea9-953b-af8ebbb723012GiRWOlonghorn15m[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pv pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301NAMECAPACITYACCESSMODESRECLAIMPOLICYSTATUSCLAIMSTORAGECLASSREASONAGEpvc-51e9f6cf-51e2-4ea9-953b-af8ebbb723012GiRWODeleteBounddefault/mysql-clone-pvclonghorn15m

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

实验结束。😘

关于我

我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！

各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：

1. 个人微信二维码：x2675263825 （舍得）， qq：2675263825。

2. 个人博客地址：www.onlyonexl.cn

3. 个人微信公众号：云原生架构师实战

4. 个人csdn

https:

1