Kubernetes 的 Volume Snapshot Alpha 簡介

Kubernetes v1.12 引入了對磁碟區快照的 Alpha 支援。此功能允許建立/刪除磁碟區快照，以及使用 Kubernetes API 從快照原生建立新磁碟區的能力。

什麼是快照？

許多儲存系統（例如 Google Cloud Persistent Disks、Amazon Elastic Block Storage 和許多內部部署儲存系統）都提供建立永久磁碟區「快照」的功能。快照代表磁碟區在特定時間點的副本。快照可用於佈建新磁碟區（預先填入快照資料），或將現有磁碟區還原到先前的狀態（由快照代表）。

為什麼要將快照新增到 Kubernetes？

Kubernetes 磁碟區外掛程式系統已經提供強大的抽象化，可自動化區塊和檔案儲存的佈建、連接和掛載。

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

Kubernetes 儲存 SIG 認為快照操作是許多具狀態工作負載的關鍵功能。例如，資料庫管理員可能希望在開始資料庫操作之前快照資料庫磁碟區。

通過在 Kubernetes API 中提供觸發快照操作的標準方法，Kubernetes 使用者現在可以處理像這樣的用例，而無需繞過 Kubernetes API（並手動執行儲存系統特定操作）。

相反地，Kubernetes 使用者現在可以以與叢集無關的方式將快照操作整合到他們的工具和策略中，並且可以放心地知道，無論底層儲存是什麼，它都將適用於任意 Kubernetes 叢集。

此外，這些 Kubernetes 快照原語充當基本構建模組，可解鎖為 Kubernetes 開發進階、企業級儲存管理功能的能力：例如資料保護、資料複寫和資料遷移。

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

Kubernetes 支援三種類型的磁碟區外掛程式：in-tree、Flex 和 CSI。有關詳細資訊，請參閱 Kubernetes 磁碟區外掛程式常見問題解答。

快照僅支援 CSI 驅動程式（不支援 in-tree 或 Flex）。要使用 Kubernetes 快照功能，請確保在您的叢集上部署了實作快照的 CSI 驅動程式。

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

• GCE Persistent Disk CSI 驅動程式
• OpenSDS CSI 驅動程式
• Ceph RBD CSI 驅動程式
• Portworx CSI 驅動程式

其他 驅動程式的快照支援正在等待中，應該很快就會推出。閱讀「Kubernetes 的容器儲存介面 (CSI) 進入 Beta 版」部落格文章，以進一步了解 CSI 以及如何部署 CSI 驅動程式。

Kubernetes 快照 API

與用於管理 Kubernetes 永久磁碟區的 API 類似，Kubernetes 磁碟區快照引入了三個新的 API 物件來管理快照

• VolumeSnapshot
  • 由 Kubernetes 使用者建立，以請求為指定的磁碟區建立快照。它包含有關快照操作的資訊，例如取得快照的時間戳記以及快照是否已準備好使用。
  • 與 PersistentVolumeClaim 物件類似，此物件的建立和刪除代表使用者希望建立或刪除叢集資源（快照）。
• VolumeSnapshotContent
  • 由 CSI 磁碟區驅動程式在成功建立快照後建立。它包含有關快照的資訊，包括快照 ID。
  • 與 PersistentVolume 物件類似，此物件代表叢集上佈建的資源（快照）。
  • 就像 PersistentVolumeClaim 和 PersistentVolume 物件一樣，一旦建立快照，VolumeSnapshotContent 物件就會繫結到為其建立的 VolumeSnapshot（具有一對一映射）。
• VolumeSnapshotClass
  • 由叢集管理員建立，以描述應如何建立快照。包括驅動程式資訊、存取快照的密碼等。

重要的是要注意，與核心 Kubernetes 永久磁碟區物件不同，這些快照物件被定義為 CustomResourceDefinitions (CRD)。Kubernetes 專案正在擺脫在 API 伺服器中預先定義資源類型，並朝著 API 伺服器獨立於 API 物件的模型發展。這允許 API 伺服器可重複用於 Kubernetes 以外的專案，並且消費者（例如 Kubernetes）可以簡單地將他們需要的資源類型安裝為 CRD。

CSI 驅動程式（支援快照）將自動安裝所需的 CRD。Kubernetes 最終使用者只需要驗證支援快照的 CSI 驅動程式是否已部署在其 Kubernetes 叢集上。

除了這些新物件之外，PersistentVolumeClaim 物件還新增了一個新的 DataSource 欄位

type PersistentVolumeClaimSpec struct {
	AccessModes []PersistentVolumeAccessMode
	Selector *metav1.LabelSelector
	Resources ResourceRequirements
	VolumeName string
	StorageClassName *string
	VolumeMode *PersistentVolumeMode
	DataSource *TypedLocalObjectReference
}

這個新的 Alpha 欄位允許建立新磁碟區，並使用來自現有快照的資料自動預先填入。

Kubernetes 快照需求

在使用 Kubernetes 磁碟區快照之前，您必須

• 確保實作快照的 CSI 驅動程式已部署並在您的 Kubernetes 叢集上執行。
• 通過新的 Kubernetes 功能閘道啟用 Kubernetes 磁碟區快照功能（預設為 Alpha 版停用）
  • 在 API 伺服器二進位檔案上設定以下標誌：--feature-gates=VolumeSnapshotDataSource=true

在建立快照之前，您還需要通過建立 VolumeSnapshotClass 物件並將 snapshotter 欄位設定為指向您的 CSI 驅動程式，來指定快照的 CSI 驅動程式資訊。在下面的 VolumeSnapshotClass 範例中，CSI 驅動程式是 com.example.csi-driver。每個快照佈建器至少需要一個 VolumeSnapshotClass 物件。您還可以通過在類別定義中放置註釋 snapshot.storage.kubernetes.io/is-default-class: "true"，為每個單獨的 CSI 驅動程式設定預設的 VolumeSnapshotClass。

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotClass
metadata:
  name: default-snapclass
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
snapshotter: com.example.csi-driver


apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
snapshotter: com.example.csi-driver
parameters:
  fakeSnapshotOption: foo
  csiSnapshotterSecretName: csi-secret
  csiSnapshotterSecretNamespace: csi-namespace

您必須根據 CSI 驅動程式的文件設定任何必需的不透明參數。如上述範例所示，參數 fakeSnapshotOption: foo 和任何參考的密碼都將在快照建立和刪除期間傳遞給 CSI 驅動程式。預設的 CSI external-snapshotter 保留參數金鑰 csiSnapshotterSecretName 和 csiSnapshotterSecretNamespace。如果指定，它會提取密碼並在建立和刪除快照時將其傳遞給 CSI 驅動程式。

最後，在建立快照之前，您必須使用 CSI 驅動程式佈建磁碟區，並使用您要快照的一些資料來填入它（請參閱 CSI 部落格文章，了解如何建立和使用 CSI 磁碟區）。

使用 Kubernetes 建立新的快照

一旦定義了 VolumeSnapshotClass 物件並且您有一個要快照的磁碟區，您就可以通過建立 VolumeSnapshot 物件來建立新的快照。

快照的來源指定要從中建立快照的磁碟區。它有兩個參數

• kind - 必須為 PersistentVolumeClaim
• name - PVC API 物件名稱

要快照的磁碟區的命名空間假定與 VolumeSnapshot 物件的命名空間相同。

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  name: new-snapshot-demo
  namespace: demo-namespace
spec:
  snapshotClassName: csi-snapclass
  source:
    name: mypvc
    kind: PersistentVolumeClaim

在 VolumeSnapshot 規格中，使用者可以指定 VolumeSnapshotClass，其中包含有關應使用哪個 CSI 驅動程式來建立快照的資訊。建立 VolumeSnapshot 物件時，來自 VolumeSnapshotClass 的參數 fakeSnapshotOption: foo 和任何參考的密碼都會通過 CreateSnapshot 呼叫傳遞給 CSI 外掛程式 com.example.csi-driver。

作為回應，CSI 驅動程式會觸發磁碟區的快照，然後自動建立 VolumeSnapshotContent 物件來表示新的快照，並將新的 VolumeSnapshotContent 物件繫結到 VolumeSnapshot，使其準備好使用。如果 CSI 驅動程式無法建立快照並返回錯誤，則快照控制器會在 VolumeSnapshot 物件的狀態中報告錯誤，並且不會重試（這與 Kubernetes 中的其他控制器不同，並且是為了防止在意外時間拍攝快照）。

如果未指定快照類別，則外部快照器將嘗試尋找並為快照設定預設快照類別。預設快照類別中由 snapshotter 指定的 CSI 驅動程式必須與 PVC 儲存類別中由 provisioner 指定的 CSI 驅動程式匹配。

請注意，Kubernetes 快照的 Alpha 版本不提供任何一致性保證。您必須在拍攝快照以確保資料一致性之前準備好您的應用程式（暫停應用程式、凍結檔案系統等）。

您可以通過運行 kubectl describe volumesnapshot 來驗證 VolumeSnapshot 物件是否已建立並與 VolumeSnapshotContent 繫結

• Ready 應在 Status 下設定為 true，以指示此磁碟區快照已準備好使用。
• Creation Time 欄位指示快照實際建立（剪切）的時間。
• Restore Size 欄位指示從快照還原磁碟區時的最小磁碟區大小。
• 規格中的 Snapshot Content Name 欄位指向為此快照建立的 VolumeSnapshotContent 物件。

使用 Kubernetes 匯入現有快照

您始終可以通過手動建立 VolumeSnapshotContent 物件來表示現有快照，從而將現有快照匯入到 Kubernetes。由於 VolumeSnapshotContent 是非命名空間 API 物件，因此只有系統管理員才有權限建立它。一旦建立 VolumeSnapshotContent 物件，使用者就可以建立指向 VolumeSnapshotContent 物件的 VolumeSnapshot 物件。外部快照器控制器將在驗證快照存在且 VolumeSnapshot 和 VolumeSnapshotContent 物件之間的繫結正確後，將快照標記為就緒。繫結後，快照即可在 Kubernetes 中使用。

應使用以下欄位建立 VolumeSnapshotContent 物件，以表示預先佈建的快照

• csiVolumeSnapshotSource - 快照識別資訊。
  • snapshotHandle - 快照的名稱/識別碼。此欄位為必填。
  • driver - 用於處理此磁碟區的 CSI 驅動程式。此欄位為必填。它必須與快照控制器中的 snapshotter 名稱匹配。
  • creationTime 和 restoreSize - 預先佈建的磁碟區不需要這些欄位。外部快照器控制器將在建立後自動更新它們。
• volumeSnapshotRef - 指向此物件應繫結到的 VolumeSnapshot 物件的指標。
  • name 和 namespace - 它指定內容繫結到的 VolumeSnapshot 物件的名稱和命名空間。
  • UID - 預先佈建的磁碟區不需要這些欄位。外部快照器控制器將在繫結後自動更新該欄位。如果使用者指定 UID 欄位，他/她必須確保它與繫結快照的 UID 匹配。如果指定的 UID 與繫結快照的 UID 不匹配，則該內容被視為孤立物件，並且控制器將刪除它及其關聯的快照。
• snapshotClassName - 此欄位為選填。外部快照器控制器將在繫結後自動更新該欄位。

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
metadata:
  name: static-snapshot-content
spec:
  csiVolumeSnapshotSource:
    driver: com.example.csi-driver
    snapshotHandle: snapshotcontent-example-id
  volumeSnapshotRef:
    kind: VolumeSnapshot
    name: static-snapshot-demo
    namespace: demo-namespace

應建立 VolumeSnapshot 物件，以允許使用者使用快照

• snapshotClassName - 磁碟區快照類別的名稱。此欄位為選填。如果設定，快照類別中的 snapshotter 欄位必須與快照控制器的 snapshotter 名稱匹配。如果未設定，快照控制器將嘗試尋找預設快照類別。
• snapshotContentName - 磁碟區快照內容的名稱。預先佈建的磁碟區需要此欄位。

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  name: static-snapshot-demo
  namespace: demo-namespace
spec:
  snapshotClassName: csi-snapclass
  snapshotContentName: static-snapshot-content

一旦建立這些物件，快照控制器將它們繫結在一起，並將 Ready 欄位（在 Status 下）設定為 True，以指示快照已準備好使用。

使用 Kubernetes 從快照佈建新磁碟區

要佈建預先填入來自快照物件的資料的新磁碟區，請使用 PersistentVolumeClaim 中的新 dataSource 欄位。它有三個參數

• name - 代表要用作來源的快照的 VolumeSnapshot 物件的名稱
• kind - 必須為 VolumeSnapshot
• apiGroup - 必須為 snapshot.storage.k8s.io

來源 VolumeSnapshot 物件的命名空間假定與 PersistentVolumeClaim 物件的命名空間相同。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
  Namespace: demo-namespace
spec:
  storageClassName: csi-storageclass
  dataSource:
    name: new-snapshot-demo
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

建立 PersistentVolumeClaim 物件時，它將觸發佈建一個新磁碟區，該磁碟區預先填入了來自指定快照的資料。

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

要實作快照功能，CSI 驅動程式必須新增對額外控制器功能 CREATE_DELETE_SNAPSHOT 和 LIST_SNAPSHOTS 的支援，並實作額外的控制器 RPC：CreateSnapshot、DeleteSnapshot 和 ListSnapshots。有關詳細資訊，請參閱 CSI 規格。

儘管 Kubernetes 在 CSI 磁碟區驅動程式的封裝和部署方面盡可能地 少有規定，但它提供了一種 建議機制，用於在 Kubernetes 上部署任意容器化的 CSI 驅動程式，以簡化容器化 CSI 相容磁碟區驅動程式的部署。

作為此建議部署過程的一部分，Kubernetes 團隊提供了許多 sidecar（輔助）容器，包括一個新的 external-snapshotter sidecar 容器。

external-snapshotter 監視 Kubernetes API 伺服器上的 VolumeSnapshot 和 VolumeSnapshotContent 物件，並針對 CSI 端點觸發 CreateSnapshot 和 DeleteSnapshot 操作。CSI external-provisioner sidecar 容器也已更新，以支援使用新的 dataSource PVC 欄位從快照還原磁碟區。

為了支援快照功能，建議儲存供應商除了外部佈建器外部附加器之外，還部署 external-snapshotter sidecar 容器，以及它們的 CSI 驅動程式在 statefulset 中，如下圖所示。

在此 範例部署 yaml 檔案中，兩個 sidecar 容器、外部佈建器和外部快照器以及 CSI 驅動程式與 statefulset pod 中的 hostpath CSI 外掛程式一起部署。Hostpath CSI 外掛程式是範例外掛程式，不適用於生產環境。

Alpha 版有哪些限制？

Kubernetes 快照的 Alpha 實作具有以下限制：

• 不支援將現有磁碟區還原到由快照代表的較早狀態（Alpha 版僅支援從快照佈建新磁碟區）。
• 不支援從快照「就地還原」現有的 PersistentVolumeClaim：即從快照佈建新磁碟區，但更新現有的 PersistentVolumeClaim 以指向新磁碟區，並有效地使 PVC 顯示為還原到較早的狀態（Alpha 版僅支援通過新的 PV/PVC 使用從快照佈建的新磁碟區）。
• 除了儲存系統提供的任何保證（例如崩潰一致性）之外，沒有快照一致性保證。

接下來是什麼？

根據回饋和採用情況，Kubernetes 團隊計劃在 1.13 或 1.14 版本中將 CSI 快照實作推向 Beta 版。

我如何了解更多資訊？

在此處查看有關快照功能的其他文件：http://k8s.io/docs/concepts/storage/volume-snapshots 和 https://kubernetes-csi.github.io/docs/

我如何參與？

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

除了參與快照功能貢獻者之外

• Xing Yang (xing-yang)
• Jing Xu (jingxu97)
• Huamin Chen (rootfs)
• Tomas Smetana (tsmetana)
• Shiwei Xu (wackxu)

我們非常感謝 Kubernetes 儲存 SIG 和 CSI 社群中所有協助審查專案設計和實作的貢獻者，包括但不限於以下人員

• Saad Ali (saadali)
• Tim Hockin (thockin)
• Jan Šafránek (jsafrane)
• Luis Pabon (lpabon)
• Jordan Liggitt (liggitt)
• David Zhu (davidz627)
• Garth Bushell (garthy)
• Ardalan Kangarlou (kangarlou)
• Seungcheol Ko (sngchlko)
• Michelle Au (msau42)
• Humble Devassy Chirammal (humblec)
• Vladimir Vivien (vladimirvivien)
• John Griffith (j-griffith)
• Bradley Childs (childsb)
• Ben Swartzlander (bswartz)

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

• ←上一篇
下一篇→