小米平板5 Pro 12.4簡評：多專多能 兼顧影音娛樂的大屏利器
疫情帶來了網(wǎng)課，網(wǎng)課盤活了安卓平板，安卓平板市場雖然中途停滯了幾年，但好的一點就是停滯的這幾年行業(yè)又有了新的發(fā)展方向，例如超窄邊框、高刷新率、多攝鏡頭組合等，這就讓安卓
前文我們介紹了通過 Longhorn UI 可以對卷進(jìn)行快照、備份恢復(fù)等功能，此外我們還可以通過 Kubernetes 來實現(xiàn)對卷的管理，比如可以在集群上通過 CSI 來實現(xiàn)快照、備份恢復(fù)、克隆、擴(kuò)容等功能支持。
CSI 卷快照
Kubernetes 從 1.12 版本開始引入了存儲卷快照功能，在 1.17 版本進(jìn)入 Beta 版本，和 PV、PVC 兩個資源對象類似，Kubernetes 提供了 VolumeSnapshotContent、VolumeSnapshot、VolumeSnapshotClass 三個資源對象用于卷快照管理。
概念
VolumeSnapshotContent 是基于某個 PV 創(chuàng)建的快照，類似于 PV 的資源概念;VolumeSnapshot 是用戶對卷快照的請求，類似于持久化聲明 PVC 的概念;VolumeSnapshotClass 對象可以來設(shè)置快照的特性，屏蔽 VolumeSnapshotContent 的細(xì)節(jié)，為 VolumeSnapshot 綁定提供動態(tài)管理，就像 StorageClass 的“類”概念。
卷快照能力為 Kubernetes 用戶提供了一種標(biāo)準(zhǔn)的方式來在指定時間點復(fù)制卷的內(nèi)容，并且不需要創(chuàng)建全新的卷，比如數(shù)據(jù)庫管理員可以在執(zhí)行編輯或刪除之類的修改之前對數(shù)據(jù)庫執(zhí)行備份。
但是在使用該功能時，需要注意以下幾點：
VolumeSnapshot、VolumeSnapshotContent 和 VolumeSnapshotClass 資源對象是 CRDs， 不屬于核心 API。VolumeSnapshot 支持僅可用于 CSI 驅(qū)動。作為 VolumeSnapshot 部署過程的一部分，Kubernetes 團(tuán)隊提供了一個部署于控制平面的快照控制器，并且提供了一個叫做 csi-snapshotter 的 Sidecar 容器，和 CSI 驅(qū)動程序一起部署，快照控制器會去監(jiān)聽 VolumeSnapshot 和 VolumeSnapshotContent 對象，并且負(fù)責(zé)創(chuàng)建和刪除 VolumeSnapshotContent 對象。csi-snapshotter 監(jiān)聽 VolumeSnapshotContent 對象，并且觸發(fā)針對 CSI 端點的 CreateSnapshot 和 DeleteSnapshot 的操作，完成快照的創(chuàng)建或刪除。CSI 驅(qū)動可能實現(xiàn)，也可能沒有實現(xiàn)卷快照功能，CSI 驅(qū)動可能會使用 csi-snapshotter 來提供對卷快照的支持，詳見 CSI 驅(qū)動程序文檔(https://kubernetes-csi.github.io/docs/external-snapshotter.html)。
VolumeSnapshotContents 和 VolumeSnapshots 的生命周期包括資源供應(yīng)、資源綁定、對使用 PVC 的保護(hù)機(jī)制和資源刪除等各個階段，這兩個對象會遵循這些生命周期。
資源供應(yīng)：與 PV 的資源供應(yīng)類似，VolumeSnapshotContent 也可以以靜態(tài)或動態(tài)兩種方式供應(yīng)資源。
靜態(tài)供應(yīng)：集群管理員會預(yù)先創(chuàng)建好一組 VolumeSnapshotContent 資源，類似于手動創(chuàng)建 PV動態(tài)供應(yīng)：基于 VolumeSnapshotClass 資源，當(dāng)用戶創(chuàng)建 VolumeSnapshot 申請時自動創(chuàng)建 VolumeSnapshotContent，類似于 StorageClass 動態(tài)創(chuàng)建 PV
資源綁定：快照控制器負(fù)責(zé)將 VolumeSnapshot 與一個合適的 VolumeSnapshotContent 進(jìn)行綁定，包括靜態(tài)和動態(tài)供應(yīng)兩種情況，VolumeSnapshot 和 VolumeSnapshotContent 之間也是一對一進(jìn)行綁定的，不會存在一對多的情況。
對使用中的PVC的保護(hù)機(jī)制：當(dāng)存儲快照 VolumeSnapshot 正在被創(chuàng)建且還未完成時，相關(guān)的 PVC 將會被標(biāo)記為正被使用中，如果用戶對 PVC 進(jìn)行刪除操作，系統(tǒng)不會立即刪除 PVC，以避免快照還未做完造成數(shù)據(jù)丟失，刪除操作會延遲到 VolumeSnapshot 創(chuàng)建完成(readyToUse 狀態(tài))或被終止(aborted 狀態(tài))的情況下完成。
資源刪除：對 VolumeSnapshot 發(fā)起刪除操作時，對與其綁定的后端 VolumeSnapshotContent 的刪除操作將基于刪除策略 DeletionPolicy 的設(shè)置來決定，可以配置的刪除策略有：
Delete：自動刪除 VolumeSnapshotContent 資源對象和快照的內(nèi)容。Retain：VolumeSnapshotContent 資源對象和快照的內(nèi)容都將保留，需要手動清理。
我們這里的 Longhorn 系統(tǒng)在部署完成后創(chuàng)建了3個 csi-snapshotter 的 Pod：
? kubectl get pods -n longhorn-system
NAME READY STATUS RESTARTS AGE
csi-snapshotter-86f65d8bc-9t7dd 1/1 Running 5 (126m ago) 2d17h
csi-snapshotter-86f65d8bc-d6xbj 1/1 Running 5 (126m ago) 2d17h
csi-snapshotter-86f65d8bc-dncwv 1/1 Running 5 (126m ago) 2d17h
......
這其實是啟動的3個副本，同一時間只有一個 Pod 提供服務(wù)，通過 leader-election 來實現(xiàn)的選主高可用，比如當(dāng)前這里提供服務(wù)的是 csi-snapshotter-86f65d8bc-dncwv，我們可以查看對應(yīng)的日志信息：
? 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 內(nèi)置的資源對象，而我們在安裝 Longhorn 的時候也沒有安裝這兩個 CRDs，所以找不到，要通過 CSI 來實現(xiàn)卷快照功能自然就需要先安裝 CRDs，我們可以從 https://github.com/kubernetes-csi/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 -
上面的命令會安裝上面提到的3個 Snapshot CRDs:
? kubectl get crd |grep snapshot
volumesnapshotclasses.snapshot.storage.k8s.io 2022-02-23T05:31:34Z
volumesnapshotcontents.snapshot.storage.k8s.io 2022-02-23T05:31:34Z
volumesnapshots.snapshot.storage.k8s.io 2022-02-23T05:31:34Z
安裝完成后再去查看上面的 csi-snapshotter 相關(guān)的 Pod 日志就正常了。CRDs 安裝完成后還不夠，我們還需要一個快照控制器來監(jiān)聽 VolumeSnapshot 和 VolumeSnapshotContent 對象，同樣 external-snapshotter 項目中也提供了一個 Common Snapshot Controller，執(zhí)行下面的命令一鍵安裝：
# 修改 deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml 鏡像地址為 cnych/csi-snapshot-controller:v5.0.0，默認(rèn)為 gcr 鏡像
? kubectl -n kube-system kustomize deploy/kubernetes/snapshot-controller | kubectl create -f -
這里我們將快照控制器安裝到了 kube-system 命名空間下，啟動兩個副本，同樣同一時間只有一個 Pod 提供服務(wù)：
? kubectl get pods -n kube-system -l app=snapshot-controller
NAME READY STATUS RESTARTS AGE
snapshot-controller-677b65dc6c-288w9 1/1 Running 0 3m22s
snapshot-controller-677b65dc6c-zgdcm 1/1 Running 0 39s
到這里就將使用 CSI 來配置快照的環(huán)境準(zhǔn)備好了。
測試
下面我們?nèi)匀灰郧懊娴?mysql-pvc 這個卷為例來說明下如何使用卷快照功能：
? kubectl get pvc mysql-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pvc Bound pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307 1Gi RWO longhorn 2d18h
要創(chuàng)建 mysql-pvc 的快照申請，首先需要創(chuàng)建一個 VolumeSnapshot 對象：
# 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
其中就兩個主要配置參數(shù)：
volumeSnapshotClassName：指定 VolumeSnapshotClass 的名稱，這樣就可以動態(tài)創(chuàng)建一個對應(yīng)的 VolumeSnapshotContent 與之綁定，如果沒有指定該參數(shù)，則屬于靜態(tài)方式，需要手動創(chuàng)建 VolumeSnapshotContent。persistentVolumeClaimName：指定數(shù)據(jù)來源的 PVC 名稱。volumeSnapshotContentName：如果是申請靜態(tài)存儲快照，則需要通過該參數(shù)來指定一個 VolumeSnapshotContent。
上面我們指定了一個存儲快照類 longhorn，當(dāng)然需要創(chuàng)建這個對象：
# snapshotclass.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: longhorn
# annotations: # 如果要指定成默認(rèn)的快照類
# snapshot.storage.kubernetes.io/is-default-class: "true"
driver: driver.longhorn.io
deletionPolicy: Delete
每個 VolumeSnapshotClass 都包含 driver、deletionPolicy 和 parameters 字段，在需要動態(tài)配置屬于該類的 VolumeSnapshot 時使用。
driver：表示 CSI 存儲插件驅(qū)動的名稱，這里我們使用的是 Longhorn 插件，名為 driver.longhorn.iodeletionPolicy：刪除策略，可以設(shè)置為 Delete 或 Retain，如果刪除策略是 Delete，那么底層的存儲快照會和 VolumeSnapshotContent 對象一起刪除，如果刪除策略是 Retain，那么底層快照和 VolumeSnapshotContent 對象都會被保留。parameters：存儲插件需要配置的參數(shù)，由 CSI 驅(qū)動提供具體的配置參數(shù)。
如果想將當(dāng)前快照類設(shè)置成默認(rèn)的則需要添加 snapshot.storage.kubernetes.io/is-default-class: "true" 這樣的 annotations。
現(xiàn)在我們直接創(chuàng)建上面的兩個資源對象：
? kubectl apply -f snapshotclass.yaml
volumesnapshotclass.snapshot.storage.k8s.io/longhorn created
? kubectl apply -f snapshot-mysql.yaml
volumesnapshot.snapshot.storage.k8s.io/mysql-snapshot-demo created
? kubectl get volumesnapshotclass
NAME DRIVER DELETIONPOLICY AGE
longhorn driver.longhorn.io Delete 43s
? kubectl get volumesnapshot
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS SNAPSHOTCONTENT CREATIONTIME AGE
mysql-snapshot-demo true mysql-pvc 1Gi longhorn snapcontent-1119649a-d4f2-447f-a21a-e527f202e43e 43s 43s
這個時候會動態(tài)為我們創(chuàng)建一個 VolumeSnapshotContent 對象：
? kubectl get volumesnapshotcontent
NAME READYTOUSE RESTORESIZE DELETIONPOLICY DRIVER VOLUMESNAPSHOTCLASS VOLUMESNAPSHOT VOLUMESNAPSHOTNAMESPACE AGE
snapcontent-1119649a-d4f2-447f-a21a-e527f202e43e true 1073741824 Delete driver.longhorn.io longhorn mysql-snapshot-demo default 97s
自動創(chuàng)建的 VolumeSnapshotContent 對象內(nèi)容如下所示：
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: snapcontent-1119649a-d4f2-447f-a21a-e527f202e43e
spec:
deletionPolicy: Delete
driver: driver.longhorn.io
source:
volumeHandle: pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307
volumeSnapshotClassName: longhorn
volumeSnapshotRef:
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
name: mysql-snapshot-demo
namespace: default
resourceVersion: "4967456"
uid: 1119649a-d4f2-447f-a21a-e527f202e43e
status:
creationTime: 1645597546000000000
readyToUse: true
restoreSize: 1073741824
snapshotHandle: bs://pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307/backup-f5f28fd624a148ed
其中的 source.volumeHandle 字段的值是在后端存儲上創(chuàng)建并由 CSI 驅(qū)動在創(chuàng)建存儲卷期間返回的 Volume 的唯一標(biāo)識符，在動態(tài)供應(yīng)模式下需要該字段，指定的是快照的來源 Volume 信息，volumeSnapshotRef 下面就是和關(guān)聯(lián)的 VolumeSnapshot 對象的相關(guān)信息。當(dāng)然這個時候我們在 Longhorn UI 界面上也可以看到上面我們創(chuàng)建的這個快照了，快照名稱為 snapshot-1119649a-d4f2-447f-a21a-e527f202e43e，后面的 ID 與上面的 VolumeSnapshotContent 名稱保持一致：
并且也會進(jìn)行一次對應(yīng)的 Backup 操作，備份的信息通過 snapshotHandle 進(jìn)行指定的，格式為 bs://backup-/backup-：
這樣我們就完成了通過 CSI 實現(xiàn)卷的快照管理功能。
CSI 卷恢復(fù)
Kubernetes 對基于快照創(chuàng)建存儲卷在 1.17 版本更新到了 Beta 版本，要啟用該特性，就需要在 kube-apiserver、kube-controller-manager 和 kubelet 的 Feature Gate 中啟用 --feature-gates=...,VolumeSnapshotDataSource(我們這里是1.22版本默認(rèn)已經(jīng)啟用了)，然后就可以基于某個快照創(chuàng)建一個新的 PVC 存儲卷了，比如現(xiàn)在我們來基于上面創(chuàng)建的 mysql-snapshot-demo 這個對象來創(chuàng)建一個新的 PVC：
# 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 的存儲快照進(jìn)行創(chuàng)建，創(chuàng)建上面的資源對象后同樣會自動創(chuàng)建一個 PV 與之綁定：
? kubectl get pvc mysql-restore-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-restore-pvc Bound pvc-e4ddd985-31a8-4570-b393-dcedec3b0d95 1Gi RWO longhorn 17s
在 Longhorn UI 中去查看該卷，可以看到該卷的實際大小并不為0，這是因為我們是從快照中創(chuàng)建過來的，相當(dāng)于從上面的快照中恢復(fù)的數(shù)據(jù)：
卷克隆
除了基于快照創(chuàng)建新的 PVC 對象之外，CSI 類型的存儲還支持存儲的克隆功能，可以基于已經(jīng)存在的 PVC 克隆一個新的 PVC，實現(xiàn)方式也是通過在 dataSource 字段中來設(shè)置源 PVC 來實現(xiàn)。
克隆一個 PVC 其實就是對已存在的存儲卷創(chuàng)建一個副本，唯一的區(qū)別是，系統(tǒng)在為克隆 PVC 提供后端存儲資源時，不是新建一個空的 PV，而是復(fù)制一個與原 PVC 綁定 PV 完全一樣的 PV。
從 Kubernetes API 的角度看，克隆的實現(xiàn)只是在創(chuàng)建新的 PVC 時， 增加了指定一個現(xiàn)有 PVC 作為數(shù)據(jù)源的能力。源 PVC 必須是 bound 狀態(tài)且可用的(不在使用中)。
用戶在使用該功能時，需要注意以下事項：
克隆僅適用于 CSI 驅(qū)動克隆僅適用于動態(tài)供應(yīng)克隆功能取決于具體的 CSI 驅(qū)動是否實現(xiàn)該功能要求目標(biāo) PVC 和源 PVC 必須處于同一個命名空間只支持在相同的 StorageClass 中(可以使用默認(rèn)的)兩個存儲卷的存儲模式(VolumeMode)要一致
同樣我們來對前面的 mysql-pvc 這個存儲卷進(jìn)行克隆操作，對應(yīng)的 PVC 聲明如下所示：
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 的名稱，直接創(chuàng)建這個資源對象，結(jié)果是 mysql-clone-pvc 這個新的 PVC 與源 mysql-pvc 擁有相同的數(shù)據(jù)。
? kubectl get pvc mysql-clone-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-clone-pvc Bound pvc-58eab5f0-a386-435c-91f4-0c26f7935695 1Gi RWO longhorn 31s
在 Longhorn UI 頁面中也可以看到對應(yīng)的卷：
一旦新的 PVC 可用，被克隆的 PVC 就可以像其他 PVC 一樣被使用了，也可以對其進(jìn)行克隆、快照、刪除等操作。
卷動態(tài)擴(kuò)容
我們知道對于存儲來說擴(kuò)容是一個非常重要的需求，對于 Kubernetes 中的卷動態(tài)擴(kuò)容同樣也是需要的基本功能，PV 要做擴(kuò)容操作是需要底層存儲支持該操作才能實現(xiàn)，Longhorn 底層是支持卷擴(kuò)容操作的，但是要求擴(kuò)展的卷必須處于 detached 狀態(tài)才能操作，有兩種方法可以擴(kuò)容 Longhorn 卷：修改 PVC 和使用 Longhorn UI。
通過 Longhorn UI 操作比較簡單，直接在頁面中選擇要擴(kuò)容的卷，在操作中選擇 Expand Volume 進(jìn)行操作即可：
要通過 PVC 來進(jìn)行擴(kuò)容首先需要 PVC 由 Longhorn StorageClass 進(jìn)行動態(tài)供應(yīng)，并且在 StorageClass 中 allowVolumeExpansion 屬性設(shè)置為 true，建議使用這種方法，因為 PVC 和 PV 會自動更新，并且在擴(kuò)容后都會保持一致。比如上面使用的 mysql-clone-pvc 這個卷(處于 detached 狀態(tài))使用的 longhorn 這個 StorageClass 中就已經(jīng)配置了 allowVolumeExpansion: true，然后直接修改 mysql-pvc 這個卷下面的 spec.resources.requests.storage 值即可：
? kubectl get pvc mysql-clone-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-clone-pvc Bound pvc-58eab5f0-a386-435c-91f4-0c26f7935695 1Gi RWO longhorn 40m
? kubectl patch pvc mysql-clone-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}}'
修改后可以查看該 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 組件實現(xiàn)了 Resize 操作，查看 PVC 和 PV 的大小驗證：
? kubectl get pvc mysql-clone-pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-clone-pvc Bound pvc-58eab5f0-a386-435c-91f4-0c26f7935695 2Gi RWO longhorn 43m
? kubectl get pv pvc-58eab5f0-a386-435c-91f4-0c26f7935695
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-58eab5f0-a386-435c-91f4-0c26f7935695 2Gi RWO Delete Bound default/mysql-clone-pvc longhorn 43m
可以看到 PVC 和 PV 中的容量都變成了 2Gi，證明擴(kuò)容成功了，通過 Longhorn UI 也可以查看到卷擴(kuò)容成功了：
本文鏈接：http://m.www897cc.com/showinfo-119-2181-0.html通過 Kubernetes CSI 實現(xiàn) Longhorn 卷快照備份、恢復(fù)、克隆與擴(kuò)容功能
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號