Kubernetes 中跨 StorageClass 遷移存儲(chǔ)完全指南

大家好，我是米開(kāi)朗基楊。

KubeSphere 3.3.0 （不出意外的話~）下周就要 GA 了，作為一名 KubeSphere 腦殘粉，我迫不及待地先安裝 RC 版^[1]嘗嘗鮮，一頓操作猛如虎開(kāi)啟所有組件，裝完之后發(fā)現(xiàn)有點(diǎn)尷尬：我用錯(cuò)了持久化存儲(chǔ)。

我的 K8s 集群中有兩個(gè)存儲(chǔ)類(lèi)（StorageClass），一個(gè)是 OpenEBS 提供的本地存儲(chǔ)，另一個(gè)是 QingCloud CSI^[2] 提供的分布式存儲(chǔ)，而且默認(rèn)的 StorageClass 是 OpenEBS 提供的 local-hostpath，所以 KubeSphere 的有狀態(tài)組件默認(rèn)便使用本地存儲(chǔ)來(lái)保存數(shù)據(jù)。

失誤失誤，我本來(lái)是想用分布式存儲(chǔ)作為默認(rèn)存儲(chǔ)的，但是我忘記將 csi-qingcloud 設(shè)置為默認(rèn)的 StorageClass 了，反正不管怎樣，就這么稀里糊涂地搞錯(cuò)了。雖然重裝可以解決 99% 的問(wèn)題，但作為一名成熟的 YAML 工程師，重裝是不可能的，必須在不重裝的情況下解決這個(gè)問(wèn)題，才能體現(xiàn)出我的氣質(zhì)！

事實(shí)上不止我一個(gè)人遇到過(guò)這種情況，很多人都會(huì)稀里糊涂地裝完一整套產(chǎn)品之后發(fā)現(xiàn) StorageClass 用錯(cuò)了，這時(shí)候再想改回去恐怕就沒(méi)那么容易了。這不巧了么這不是，本文就是來(lái)幫助大家解決這個(gè)問(wèn)題的。

思路

我們先來(lái)思考一下?lián)Q StorageClass 需要做哪幾件事情。首先需要將應(yīng)用的副本數(shù)縮減為 0，然后創(chuàng)建一個(gè)新的 PVC，將舊 PV 的數(shù)據(jù)復(fù)制到新 PV，然后讓?xiě)?yīng)用使用新的 PV，并將副本擴(kuò)展到原來(lái)的數(shù)量，最后再將舊 PV 刪除。在這整個(gè)過(guò)程中還要防止刪除 PVC 時(shí) Kubernetes 將 PV 也刪除了。

當(dāng)然，有些 CSI 驅(qū)動(dòng)或者存儲(chǔ)后端可能會(huì)有更便利的數(shù)據(jù)遷移技巧，但是本文提供的是一種更加通用的方案，不管后端是什么存儲(chǔ)都可以。

KubeSphere 3.3.0 開(kāi)啟所有組件之后使用的持久卷聲明（PVC）如下：

本文就以 Elasticsearch 為例，演示如何將 Elasticsearch 的存儲(chǔ)從本地存儲(chǔ)替換為分布式存儲(chǔ)。

備份 PVC 和 PV

首先第一步就是備份 PVC 和 PV，萬(wàn)一后面操作失敗了，還有反悔的余地。

$ 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，因?yàn)?ReadWriteOne 模式同時(shí)只允許掛載一個(gè) Pod，新 Pod 無(wú)法掛載，而 ReadWriteMany 模式如果不將副本數(shù)量縮減為 0，在復(fù)制數(shù)據(jù)時(shí)可能會(huì)有新的數(shù)據(jù)寫(xiě)入。所以無(wú)論如何，都要將副本數(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)建一個(gè)新的 PVC 叫 new-data-elasticsearch-logging-data-0，容量和 data-elasticsearch-logging-data-0 一樣，并將 storageClassName 指定為新的 StorageClass。

創(chuàng)建一個(gè) Deployment，將新 PV 和舊 PV 都掛載進(jìn)去，然后再將舊 PV 的數(shù)據(jù)拷貝到新 PV。

在『工作負(fù)載』界面點(diǎn)擊『創(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

這個(gè) Deployment 將新 PV 和舊 PV 都掛載進(jìn)去了，稍后我們會(huì)將舊 PV 的數(shù)據(jù)拷貝到新 PV。

Pod 啟動(dòng)成功后，點(diǎn)擊容器的終端圖標(biāo)進(jìn)入容器的終端。

在容器中先驗(yàn)證舊 PV 的掛載點(diǎn)是否包含應(yīng)用數(shù)據(jù)，新 PV 的掛載點(diǎn)是否是空的，之后再執(zhí)行命令 (cd /mnt/old; tar -cf - .) | (cd /mnt/new; tar -xpf -)，以確保所有數(shù)據(jù)的所有權(quán)和權(quán)限被繼承。

執(zhí)行完成后，驗(yàn)證新 PV 的掛載點(diǎn)是否包含舊 PV 的數(shù)據(jù)，以及所有權(quán)和權(quán)限是否被正確繼承。

到這里復(fù)制數(shù)據(jù)的任務(wù)就完成了，現(xiàn)在我們需要將 datacopy 的副本數(shù)量縮為 0。

遷移 PVC

遷移存儲(chǔ)的理想狀態(tài)是使用舊的 PVC，并將其指向新的 PV，這樣工作負(fù)載的 YAML 配置清單就不需要做任何改變。但 PVC 和 PV 之間的綁定關(guān)系是不可更改的，要想讓它們解綁，必須先刪除舊的 PVC，再創(chuàng)建同名的 PVC，并將舊的 PV 與它綁定。

需要注意的是，默認(rèn)情況下 PV 的回收策略是 Delete，一旦刪除 PVC，與之綁定的 PV 和 PV 里的數(shù)據(jù)都會(huì)被刪除。這是我們不希望看到的，所以我們需要修改回收策略，以便刪除 PVC 時(shí) PV 能夠保留下來(lái)。

事實(shí)上可以通過(guò) StorageClass 來(lái)設(shè)置全局的回收策略（reclaimPolicy）^[5]，如果不設(shè)置，默認(rèn)就是 Delete。可以通過(guò)命令 kubectl describe pv <pv-name> 來(lái)查看 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
...

我們可以通過(guò) 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

?

??注意：該命令對(duì) PV 的穩(wěn)定性和可用性沒(méi)有任何影響，可以隨時(shí)執(zhí)行。

現(xiàn)在可以將新舊 PVC 全部刪除，PV 不會(huì)受到任何影響。

$ 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 上。通過(guò)以下命令可以看到新 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
...

這是因?yàn)?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

為了解決這個(gè)問(wèn)題，可以直接通過(guò)命令 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

最終我們需要?jiǎng)?chuàng)建與舊 PVC 同名的新 PVC，而且要盡可能保證與舊 PVC 的參數(shù)相同：

• 新 PVC 的名字和舊 PVC 的名字相同；
• spec.volumeName 指向新 PV；
• 新 PVC 的 metadata.annotations 和 metadata.labels 和舊 PVC 保存相同，因?yàn)檫@些值可能會(huì)影響到應(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

在『存儲(chǔ)卷聲明』頁(yè)面點(diǎn)擊『創(chuàng)建』：

選擇『編輯 YAML』，將上面的 YAML 內(nèi)容復(fù)制粘貼進(jìn)去，然后點(diǎ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

再來(lái)一遍

到目前為止，我們只遷移了 data-elasticsearch-logging-data-0 的數(shù)據(jù)，對(duì)于 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)在所有的存儲(chǔ)都遷移完成，PVC 名稱(chēng)保持不變，PV 使用的是新的存儲(chǔ)。

$ 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

完美！

最后還有一點(diǎn)收尾工作，我們需要將所有新 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

更簡(jiǎn)單的方案

上面的方案雖然完美解決了問(wèn)題，但步驟比較繁瑣，有沒(méi)有更簡(jiǎn)潔的方法呢？

可以試試青云推出的云原生備份容災(zāi) SaaS 服務(wù)^[6]，無(wú)需部署、維護(hù)本地備份基礎(chǔ)架構(gòu)，即可輕松完成多云異構(gòu)環(huán)境下數(shù)據(jù)的自由遷移，從而實(shí)現(xiàn)多地、按需的數(shù)據(jù)保護(hù)與應(yīng)用的高可用。而且價(jià)格比較親民，對(duì)白嫖黨友好，提供了 100GB 的免費(fèi)存儲(chǔ)，遷移幾個(gè) PV 完全夠用了。

使用起來(lái)非常簡(jiǎn)單，先注冊(cè)賬戶(hù)^[7]，然后導(dǎo)入 Kubernetes 集群。如果選擇通過(guò)代理連接 Kubernetes 集群，需要執(zhí)行紅色方框內(nèi)命令在 Kubernetes 集群中安裝代理。

然后新建托管倉(cāng)庫(kù)。

接下來(lái)直接創(chuàng)建備份計(jì)劃，選擇直接復(fù)制。

備份成功之后，將集群中的 PVC 和 PV 刪除，并將工作負(fù)載的副本數(shù)縮減為 0。最后創(chuàng)建恢復(fù)計(jì)劃，注意將源存儲(chǔ)類(lèi)型名稱(chēng)為 local-hostpath 的目標(biāo)存儲(chǔ)類(lèi)型名稱(chēng)設(shè)置為你想遷移的存儲(chǔ)，這樣恢復(fù)后的 PV 使用的就是新的 StorageClass。

完了。

總結(jié)

本文介紹了如何將 Kubernetes 集群中現(xiàn)有 PV 的數(shù)據(jù)遷移到新的 PV，并創(chuàng)建同名的 PVC 來(lái)指向新的 PV，這樣就完成了應(yīng)用的數(shù)據(jù)遷移而不需要對(duì)應(yīng)用的配置清單做任何更改。最后還介紹了如何通過(guò)云原生備份容災(zāi) SaaS 服務(wù)來(lái)簡(jiǎn)化遷移過(guò)程。

引用鏈接

你可能還喜歡

點(diǎn)擊下方圖片即可閱讀

系統(tǒng)的過(guò)載（Overload）以及處理思路

2022-06-14

Kubernetes 容器和鏡像 GC 原理解析

2022-06-13

構(gòu)建我的第一個(gè) 22TB 容量的家庭存儲(chǔ)服務(wù)器

2022-06-11

如何在 Mac 上愉快地使用 Docker

2022-06-10

云原生是一種信仰 ??

關(guān)注公眾號(hào)

后臺(tái)回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！