Kubernetes 中跨 StorageClass 遷移存儲完全指南
大家好，我是米開朗基楊。
KubeSphere 3.3.0 （不出意外的話~）下周就要 GA 了，作為一名 KubeSphere 腦殘粉，我迫不及待地先安裝 RC 版[1]嘗嘗鮮，一頓操作猛如虎開啟所有組件，裝完之后發(fā)現(xiàn)有點尷尬：我用錯了持久化存儲。
我的 K8s 集群中有兩個存儲類（StorageClass），一個是 OpenEBS 提供的本地存儲，另一個是 QingCloud CSI[2] 提供的分布式存儲，而且默認(rèn)的 StorageClass 是 OpenEBS 提供的 local-hostpath，所以 KubeSphere 的有狀態(tài)組件默認(rèn)便使用本地存儲來保存數(shù)據(jù)。
失誤失誤，我本來是想用分布式存儲作為默認(rèn)存儲的，但是我忘記將 csi-qingcloud 設(shè)置為默認(rèn)的 StorageClass 了，反正不管怎樣，就這么稀里糊涂地搞錯了。雖然重裝可以解決 99% 的問題，但作為一名成熟的 YAML 工程師，重裝是不可能的，必須在不重裝的情況下解決這個問題，才能體現(xiàn)出我的氣質(zhì)！
事實上不止我一個人遇到過這種情況，很多人都會稀里糊涂地裝完一整套產(chǎn)品之后發(fā)現(xiàn) StorageClass 用錯了，這時候再想改回去恐怕就沒那么容易了。這不巧了么這不是，本文就是來幫助大家解決這個問題的。
思路
我們先來思考一下?lián)Q StorageClass 需要做哪幾件事情。首先需要將應(yīng)用的副本數(shù)縮減為 0，然后創(chuàng)建一個新的 PVC，將舊 PV 的數(shù)據(jù)復(fù)制到新 PV，然后讓應(yīng)用使用新的 PV，并將副本擴展到原來的數(shù)量，最后再將舊 PV 刪除。在這整個過程中還要防止刪除 PVC 時 Kubernetes 將 PV 也刪除了。
當(dāng)然，有些 CSI 驅(qū)動或者存儲后端可能會有更便利的數(shù)據(jù)遷移技巧，但是本文提供的是一種更加通用的方案，不管后端是什么存儲都可以。
KubeSphere 3.3.0 開啟所有組件之后使用的持久卷聲明（PVC）如下：
本文就以 Elasticsearch 為例，演示如何將 Elasticsearch 的存儲從本地存儲替換為分布式存儲。
備份 PVC 和 PV
首先第一步就是備份 PVC 和 PV，萬一后面操作失敗了，還有反悔的余地。
$ kubectl -n kubesphere-logging-system get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-elasticsearch-logging-data-0 Bound pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO local-hostpath 28h
data-elasticsearch-logging-data-1 Bound pvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO local-hostpath 28h
data-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
復(fù)制數(shù)據(jù)
不管 PV 的 accessModes 是 ReadWriteOnce[3] 還是 ReadWriteMany[4]，在復(fù)制數(shù)據(jù)之前都要將應(yīng)用的副本數(shù)量縮減為 0，因為 ReadWriteOne 模式同時只允許掛載一個 Pod，新 Pod 無法掛載，而 ReadWriteMany 模式如果不將副本數(shù)量縮減為 0，在復(fù)制數(shù)據(jù)時可能會有新的數(shù)據(jù)寫入。所以無論如何，都要將副本數(shù)量縮為 0 。
$ kubectl -n kubesphere-logging-system get sts
NAME READY AGE
elasticsearch-logging-data 2/2 28h
elasticsearch-logging-discovery 1/1 28h
$ kubectl -n kubesphere-logging-system scale sts elasticsearch-logging-data --replicas=0
$ kubectl -n kubesphere-logging-system get sts
NAME READY AGE
elasticsearch-logging-data 0/0 28h
elasticsearch-logging-discovery 1/1 28h
創(chuàng)建一個新的 PVC 叫 new-data-elasticsearch-logging-data-0，容量和 data-elasticsearch-logging-data-0 一樣，并將 storageClassName 指定為新的 StorageClass。
創(chuàng)建一個 Deployment，將新 PV 和舊 PV 都掛載進(jìn)去，然后再將舊 PV 的數(shù)據(jù)拷貝到新 PV。
在『工作負(fù)載』界面點擊『創(chuàng)建』，將下面的 YAML 粘貼進(jìn)去即可。
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: kubesphere-logging-system
labels:
app: datacopy
name: datacopy
spec:
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 都掛載進(jìn)去了，稍后我們會將舊 PV 的數(shù)據(jù)拷貝到新 PV。
Pod 啟動成功后，點擊容器的終端圖標(biāo)進(jìn)入容器的終端。
在容器中先驗證舊 PV 的掛載點是否包含應(yīng)用數(shù)據(jù)，新 PV 的掛載點是否是空的，之后再執(zhí)行命令 (cd /mnt/old; tar -cf - .) | (cd /mnt/new; tar -xpf -)，以確保所有數(shù)據(jù)的所有權(quán)和權(quán)限被繼承。
執(zhí)行完成后，驗證新 PV 的掛載點是否包含舊 PV 的數(shù)據(jù)，以及所有權(quán)和權(quán)限是否被正確繼承。
到這里復(fù)制數(shù)據(jù)的任務(wù)就完成了，現(xiàn)在我們需要將 datacopy 的副本數(shù)量縮為 0。
遷移 PVC
遷移存儲的理想狀態(tài)是使用舊的 PVC，并將其指向新的 PV，這樣工作負(fù)載的 YAML 配置清單就不需要做任何改變。但 PVC 和 PV 之間的綁定關(guān)系是不可更改的，要想讓它們解綁，必須先刪除舊的 PVC，再創(chuàng)建同名的 PVC，并將舊的 PV 與它綁定。
需要注意的是，默認(rèn)情況下 PV 的回收策略是 Delete，一旦刪除 PVC，與之綁定的 PV 和 PV 里的數(shù)據(jù)都會被刪除。這是我們不希望看到的，所以我們需要修改回收策略，以便刪除 PVC 時 PV 能夠保留下來。
事實上可以通過 StorageClass 來設(shè)置全局的回收策略（reclaimPolicy）[5]，如果不設(shè)置，默認(rèn)就是 Delete?？梢酝ㄟ^命令 kubectl describe pv <pv-name> 來查看 PV 的回收策略（reclaimPolicy）：
$ kubectl describe pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9
Name: pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9
Labels: openebs.io/cas-type=local-hostpath
Annotations: pv.kubernetes.io/provisioned-by: openebs.io/local
Finalizers: [kubernetes.io/pv-protection]
StorageClass: local-hostpath
Status: Bound
Claim: kubesphere-logging-system/data-elasticsearch-logging-data-0
Reclaim Policy: Delete
...
$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Name: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Labels: <none>
Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.com
Finalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]
StorageClass: csi-qingcloud
Status: Bound
Claim: kubesphere-logging-system/new-data-elasticsearch-logging-data-0
Reclaim Policy: Delete
...
我們可以通過 patch 命令將新舊 PV 的回收策略設(shè)置為 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 的穩(wěn)定性和可用性沒有任何影響，可以隨時執(zhí)行。
現(xiàn)在可以將新舊 PVC 全部刪除，PV 不會受到任何影響。
$ kubectl -n kubesphere-logging-system delete pvc data-elasticsearch-logging-data-0 new-data-elasticsearch-logging-data-0
persistentvolumeclaim "data-elasticsearch-logging-data-0" deleted
persistentvolumeclaim "new-data-elasticsearch-logging-data-0" deleted
在創(chuàng)建最終的 PVC 之前，我們必須要確保新創(chuàng)建的 PVC 能夠被綁定到新的 PV 上。通過以下命令可以看到新 PV 目前處于釋放狀態(tài)，不能被新 PVC 綁定：
$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Name: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Labels: <none>
Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.com
Finalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]
StorageClass: csi-qingcloud
Status: Released
Claim: kubesphere-logging-system/new-data-elasticsearch-logging-data-0
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 20Gi
...
這是因為 PV 在 spec.claimRef 中仍然引用了已經(jīng)被刪除的 PVC：
$ kubectl get pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
...
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 的內(nèi)容全部刪除。然后再查看 PV 已經(jīng)處于可用狀態(tài)（Available）：
$ kubectl describe pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Name: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
Labels: <none>
Annotations: pv.kubernetes.io/provisioned-by: disk.csi.qingcloud.com
Finalizers: [kubernetes.io/pv-protection external-attacher/disk-csi-qingcloud-com]
StorageClass: csi-qingcloud
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 20Gi
最終我們需要創(chuàng)建與舊 PVC 同名的新 PVC，而且要盡可能保證與舊 PVC 的參數(shù)相同：
新 PVC 的名字和舊 PVC 的名字相同； spec.volumeName指向新 PV；新 PVC 的 metadata.annotations和metadata.labels和舊 PVC 保存相同，因為這些值可能會影響到應(yīng)用部署（比如 Helm chart 等）。
最終 PVC 內(nèi)容如下：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
labels:
app: elasticsearch
component: data
release: elasticsearch-logging
role: data
name: data-elasticsearch-logging-data-0
namespace: kubesphere-logging-system
spec:
storageClassName: csi-qingcloud
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
volumeMode: Filesystem
volumeName: pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
在『存儲卷聲明』頁面點擊『創(chuàng)建』：
選擇『編輯 YAML』，將上面的 YAML 內(nèi)容復(fù)制粘貼進(jìn)去，然后點擊『創(chuàng)建』：
最終可以看到新的 PVC 和 PV 全部都是 Bound 狀態(tài)：
$ kubectl -n kubesphere-logging-system get pvc data-elasticsearch-logging-data-0
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
data-elasticsearch-logging-data-0 Bound pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO csi-qingcloud 64s
$ kubectl get pv pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-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 的數(shù)據(jù)，對于 data-elasticsearch-logging-data-1，按照上面的步驟再重復(fù)一遍就行了，記得將 datacopy 中的 PVC 改為 data-elasticsearch-logging-data-1 和 new-data-elasticsearch-logging-data-0，其他地方的配置內(nèi)容也要修改為新的。
恢復(fù)工作負(fù)載
現(xiàn)在所有的存儲都遷移完成，PVC 名稱保持不變，PV 使用的是新的存儲。
$ kubectl get pv -A|grep elasticsearch-logging-data
pvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-1 local-hostpath 40h
pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-0 local-hostpath 40h
pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO Retain Bound kubesphere-logging-system/data-elasticsearch-logging-data-1 csi-qingcloud 9m53s
pvc-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-data
data-elasticsearch-logging-data-0 Bound pvc-f4e96f69-b3be-4afe-bb52-1e8e728ca55e 20Gi RWO csi-qingcloud 27m
data-elasticsearch-logging-data-1 Bound pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO csi-qingcloud 3m49s
將工作負(fù)載的副本恢復(fù)到之前的數(shù)量：
$ kubectl -n kubesphere-logging-system scale sts elasticsearch-logging-data --replicas=2
statefulset.apps/elasticsearch-logging-data scaled
$ kubectl -n kubesphere-logging-system get pod -l app=elasticsearch,component=data
NAME READY STATUS RESTARTS AGE
elasticsearch-logging-data-0 1/1 Running 0 4m12s
elasticsearch-logging-data-1 1/1 Running 0 3m42s
完美！
最后還有一點收尾工作，我們需要將所有新 PV 的回收策略重新設(shè)置為 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-data
pvc-0851350a-270e-4d4d-af8d-081132c1775b 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-1 local-hostpath 40h
pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9 20Gi RWO Retain Released kubesphere-logging-system/data-elasticsearch-logging-data-0 local-hostpath 40h
pvc-d0acd2e7-ee1d-47cf-8506-69147fe25563 20Gi RWO Delete Bound kubesphere-logging-system/data-elasticsearch-logging-data-1 csi-qingcloud 15m
pvc-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-081132c1775b
persistentvolume "pvc-0851350a-270e-4d4d-af8d-081132c1775b" deleted
$ kubectl delete pv pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9
persistentvolume "pvc-9aed3d1b-09a6-4fe3-8adc-9195a2bbb2b9" deleted
更簡單的方案
上面的方案雖然完美解決了問題，但步驟比較繁瑣，有沒有更簡潔的方法呢？
可以試試青云推出的云原生備份容災(zāi) SaaS 服務(wù)[6]，無需部署、維護(hù)本地備份基礎(chǔ)架構(gòu)，即可輕松完成多云異構(gòu)環(huán)境下數(shù)據(jù)的自由遷移，從而實現(xiàn)多地、按需的數(shù)據(jù)保護(hù)與應(yīng)用的高可用。而且價格比較親民，對白嫖黨友好，提供了 100GB 的免費存儲，遷移幾個 PV 完全夠用了。
使用起來非常簡單，先注冊賬戶[7]，然后導(dǎo)入 Kubernetes 集群。如果選擇通過代理連接 Kubernetes 集群，需要執(zhí)行紅色方框內(nèi)命令在 Kubernetes 集群中安裝代理。
然后新建托管倉庫。
接下來直接創(chuàng)建備份計劃，選擇直接復(fù)制。
備份成功之后，將集群中的 PVC 和 PV 刪除，并將工作負(fù)載的副本數(shù)縮減為 0。最后創(chuàng)建恢復(fù)計劃，注意將源存儲類型名稱為 local-hostpath 的目標(biāo)存儲類型名稱設(shè)置為你想遷移的存儲，這樣恢復(fù)后的 PV 使用的就是新的 StorageClass。
完了。
總結(jié)
本文介紹了如何將 Kubernetes 集群中現(xiàn)有 PV 的數(shù)據(jù)遷移到新的 PV，并創(chuàng)建同名的 PVC 來指向新的 PV，這樣就完成了應(yīng)用的數(shù)據(jù)遷移而不需要對應(yīng)用的配置清單做任何更改。最后還介紹了如何通過云原生備份容災(zāi) SaaS 服務(wù)來簡化遷移過程。
引用鏈接
RC 版: https://github.com/kubesphere/kubesphere/releases/tag/v3.3.0-rc.2
[2]QingCloud CSI: https://github.com/yunify/qingcloud-csi
[3]ReadWriteOnce: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
[4]ReadWriteMany: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
[5]通過 StorageClass 來設(shè)置全局的回收策略（reclaimPolicy）: https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy
[6]云原生備份容災(zāi) SaaS 服務(wù): https://kubesphere.cloud/self-service/disaster-recovery/
[7]注冊賬戶: https://kubesphere.cloud/sign-up/
你可能還喜歡
點擊下方圖片即可閱讀
2022-06-14
2022-06-13
2022-06-11
2022-06-10
云原生是一種信仰 ??
關(guān)注公眾號
后臺回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！
點擊 "閱讀原文" 獲取更好的閱讀體驗！
發(fā)現(xiàn)朋友圈變“安靜”了嗎？
