大家好，我是米开朗基杨。
KubeSphere 3.3.0 （不出意外的话~）本周就要 GA 了，作为一名 KubeSphere 脑残粉，我急不可待地先装置 RC 版尝尝鲜，一顿操作猛如虎开启所有组件，装完之后发现有点难堪：我用错了长久化存储。
我的 K8s 集群中有两个存储类（StorageClass），一个是 OpenEBS 提供的本地存储，另一个是 QingCloud CSI 提供的分布式存储，而且默认的 StorageClass 是 OpenEBS 提供的 local-hostpath，所以 KubeSphere 的有状态组件默认便应用本地存储来保留数据。
失误失误，我原本是想用分布式存储作为默认存储的，然而我遗记将 csi-qingcloud 设置为默认的 StorageClass 了，反正不管怎样，就这么稀里糊涂地搞错了。尽管重装能够解决 99% 的问题，但作为一名成熟的 YAML 工程师，重装是不可能的，必须在不重装的状况下解决这个问题，能力体现出我的气质！
事实上不止我一个人遇到过这种状况，很多人都会稀里糊涂地装完一整套产品之后发现 StorageClass 用错了，这时候再想改回去恐怕就没那么容易了。这不巧了么这不是，本文就是来帮忙大家解决这个问题的。
思路
咱们先来思考一下换 StorageClass 须要做哪几件事件。首先须要将利用的正本数缩减为 0，而后创立一个新的 PVC，将旧 PV 的数据复制到新 PV，而后让利用应用新的 PV，并将正本扩大到原来的数量，最初再将旧 PV 删除。在这整个过程中还要避免删除 PVC 时 Kubernetes 将 PV 也删除了。
当然，有些 CSI 驱动或者存储后端可能会有更便当的数据迁徙技巧，然而本文提供的是一种更加通用的计划，不论后端是什么存储都能够。
KubeSphere 3.3.0 开启所有组件之后应用的长久卷申明（PVC）如下：
本文就以 Elasticsearch 为例，演示如何将 Elasticsearch 的存储从本地存储替换为分布式存储。
备份 PVC 和 PV
首先第一步就是备份 PVC 和 PV，万一前面操作失败了，还有反悔的余地。
$ kubectl -n kubesphere-logging-system get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEdata-elasticsearch-logging-data-0 Bound pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO local-hostpath 28hdata-elasticsearch-logging-data-1 Bound pvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO local-hostpath 28hdata-elasticsearch-logging-discovery-0 Bound pvc-8f32fc97-3d6e-471a-8121-655991d945a8 4Gi RWO local-hostpath 28h$ kubectl -n kubesphere-logging-system get pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 -o yaml > pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9.yaml$ kubectl -n kubesphere-logging-system get pv pvc-0851350a-270e-4d4d-af8d-081132c1775b -o yaml > pvc-0851350a-270e-4d4d-af8d-081132c1775b.yaml$ kubectl -n kubesphere-logging-system get pvc data-elasticsearch-logging-data-0 -o yaml > data-elasticsearch-logging-data-0.yaml$ kubectl -n kubesphere-logging-system get pvc data-elasticsearch-logging-data-1 -o yaml > data-elasticsearch-logging-data-1.yaml复制数据
不论 PV 的 accessModes 是 ReadWriteOnce 还是 ReadWriteMany，在复制数据之前都要将利用的正本数量缩减为 0，因为 ReadWriteOne 模式同时只容许挂载一个 Pod，新 Pod 无奈挂载，而 ReadWriteMany 模式如果不将正本数量缩减为 0，在复制数据时可能会有新的数据写入。所以无论如何，都要将正本数量缩为 0 。
$ kubectl -n kubesphere-logging-system get stsNAME READY AGEelasticsearch-logging-data 2/2 28helasticsearch-logging-discovery 1/1 28h$ kubectl -n kubesphere-logging-system scale sts elasticsearch-logging-data --replicas=0$ kubectl -n kubesphere-logging-system get stsNAME READY AGEelasticsearch-logging-data 0/0 28helasticsearch-logging-discovery 1/1 28h创立一个新的 PVC 叫 new-data-elasticsearch-logging-data-0，容量和 data-elasticsearch-logging-data-0 一样，并将 storageClassName 指定为新的 StorageClass。
创立一个 Deployment，将新 PV 和旧 PV 都挂载进去，而后再将旧 PV 的数据拷贝到新 PV。
在『工作负载』界面点击『创立』，将上面的 YAML 粘贴进去即可。
apiVersion: apps/v1kind: Deploymentmetadata: namespace: kubesphere-logging-system labels: app: datacopy name: datacopyspec: replicas: 1 selector: matchLabels: app: datacopy template: metadata: labels: app: datacopy spec: containers: - name: datacopy image: ubuntu command: - 'sleep' args: - infinity volumeMounts: - name: old-pv readOnly: false mountPath: /mnt/old - name: new-pv readOnly: false mountPath: /mnt/new volumes: - name: old-pv persistentVolumeClaim: claimName: data-elasticsearch-logging-data-0 - name: new-pv persistentVolumeClaim: claimName: new-data-elasticsearch-logging-data-0这个 Deployment 将新 PV 和旧 PV 都挂载进去了，稍后咱们会将旧 PV 的数据拷贝到新 PV。
Pod 启动胜利后，点击容器的终端图标进入容器的终端。
在容器中先验证旧 PV 的挂载点是否蕴含利用数据，新 PV 的挂载点是否是空的，之后再执行命令 (cd /mnt/old; tar -cf - .) | (cd /mnt/new; tar -xpf -)，以确保所有数据的所有权和权限被继承。
执行实现后，验证新 PV 的挂载点是否蕴含旧 PV 的数据，以及所有权和权限是否被正确继承。
到这里复制数据的工作就实现了，当初咱们须要将 datacopy 的正本数量缩为 0。
迁徙 PVC
迁徙存储的现实状态是应用旧的 PVC，并将其指向新的 PV，这样工作负载的 YAML 配置清单就不须要做任何扭转。但 PVC 和 PV 之间的绑定关系是不可更改的，要想让它们解绑，必须先删除旧的 PVC，再创立同名的 PVC，并将旧的 PV 与它绑定。
须要留神的是，默认状况下 PV 的回收策略是 Delete，一旦删除 PVC，与之绑定的 PV 和 PV 里的数据都会被删除。这是咱们不心愿看到的，所以咱们须要批改回收策略，以便删除 PVC 时 PV 可能保留下来。
事实上能够通过 StorageClass 来设置全局的回收策略（reclaimPolicy），如果不设置，默认就是 Delete。能够通过命令 kubectl describe pv <pv-name> 来查看 PV 的回收策略（reclaimPolicy）：
$ kubectl describe pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9Name: pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9Labels: openebs.io/cas-type=local-hostpathAnnotations: pv.kubernetes.io/provisioned-by: openebs.io/localFinalizers: [kubernetes.io/pv-protection]StorageClass: local-hostpathStatus: BoundClaim: kubesphere-logging-system/data-elasticsearch-logging-data-0Reclaim Policy: Delete...$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eName: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eLabels: <none>Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.comFinalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]StorageClass: csi-qingcloudStatus: BoundClaim: kubesphere-logging-system/new-data-elasticsearch-logging-data-0Reclaim Policy: Delete...咱们能够通过 patch 命令将新旧 PV 的回收策略设置为 Retain。
$ kubectl patch pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'persistentvolume/pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 patched$ kubectl patch pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'persistentvolume/pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 patched⚠️留神：该命令对 PV 的稳定性和可用性没有任何影响，能够随时执行。
当初能够将新旧 PVC 全副删除，PV 不会受到任何影响。
$ kubectl -n kubesphere-logging-system delete pvc data-elasticsearch-logging-data-0 new-data-elasticsearch-logging-data-0persistentvolumeclaim "data-elasticsearch-logging-data-0" deletedpersistentvolumeclaim "new-data-elasticsearch-logging-data-0" deleted在创立最终的 PVC 之前，咱们必须要确保新创建的 PVC 可能被绑定到新的 PV 上。通过以下命令能够看到新 PV 目前处于开释状态，不能被新 PVC 绑定：
$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eName: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eLabels: <none>Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.comFinalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]StorageClass: csi-qingcloudStatus: ReleasedClaim: kubesphere-logging-system/new-data-elasticsearch-logging-data-0Reclaim Policy: RetainAccess Modes: RWOVolumeMode: FilesystemCapacity: 20Gi...这是因为 PV 在 spec.claimRef 中依然援用了曾经被删除的 PVC：
$ kubectl get pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e -o yamlapiVersion: v1kind: PersistentVolumemetadata: ... name: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e ...spec: accessModes: - ReadWriteOnce capacity: storage: 20Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: new-data-elasticsearch-logging-data-0 namespace: kubesphere-logging-system resourceVersion: "657019" uid: f4e96f69-b3be-4afe-bb52-1e8e728ca55e ... persistentVolumeReclaimPolicy: Retain storageClassName: csi-qingcloud volumeMode: Filesystem为了解决这个问题，能够间接通过命令 kubectl edit pv <pv-name> 编辑 PV，将 claimRef 的内容全副删除。而后再查看 PV 曾经处于可用状态（Available）：
$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eName: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eLabels: <none>Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.comFinalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]StorageClass: csi-qingcloudStatus: AvailableClaim:Reclaim Policy: RetainAccess Modes: RWOVolumeMode: FilesystemCapacity: 20Gi最终咱们须要创立与旧 PVC 同名的新 PVC，而且要尽可能保障与旧 PVC 的参数雷同：
- 新 PVC 的名字和旧 PVC 的名字雷同；
spec.volumeName指向新 PV；- 新 PVC 的
metadata.annotations和metadata.labels和旧 PVC 保留雷同，因为这些值可能会影响到利用部署（比方 Helm chart 等）。
最终 PVC 内容如下：
apiVersion: v1kind: PersistentVolumeClaimmetadata: labels: app: elasticsearch component: data release: elasticsearch-logging role: data name: data-elasticsearch-logging-data-0 namespace: kubesphere-logging-systemspec: storageClassName: csi-qingcloud accessModes: - ReadWriteOnce resources: requests: storage: 20Gi volumeMode: Filesystem volumeName: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e在『存储卷申明』页面点击『创立』：
抉择『编辑 YAML』，将下面的 YAML 内容复制粘贴进去，而后点击『创立』：
最终能够看到新的 PVC 和 PV 全部都是 Bound 状态：
$ kubectl -n kubesphere-logging-system get pvc data-elasticsearch-logging-data-0NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEdata-elasticsearch-logging-data-0 Bound pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO csi-qingcloud 64s$ kubectl get pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55eNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO Retain Bound kubesphere-logging-system/data-elasticsearch-logging-data-0 csi-qingcloud 11h再来一遍
到目前为止，咱们只迁徙了 data-elasticsearch-logging-data-0 的数据，对于 data-elasticsearch-logging-data-1，依照下面的步骤再反复一遍就行了，记得将 datacopy 中的 PVC 改为 data-elasticsearch-logging-data-1 和 new-data-elasticsearch-logging-data-0，其余中央的配置内容也要批改为新的。
复原工作负载
当初所有的存储都迁徙实现，PVC 名称放弃不变，PV 应用的是新的存储。
$ kubectl get pv -A|grep elasticsearch-logging-datapvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-1 local-hostpath 40hpvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-0 local-hostpath 40hpvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO Retain Bound kubesphere-logging-system/data-elasticsearch-logging-data-1 csi-qingcloud 9m53spvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO Retain Bound kubesphere-logging-system/data-elasticsearch-logging-data-0 csi-qingcloud 11h$ kubectl -n kubesphere-logging-system get pvc|grep elasticsearch-logging-datadata-elasticsearch-logging-data-0 Bound pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO csi-qingcloud 27mdata-elasticsearch-logging-data-1 Bound pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO csi-qingcloud 3m49s将工作负载的正本复原到之前的数量：
$ kubectl -n kubesphere-logging-system scale sts elasticsearch-logging-data --replicas=2statefulset.apps/elasticsearch-logging-data scaled$ kubectl -n kubesphere-logging-system get pod -l app=elasticsearch,component=dataNAME READY STATUS RESTARTS AGEelasticsearch-logging-data-0 1/1 Running 0 4m12selasticsearch-logging-data-1 1/1 Running 0 3m42s完满！
最初还有一点收尾工作，咱们须要将所有新 PV 的回收策略从新设置为 Delete：
$ kubectl patch pv pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'persistentvolume/pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 patched$ kubectl patch pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'persistentvolume/pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e patched$ kubectl get pv -A|grep elasticsearch-logging-datapvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-1 local-hostpath 40hpvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-0 local-hostpath 40hpvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO Delete Bound kubesphere-logging-system/data-elasticsearch-logging-data-1 csi-qingcloud 15mpvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO Delete Bound kubesphere-logging-system/data-elasticsearch-logging-data-0 csi-qingcloud 11h最初的最初，就能够将旧 PV 全副删除了：
$ kubectl delete pv pvc-0851350a-270e-4d4d-af8d-081132c1775bpersistentvolume "pvc-0851350a-270e-4d4d-af8d-081132c1775b" deleted$ kubectl delete pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9persistentvolume "pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9" deleted更简略的计划
下面的计划尽管完满解决了问题，但步骤比拟繁琐，有没有更简洁的办法呢？
能够试试青云推出的云原生备份容灾 SaaS 服务，无需部署、保护本地备份基础架构，即可轻松实现多云异构环境下数据的自在迁徙，从而实现多地、按需的数据保护与利用的高可用。而且价格比拟亲民，对白嫖党敌对，提供了 100GB 的收费存储，迁徙几个 PV 齐全够用了。
应用起来非常简单，先注册账户，而后导入 Kubernetes 集群。如果抉择通过代理连贯 Kubernetes 集群，须要执行红色方框内命令在 Kubernetes 集群中装置代理。
而后新建托管仓库。
接下来间接创立备份打算，抉择间接复制。
备份胜利之后，将集群中的 PVC 和 PV 删除，并将工作负载的正本数缩减为 0。最初创立复原打算，留神将源存储类型名称为 local-hostpath 的指标存储类型名称设置为你想迁徙的存储，这样复原后的 PV 应用的就是新的 StorageClass。
完了。
总结
本文介绍了如何将 Kubernetes 集群中现有 PV 的数据迁徙到新的 PV，并创立同名的 PVC 来指向新的 PV，这样就实现了利用的数据迁徙而不须要对利用的配置清单做任何更改。最初还介绍了如何通过云原生备份容灾 SaaS 服务来简化迁徙过程。
本文由博客一文多发平台 OpenWrite 公布！