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

Kubernetes 1.27：引入卷組快照 API

作者：Xing Yang (VMware) |

卷組快照作為 Alpha 功能在 Kubernetes v1.27 中引入。此功能引入了一個 Kubernetes API，允許使用者為多個卷一起建立崩潰一致性快照。它使用標籤選擇器將多個 PersistentVolumeClaims 分組以進行快照。此新功能僅支援 CSI 卷驅動程式。

卷組快照概述

一些儲存系統提供了為多個卷建立崩潰一致性快照的功能。卷組快照表示在同一時間點為多個卷建立的“副本”。卷組快照可用於恢復新卷（預填充快照資料），或將現有卷恢復到之前的狀態（由快照表示）。

為什麼要在 Kubernetes 中添加捲組快照？

Kubernetes 卷外掛系統已經提供了一個強大的抽象，可以自動執行塊儲存和檔案儲存的製備、掛接、掛載、調整大小和快照。

所有這些功能的基礎是 Kubernetes 的工作負載可移植性目標：Kubernetes 旨在在分散式應用程式和底層叢集之間建立一個抽象層，以便應用程式可以不感知它們所執行叢集的細節，並且應用程式部署不需要特定於叢集的知識。

已經有一個 VolumeSnapshot API，它提供了為持久卷建立快照的功能，以防止資料丟失或資料損壞。但是，還有一些快照功能未被 VolumeSnapshot API 涵蓋。

一些儲存系統支援一致的組快照，允許在同一時間點為多個卷建立快照，以實現寫順序一致性。這對於包含多個卷的應用程式非常有用。例如，一個應用程式可能將資料儲存在一個卷中，將日誌儲存在另一個卷中。如果資料卷和日誌卷的快照在不同時間建立，那麼當災難發生時，如果從這些快照恢復，應用程式將不一致，無法正常工作。

確實，你可以先靜默應用程式，然後依次為應用程式的每個卷建立單獨的快照，在所有單獨的快照建立完成後再取消靜默應用程式。這樣，你就可以獲得應用程式一致性的快照。

然而，有時可能無法靜默應用程式，或者應用程式靜默成本太高，所以你希望減少靜默頻率。與建立一致性組快照相比，逐個建立單個快照可能需要更長的時間。出於這些原因，一些使用者可能不希望經常進行應用程式靜默。例如，使用者可能希望每週使用應用程式靜默進行備份，而每晚在不進行應用程式靜默的情況下進行備份，但使用一致性組支援，這為組中的所有卷提供了崩潰一致性。

Kubernetes 卷組快照 API

Kubernetes 卷組快照引入了三個新的 API 物件來管理快照

VolumeGroupSnapshot
由 Kubernetes 使用者（或你自己的自動化）建立，用於請求為多個持久卷宣告建立卷組快照。它包含有關卷組快照操作的資訊，例如卷組快照的建立時間戳以及是否已準備好使用。此物件的建立和刪除表示希望建立或刪除叢集資源（一個組快照）。
VolumeGroupSnapshotContent
由快照控制器為動態建立的 VolumeGroupSnapshot 建立。它包含有關卷組快照的資訊，包括卷組快照 ID。此物件表示叢集上已製備的資源（一個組快照）。VolumeGroupSnapshotContent 物件與為其建立的 VolumeGroupSnapshot 以一對一的對映關係繫結。
VolumeGroupSnapshotClass
由叢集管理員建立，用於描述應如何建立卷組快照，包括驅動程式資訊、刪除策略等。

這三個 API kind 被定義為 CustomResourceDefinitions (CRD)。這些 CRD 必須安裝在 Kubernetes 叢集中，以便 CSI 驅動程式支援卷組快照。

我如何使用 Kubernetes 卷組快照？

卷組快照在 external-snapshotter 倉庫中實現。實現卷組快照意味著新增或更改了幾個元件

  • 為 VolumeGroupSnapshot 和兩個支援 API 添加了新的 CustomResourceDefinitions。
  • 卷組快照控制器邏輯已新增到通用快照控制器中。
  • 卷組快照驗證 webhook 邏輯已新增到通用快照驗證 webhook 中。
  • 添加了將 CSI 呼叫傳送到快照器 sidecar 控制器的邏輯。

卷快照控制器、CRD 和驗證 webhook 每個叢集部署一次，而 sidecar 則與每個 CSI 驅動程式捆綁在一起。

因此，將卷快照控制器、CRD 和驗證 webhook 作為叢集外掛部署是有意義的。我強烈建議 Kubernetes 發行商將卷快照控制器、CRD 和驗證 webhook 作為其 Kubernetes 叢集管理過程的一部分進行捆綁和部署（獨立於任何 CSI 驅動程式）。

使用 Kubernetes 建立新的組快照

一旦定義了 VolumeGroupSnapshotClass 物件，並且你擁有想要一起快照的卷，就可以透過建立 VolumeGroupSnapshot 物件來請求新的組快照。

組快照的來源指定了底層組快照是應動態建立，還是應使用預先存在的 VolumeGroupSnapshotContent。

預先存在的 VolumeGroupSnapshotContent 由叢集管理員建立。它包含儲存系統上真實卷組快照的詳細資訊，可供叢集使用者使用。

必須設定組快照來源中的以下成員之一。

  • selector - 一個針對要一起進行快照的 PersistentVolumeClaims 的標籤查詢。此 labelSelector 將用於匹配新增到 PVC 的標籤。
  • volumeGroupSnapshotContentName - 指定代表現有卷組快照的預先存在的 VolumeGroupSnapshotContent 物件的名稱。

在下面的示例中，有兩個 PVC。

NAME        STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
pvc-0       Bound     pvc-a42d7ea2-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s
pvc-1       Bound     pvc-a42d81b8-e3df-11ed-b5ea-0242ac120002   1Gi        RWO           48s

為 PVC 打標籤。

% kubectl label pvc pvc-0 group=myGroup
persistentvolumeclaim/pvc-0 labeled

% kubectl label pvc pvc-1 group=myGroup
persistentvolumeclaim/pvc-1 labeled

對於動態製備，必須設定一個選擇器，以便快照控制器可以找到具有匹配標籤的 PVC 以便一起進行快照。

apiVersion: groupsnapshot.storage.k8s.io/v1alpha1
kind: VolumeGroupSnapshot
metadata:
  name: new-group-snapshot-demo
  namespace: demo-namespace
spec:
  volumeGroupSnapshotClassName: csi-groupSnapclass
  source:
    selector:
      matchLabels:
        group: myGroup

在 VolumeGroupSnapshot 規約中，使用者可以指定 VolumeGroupSnapshotClass，其中包含有關應使用哪個 CSI 驅動程式來建立組快照的資訊。

作為卷組快照建立的一部分，將建立兩個單獨的卷快照。

snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
snapshot-2026811eb9f0787466171fe189c805a22cdb61a326235cd067dc3a1ac0104900-2023-04-26-2.20.4

如何在 Kubernetes 中使用組快照進行恢復

在恢復時，使用者可以請求從作為 VolumeGroupSnapshot 一部分的 VolumeSnapshot 物件建立新的 PersistentVolumeClaim。這將觸發製備一個新卷，該卷預先填充了指定快照中的資料。使用者應重複此過程，直到從組快照中的所有快照建立了所有卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc0-restore
  namespace: demo-namespace
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: snapshot-62abb5db7204ac6e4c1198629fec533f2a5d9d60ea1a25f594de0bf8866c7947-2023-04-26-2.20.4
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

作為儲存供應商，我如何為我的 CSI 驅動程式新增組快照支援？

要實現卷組快照功能，CSI 驅動程式**必須**：

  • 實現一個新的組控制器服務。
  • 實現組控制器 RPC：CreateVolumeGroupSnapshot、DeleteVolumeGroupSnapshot 和 GetVolumeGroupSnapshot。
  • 新增組控制器能力 CREATE_DELETE_GET_VOLUME_GROUP_SNAPSHOT。

有關更多詳細資訊，請參閱 CSI 規範和 Kubernetes-CSI 驅動程式開發者指南。

儘可能使用 CSI 卷驅動程式，它提供了一種建議的機制來部署容器化的 CSI 驅動程式以簡化過程。

作為此推薦部署過程的一部分，Kubernetes 團隊提供了許多 sidecar（輔助）容器，包括已更新以支援卷組快照的 external-snapshotter sidecar 容器。

external-snapshotter 監視 Kubernetes API 伺服器的 VolumeGroupSnapshotContent 物件，並針對 CSI 端點觸發 CreateVolumeGroupSnapshot 和 DeleteVolumeGroupSnapshot 操作。

有哪些限制？

Kubernetes 卷組快照的 alpha 實現有以下限制：

  • 不支援將現有 PVC 恢復到由快照表示的早期狀態（僅支援從快照製備新卷）。
  • 除了儲存系統提供的任何保證（例如崩潰一致性）之外，不提供應用程式一致性保證。有關應用程式一致性的更多討論，請參閱此文件。

下一步是什麼？

根據反饋和採用情況，Kubernetes 團隊計劃在 1.28 或 1.29 版本中將 CSI 組快照實現推向 Beta 階段。我們有興趣支援的一些功能包括卷複製、複製組、卷放置、應用程式靜默、變更塊跟蹤等。

我如何瞭解更多資訊？

我如何參與？

這個專案，就像所有的 Kubernetes 專案一樣，是許多來自不同背景的貢獻者共同努力的結果。我謹代表 SIG Storage，向過去幾個季度為專案達到 Alpha 階段做出貢獻的貢獻者們表示衷心的感謝：

我們還要感謝所有為該專案做出貢獻的其他人，包括幫助審閱 KEP 和 CSI 規範 PR 的其他人。

對於有興趣參與 CSI 或 Kubernetes 儲存系統任何部分的設計和開發的人，請加入 Kubernetes 儲存特別興趣小組 (SIG)。我們隨時歡迎新的貢獻者。

我們還定期舉行資料保護工作組會議。歡迎新成員加入我們的討論。