本篇文章已超過一年。較舊的文章可能包含過時內容。請確認頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 磁碟區快照 Alpha 版更新

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

Volume 快照支援在 Kubernetes v1.12 中以 alpha 功能形式推出。在 Kubernetes v1.13 中，它仍然是 alpha 功能，但新增了一些增強功能，並進行了一些重大變更。這篇文章總結了這些變更。

重大變更

CSI 規範 v1.0 為 Volume 快照功能引入了一些重大變更。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 以檢視快照的詳細資訊時，使用者可以看到此變更。

時間戳記資料類型

快照的建立時間可供 Kubernetes 管理員作為 VolumeSnapshotContent API 物件的一部分使用。此欄位是使用 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。它讓管理員可以設定 VolumeSnapshotContent 在其綁定的 VolumeSnapshot 物件被刪除後的處理方式。Volume 快照的 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 物件不會從系統中移除 (因為這可能會導致資料遺失)。有兩種情況需要「使用中」保護

如果 Volume 快照正在被持續性磁碟區宣告積極使用中，作為建立磁碟區的來源。
如果 VolumeSnapshotContent API 物件綁定到 VolumeSnapshot API 物件，則內容物件會被視為使用中。

如果使用者刪除正在被 PVC 積極使用的 VolumeSnapshot API 物件，則 VolumeSnapshot 物件不會立即移除。相反地，VolumeSnapshot 物件的移除會延遲到 VolumeSnapshot 不再被任何 PVC 積極使用時。同樣地，如果管理員刪除綁定到 VolumeSnapshot 的 VolumeSnapshotContent，則 VolumeSnapshotContent 不會立即移除。相反地，VolumeSnapshotContent 的移除會延遲到 VolumeSnapshotContent 未綁定到 VolumeSnapshot 物件時。

哪些磁碟區外掛程式支援 Kubernetes 快照？

快照僅適用於 CSI 驅動程式 (不適用於 in-tree 或 FlexVolume)。若要使用 Kubernetes 快照功能，請確保實作快照功能的 CSI 驅動程式已部署在您的叢集上。

截至本篇部落格文章發布時，以下 CSI 驅動程式支援快照

其他驅動程式的快照支援仍在等待中，應很快就會推出。請閱讀「Kubernetes 通用版本容器儲存介面 (CSI)」部落格文章，以深入瞭解 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 快照工作小組會議。歡迎新參加者加入設計與開發討論。