本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 卷快照 Alpha 更新

作者：DJing Xu (Google), Xing Yang (Huawei), Saad Ali (Google) | 2019 年 1 月 17 日，星期四

Kubernetes v1.12 引入了儲存卷快照支援作為一項 Alpha 功能。在 Kubernetes v1.13 中，它仍然是一項 Alpha 功能，但增加了一些增強功能並進行了一些重大更改。本文總結了這些更改。

重大更改

CSI 規範 v1.0 對儲存卷快照功能引入了一些重大更改。CSI 驅動程式維護者在將其驅動程序升級到支援 v1.0 時應注意這些更改。

SnapshotStatus 已替換為布林值 ReadyToUse

CSI v0.3.0 在 CreateSnapshotResponse 中定義了一個 SnapshotStatus 列舉，它指示快照是否為 READY、UPLOADING 或 ERROR_UPLOADING。在 CSI v1.0 中，SnapshotStatus 已從 CreateSnapshotResponse 中刪除，並替換為 boolean ReadyToUse。ReadyToUse 值為 true 表示快照後處理（例如上傳）已完成，並且快照已準備好用作建立儲存卷的源。

需要進行快照後處理（例如快照拍攝後上傳）的儲存系統應在快照拍攝完成後立即返回成功的 CreateSnapshotResponse，並將 ReadyToUse 欄位設定為 false。這表明容器編排系統（CO）可以恢復為拍攝快照而暫停的任何工作負載。然後，CO 可以重複呼叫 CreateSnapshot，直到 ReadyToUse 欄位設定為 true，或者呼叫返回指示處理問題的錯誤。CSI ListSnapshot 呼叫可以與 snapshot_id 過濾一起使用以確定快照是否準備就緒，但不建議這樣做，因為它無法檢測處理過程中的錯誤（ReadyToUse 欄位只是無限期地保持 false）。

CSI external-snapshotter Sidecar 容器的 v1.x.x 版本已經透過呼叫 CreateSnapshot 而不是 ListSnapshots 來檢查快照是否準備就緒來處理此更改。在將驅動程序升級到 CSI 1.0 時，驅動程式維護者應使用相應的 1.0 相容 Sidecar 容器。

為了與 CSI 規範中的更改保持一致，VolumeSnapshot API 物件中的 Ready 欄位已重新命名為 ReadyToUse。當執行 kubectl describe volumesnapshot 檢視快照詳細資訊時，使用者可以看到此更改。

時間戳資料型別

快照的建立時間作為 VolumeSnapshotContent API 物件的一部分可供 Kubernetes 管理員使用。此欄位使用 CSI CreateSnapshotResponse 中的 creation_time 欄位填充。在 CSI v1.0 中，此 creation_time 欄位型別已更改為 .google.protobuf.Timestamp 而不是 int64。在將驅動程序升級到 CSI 1.0 時，驅動程式維護者必須相應地進行更改。CSI external-snapshotter Sidecar 容器的 v1.x.x 版本已更新以處理此更改。

廢棄

以下 VolumeSnapshotClass 引數已廢棄，並將在未來的版本中刪除。它們將被下面“替換”部分中列出的引數替換。

已廢棄的替換項 csiSnapshotterSecretName csi.storage.k8s.io/snapshotter-secret-name csiSnapshotterSecretNameSpace csi.storage.k8s.io/snapshotter-secret-namespace

新功能

SnapshotContent 刪除/保留策略

正如宣佈快照 Alpha 版的最初部落格文章中所述，Kubernetes 快照 API 與 PV/PVC API 類似：就像儲存卷由繫結的 PVC 和 PV 對錶示一樣，快照由繫結的 VolumeSnapshot 和 VolumeSnapshotContent 對錶示。

對於 PV/PVC 對，當用戶完成使用儲存卷後，他們可以刪除 PVC。PV 上的回收策略決定了 PV 的處理方式（是也被刪除還是保留）。

在最初的 Alpha 版本中，快照不支援指定回收策略。相反，當快照物件被刪除時，它總是導致快照被刪除。在 Kubernetes v1.13 中，添加了快照內容 DeletionPolicy。它使管理員能夠配置在繫結的 VolumeSnapshot 物件被刪除後，VolumeSnapshotContent 將如何處理。卷快照的 DeletionPolicy 可以是 Retain 或 Delete。如果未指定值，則預設值取決於 SnapshotContent 物件是透過靜態繫結還是動態配置建立的。

保留

Retain 策略允許手動回收資源。如果 VolumeSnapshotContent 是靜態建立並繫結的，則預設的 DeletionPolicy 是 Retain。當 VolumeSnapshot 被刪除時，VolumeSnapshotContent 將繼續存在，並且 VolumeSnapshotContent 被視為“已釋放”。但它不能用於繫結到其他 VolumeSnapshot 物件，因為它包含資料。由管理員決定如何處理剩餘的 API 物件和資源清理。

刪除

Delete 策略支援從 Kubernetes 自動刪除繫結的 VolumeSnapshotContent 物件以及外部基礎設施中相關的儲存資產（例如 AWS EBS 快照或 GCE PD 快照等）。動態配置的快照繼承其 VolumeSnapshotClass 的刪除策略，預設為 Delete。管理員應使用所需的保留策略配置 VolumeSnapshotClass。建立後，可以透過修補物件來更改單個 VolumeSnapshotContent 的策略。

以下示例演示瞭如何檢查動態配置的 VolumeSnapshotContent 的刪除策略。

$ kubectl create -f ./examples/kubernetes/demo-defaultsnapshotclass.yaml
$ kubectl create -f ./examples/kubernetes/demo-snapshot.yaml
$ kubectl get volumesnapshots demo-snapshot-podpvc -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  creationTimestamp: "2018-11-27T23:57:09Z"
...
spec:
  snapshotClassName: default-snapshot-class
  snapshotContentName: snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002
  source:
    apiGroup: null
    kind: PersistentVolumeClaim
    name: podpvc
status:
…
$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
…
spec:
  csiVolumeSnapshotSource:
    creationTime: 1546469777852000000
    driver: pd.csi.storage.gke.io
    restoreSize: 6442450944
    snapshotHandle: projects/jing-k8s-dev/global/snapshots/snapshot-26cd0db3-f2a0-11e8-8be6-42010a800002
  deletionPolicy: Delete
  persistentVolumeRef:
    apiVersion: v1
    kind: PersistentVolume
    name: pvc-853622a4-f28b-11e8-8be6-42010a800002
    resourceVersion: "21117"
    uid: ae400e9f-f28b-11e8-8be6-42010a800002
  snapshotClassName: default-snapshot-class
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1alpha1
    kind: VolumeSnapshot
    name: demo-snapshot-podpvc
    namespace: default
    resourceVersion: "6948065"
    uid: 26cd0db3-f2a0-11e8-8be6-42010a800002

使用者可以透過修補更改刪除策略

$ kubectl patch volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -p '{"spec":{"deletionPolicy":"Retain"}}' --type=merge

$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
...
spec:
  csiVolumeSnapshotSource:
...
  deletionPolicy: Retain
  persistentVolumeRef:
    apiVersion: v1
    kind: PersistentVolume
    name: pvc-853622a4-f28b-11e8-8be6-42010a800002
...

快照物件使用保護

快照物件使用保護功能的目的是確保正在使用的快照 API 物件不會從系統中刪除（因為這可能導致資料丟失）。有兩種情況需要“正在使用”保護：

如果卷快照正在被持久卷宣告主動用作建立卷的源。
如果 VolumeSnapshotContent API 物件繫結到 VolumeSnapshot API 物件，則內容物件被視為正在使用。

如果使用者刪除被 PVC 主動使用的 VolumeSnapshot API 物件，則 VolumeSnapshot 物件不會立即刪除。相反，VolumeSnapshot 物件的刪除將被推遲，直到 VolumeSnapshot 不再被任何 PVC 主動使用。同樣，如果管理員刪除繫結到 VolumeSnapshot 的 VolumeSnapshotContent，則 VolumeSnapshotContent 不會立即刪除。相反，VolumeSnapshotContent 的刪除將被推遲，直到 VolumeSnapshotContent 未繫結到 VolumeSnapshot 物件。

哪些卷外掛支援 Kubernetes 快照？

快照僅支援 CSI 驅動程式（不支援樹內或 FlexVolume）。要使用 Kubernetes 快照功能，請確保叢集上已部署實現快照的 CSI 驅動程式。

截至本部落格文章釋出時，以下 CSI 驅動程式支援快照：

其他驅動程式的快照支援正在進行中，應很快可用。閱讀“Kubernetes CSI (Container Storage Interface) GA”部落格文章，瞭解有關 CSI 以及如何部署 CSI 驅動程式的更多資訊。

下一步是什麼？

根據反饋和採用情況，Kubernetes 團隊計劃在 1.15 或 1.16 版本中將 CSI 快照實現推向 Beta 版。我們感興趣支援的一些功能包括一致性組、應用程式一致性快照、工作負載靜默、原地恢復等。

我如何瞭解更多資訊？

快照 API 和控制器的程式碼倉庫在這裡：https://github.com/kubernetes-csi/external-snapshotter

在此處檢視有關快照功能的更多文件：http://k8s.io/docs/concepts/storage/volume-snapshots 和 https://kubernetes-csi.github.io/docs/

我如何參與？

這個專案，和所有 Kubernetes 專案一樣，是許多來自不同背景的貢獻者共同努力的結果。

特別感謝所有為本次版本中新增 CSI v1.0 支援和改進快照功能做出貢獻的貢獻者，包括 Saad Ali (saadali)、Michelle Au (msau42)、Deep Debroy (ddebroy)、James DeFelice (jdef)、John Griffith (j-griffith)、Julian Hjortshoj (julian-hj)、Tim Hockin (thockin)、Patrick Ohly (pohly)、Luis Pabon (lpabon)、Cheng Xing (verult)、Jing Xu (jingxu97)、Shiwei Xu (wackxu)、Xing Yang (xing-yang)、Jie Yu (jieyu)、David Zhu (davidz627)。

有興趣參與 CSI 或 Kubernetes 儲存系統任何部分的設計和開發的人員，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們正在快速發展，並始終歡迎新的貢獻者。

我們還定期舉行SIG-Storage 快照工作組會議。歡迎新成員加入設計和開發討論。