实战：CSI卷管理-2022.3.2

目录

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点
   k8s version：v1.22.2
   containerd://1.5.5

实验软件

链接：https://pan.baidu.com/s/1WOur–I9x2cfJugqPGzq1g?pwd=4kyi
提取码：4kyi
2022.3.2-48.CSI卷管理-实验代码

1、CSI卷管理

上面我们提到了通过 Longhorn UI 可以对卷进行快照、备份恢复等功能，此外我们还可以通过 Kubernetes 来实现对卷的管理，比如可以在集群上启用 CSI 快照和克隆支持。

#备注
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-system
NAME                                                     READY   STATUS      RESTARTS       AGE
csi-snapshotter-86f65d8bc-6kbmn                          1/1     Running     24 (25h ago)    6d16h
csi-snapshotter-86f65d8bc-9w4xr                          1/1     Running     17 (3d4h ago)   6d16h
csi-snapshotter-86f65d8bc-dqbdz                          1/1     Running     15 (5d1h ago)   6d16h
......

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

➜ kubectl logs -f csi-snapshotter-86f65d8bc-dncwv -n longhorn-system
......
E0223 04:36:33.570567       1 reflector.go:127] github.com/kubernetes-csi/external-snapshotter/client/v3/informers/externalversions/factory.go:117: Failed to watch *v1beta1.VolumeSnapshotClass: failed to list *v1beta1.VolumeSnapshotClass: the server could not find the requested resource (get volumesnapshotclasses.snapshot.storage.k8s.io)
E0223 04:37:03.773447       1 reflector.go:127] github.com/kubernetes-csi/external-snapshotter/client/v3/informers/externalversions/factory.go:117: Failed to watch *v1beta1.VolumeSnapshotContent: failed to list *v1beta1.VolumeSnapshotContent: the server could not find the requested resource (get volumesnapshotcontents.snapshot.storage.k8s.io)

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

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

1、安装CRDs

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

$ git clone https://github.com/kubernetes-csi/external-snapshotter
$ cd external-snapshotter && git checkout v5.0.1
$ kubectl kustomize client/config/crd | kubectl create -f -

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

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

直接部署：

[root@master1 external-snapshotter]#pwd
/root/external-snapshotter
[root@master1 external-snapshotter]#ls
CHANGELOG  cloudbuild.yaml  code-of-conduct.md  deploy    go.mod  LICENSE   OWNERS          pkg        release-tools      vendor
client     cmd              CONTRIBUTING.md     examples  go.sum  Makefile  OWNERS_ALIASES  README.md  SECURITY_CONTACTS
[root@master1 external-snapshotter]#kubectl kustomize client/config/crd | kubectl create -f -

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

[root@master1 external-snapshotter]#kubectl get crd|grep snapshot
volumesnapshotclasses.snapshot.storage.k8s.io    2022-03-02T11:22:12Z
volumesnapshotcontents.snapshot.storage.k8s.io   2022-03-02T11:22:12Z
volumesnapshots.snapshot.storage.k8s.io          2022-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 | kubectl create -f -
serviceaccount/snapshot-controller created
role.rbac.authorization.k8s.io/snapshot-controller-leaderelection created
clusterrole.rbac.authorization.k8s.io/snapshot-controller-runner created
rolebinding.rbac.authorization.k8s.io/snapshot-controller-leaderelection created
clusterrolebinding.rbac.authorization.k8s.io/snapshot-controller-role created
deployment.apps/snapshot-controller created
[root@master1 external-snapshotter]#

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

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

[root@master1 external-snapshotter]#kubectl get pods -n kube-system -l app=snapshot-controller
NAME                                   READY   STATUS    RESTARTS   AGE
snapshot-controller-677b65dc6c-nzp8k   1/1     Running   0          3m25s
snapshot-controller-677b65dc6c-zpxjq   1/1     Running   0          3m25s

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

3、测试

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

[root@master1 ~]#kubectl get pvc mysql-pvc 
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-pvc   Bound    pvc-52031b79-4905-47be-b8fc-09629c25de1f   1Gi        RWO            longhorn       6d11h

1.创建VolumeSnapshot资源清单文件

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

vim 01-snapshot-mysql.yaml

# 01-snapshot-mysql.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mysql-snapshot-demo
spec:
  volumeSnapshotClassName: longhorn
  source:
    persistentVolumeClaimName: mysql-pvc
    # volumeSnapshotContentName: test-content

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

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

2.创建VolumeSnapshotClass资源清单文件

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

vim 02-snapshotclass.yaml

# 02-snapshotclass.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: longhorn
  # annotations:  # 如果要指定成默认的快照类
  #   snapshot.storage.kubernetes.io/is-default-class: "true"
driver: driver.longhorn.io
deletionPolicy: 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/longhorn created
[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl apply -f 01-snapshot-mysql.yaml 
volumesnapshot.snapshot.storage.k8s.io/mysql-snapshot-demo created

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotclass
NAME       DRIVER               DELETIONPOLICY   AGE
longhorn   driver.longhorn.io   Delete           26s
[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshot
NAME                  READYTOUSE   SOURCEPVC   SOURCESNAPSHOTCONTENT   RESTORESIZE   SNAPSHOTCLASS   SNAPSHOTCONTENT                                    CREATIONTIME   AGE
mysql-snapshot-demo   true         mysql-pvc                           1Gi           longhorn        snapcontent-2338699d-d08d-42f8-8173-dfa6cb660522   17s            35s

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

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotcontent
NAME                                               READYTOUSE   RESTORESIZE   DELETIONPOLICY   DRIVER               VOLUMESNAPSHOTCLASS   VOLUMESN
snapcontent-2338699d-d08d-42f8-8173-dfa6cb660522   true         1073741824    Delete           driver.longhorn.io   longhorn              mysql-sn

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

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get volumesnapshotcontent -oyaml
apiVersion: v1
items:
- apiVersion: snapshot.storage.k8s.io/v1
  kind: VolumeSnapshotContent
  metadata:
    creationTimestamp: "2022-03-02T12:02:13Z"
    finalizers:
    - snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection
    generation: 1
    name: snapcontent-2338699d-d08d-42f8-8173-dfa6cb660522
    resourceVersion: "1667159"
    uid: 13307ef0-792f-4079-83ad-d7766949fad3
  spec:
    deletionPolicy: Delete
    driver: driver.longhorn.io
    source:
      volumeHandle: pvc-52031b79-4905-47be-b8fc-09629c25de1f
    volumeSnapshotClassName: longhorn
    volumeSnapshotRef:
      apiVersion: snapshot.storage.k8s.io/v1
      kind: VolumeSnapshot
      name: mysql-snapshot-demo
      namespace: default
      resourceVersion: "1667035"
      uid: 2338699d-d08d-42f8-8173-dfa6cb660522
  status:
    creationTime: 1646222535000000000
    readyToUse: true
    restoreSize: 1073741824
    snapshotHandle: bs://pvc-52031b79-4905-47be-b8fc-09629c25de1f/backup-fce2251f2b234844
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

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

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

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

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

实验结束，完美。

2.基于快照创建新的 PVC（恢复）

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

实战演示：基于快照创建新的 PVC（恢复）(成功测试)

1、基于快照创建新的pvc

比如现在我们来基于上面创建的 mysql-snapshot-demo 这个对象来创建一个新的 PVC：

vim 03-restore-mysql.yaml

# 03-restore-mysql.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-restore-pvc
spec:
  storageClassName: longhorn
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  dataSource:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: 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 pvc
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
html                Bound    pvc-6d15f7e3-8d2f-471d-b1b4-4bc045e84d7f   1Gi        RWX            longhorn       5d8h
mysql-pvc           Bound    pvc-52031b79-4905-47be-b8fc-09629c25de1f   1Gi        RWO            longhorn       6d13h
mysql-restore-pvc   Bound    pvc-1b89ddf4-8647-41d1-b334-ec1c9dac658d   1Gi        RWO            longhorn       20m
nfs-csi-sc-pvc      Bound    pvc-628c2b7d-6c51-4a4c-ac0d-87bea6ef89be   20Gi       RWX            nfs-csi        7d12h

呃呃，我这个等了有一会儿才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.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-clone-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 1Gi  # 必须大于或等于源的值
  dataSource:
    kind: PersistentVolumeClaim
    name: 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-pvc created

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvc mysql-clone-pvc
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-clone-pvc   Bound    pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301   1Gi        RWO            longhorn       36s

在 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 
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-clone-pvc   Bound    pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301   1Gi        RWO            longhorn       14m


[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl patch pvc mysql-clone-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}'
persistentvolumeclaim/mysql-clone-pvc patched

修改后可以查看该 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 的大小验证：

[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pvc mysql-clone-pvc 
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-clone-pvc   Bound    pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301   2Gi        RWO            longhorn       15m
[root@master1 2022.3.2-48.CSI卷管理-实验代码]#kubectl get pv pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                     STORAGECLASS   REASON   AGE
pvc-51e9f6cf-51e2-4ea9-953b-af8ebbb72301   2Gi        RWO            Delete           Bound    default/mysql-clone-pvc   longhorn                15m

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

实验结束。

关于我

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

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

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

   

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

   

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

   

4. 个人csdn

   https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

   

5. 个人已开源干货

   名称	链接
   01 实战：打造一款王者云笔记：typora+坚果云+阿里云oss	https://www.jianguoyun.com/p/DXS6qiIQvPWVCRiS0qoE
   02 实战：定制宇宙中最美的typora主题皮肤	https://www.jianguoyun.com/p/DeUK9u0QvPWVCRib0qoE
   03 玩转vscode	https://www.jianguoyun.com/p/DZe8gmsQvPWVCRid0qoE
   04 陈果的幸福哲学课	https://www.jianguoyun.com/p/Db0kM7gQvPWVCRj2q6YE

最后

​ 好了，关于CSI卷管理实验就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！