K8S 1.12大特性最快最深度解析：Kubernetes CSI Snapshot（上）

前言

CSI snapshot 是由華爲在 Kubernetes 社區主導開發的存儲特性，在 K8S 1.12進入Alpha階段。接下來，咱們將分爲上下兩篇，分別介紹snapshot的建立刪除等API以及從snapshot還原數據卷，同時，咱們將使用CSI hostpath 插件來演示，如何使用這兩種特性。

Kubernetes CSI Snapshot（上篇）

背景

許多存儲系統提供了建立存儲卷「快照」（snapshot）的能力，以防止數據丟失。快照能夠替代傳統的備份系統來備份和還原主要數據和關鍵數據。快照可以快速備份數據（例如，建立GCE PD快照僅須要幾分之一秒）， 並提供快速恢復時間目標（RTO）和恢復點目標（RPO）。快照還可用於數據複製、分發和遷移。 早在kubernetes 1.8版本中，卷快照系統原型已經發布,其實現位於 external-storage(github.com/kubernetes-…)庫中。該原型基於 CRD 實現，提供了外部 controller 和 provisioner 兩個二進制，支持 GCE PD，AWS EBS，OpenStack Cinder，GlusterFS 和 Kubernetes hostPath 等存儲卷。

Kubernetes 的社區存儲趨勢是採用 CSI 實現存儲插件，本文添加對 CSI 存儲插件的快照支持。Kubernetes 的趨勢是保持核心 API 儘量小，所以咱們採用 CRD 實現，並添加一個外部快照控制器來處理卷快照，external provisioner 也會升級以支持從快照建立 volume，CSI snapshot規範詳情能夠在https://github.com/container-storage-interface/spec/pull/224 查看。

目標

對於 Kubernetes 中的第一個快照支持版本，咱們僅支持 CSI 卷插件按需建立快照。

• 目標1：實現標準化的快照操做，支持建立，列出和刪除快照等 REST API。目前，API 將使用 CRD（CustomResourceDefinitions）實現。
• 目標2：實現CSI卷快照支持。external-snapshotter 將與 CSI 卷插件的其餘外部組件（例如，external-attacher, external-provisioner）一塊兒部署。
• 目標3：提供一種從快照建立新存儲卷和還原現有卷的便捷方法。 如下目標本階段將不會實現，但將在稍後階段考慮。
• 目標4：經過提供 pre/post 快照鉤子來凍結/解凍應用程序和/或卸載/掛載文件系統，從而提供應用程序一致性快照。
• 目標5：提供更高級別的管理，例如備份和還原 pod 和 statefulSet，以及建立一致性的快照組。

詳細設計

在此提案中，卷快照被視爲 Kubernetes 管理的另外一種存儲資源。 所以，快照 API 和控制器遵循現有卷管理的設計模式。

• VolumeSnapshot
• VolumeSnapshotContent
• VolumeSnapshotClass

三個 API，它們與 PersistentVolumeClaim 和 PersistentVolume 以及 storageClass 的結構相似。外部快照控制器的功能相似於 in-tree 的 PV 控制器。同時建議在 PersistentVolumeClaim（PVC）API 中添加新的數據源結構，以支持從快照還原數據卷。 如下部分將詳細介紹 API 和控制器設計。

Snapshot API設計

VolumeSnapshot 和 VolumeSnapshotContent API 是在 PersistentVolumeClaim 和 PersistentVolume 以後建模設計的。 在第一個版本中，VolumeSnapshot 生命週期徹底獨立於其來源（PVC）。 刪除 PVC / PV 時，相應的 VolumeSnapshot 和 VolumeSnapshotContent 對象將繼續存在。 可是，對於某些卷插件，快照依賴於其存儲卷。 在將來的版本中，咱們計劃進行完整的生命週期管理，以便更好地處理快照與其卷之間的關係。（例如，添加finalizer，當有快照依賴於存儲卷時，可防止存儲卷被刪除）。

VolumeSnapshot對象

VolumeSnapshotContent對象

VolumeSnapshotClass對象

咱們將添加新的 API 對象 VolumeSnapshotClass，而不是複用現有的 StorageClass，以免在 snapshot 和 volume 之間混合參數。每一個 CSI 卷插件均可以擁有本身的默認 VolumeSnapshotClass。若是未提供 VolumeSnapshotClass，則將使用默認值。VolumeSnapshotClass 將爲快照添加新的參數。

Snapshot Controller 設計要點

以下圖所示，CSI 快照控制器體系結構由 external-snapshotter（外部快照器）組成，external-snapshotter 經過套接字與 out-of-tree CSI 卷插件進行通訊（默認狀況下爲/ run / csi / socket，可由 -csi-address 配置）。external-snapshotter 是 Kubernetes 實現容器存儲接口（CSI）的一部分。 它是一個外部控制器，用於監視 VolumeSnapshot 和 VolumeSnapshotContent 對象並建立/刪除快照。

• 一般 external-snapshotter 使用 ControllerGetCapabilities 來驗證 CSI 驅動程序是否支持 CREATE_DELETE_SNAPSHOT 調用。
• external-snapshotter 負責建立/刪除快照及綁定 VolumeSnapshot 和 VolumeSnapshotContent 對象。它遵循 kubernetes 控制器模式並使用 informer 來監視 VolumeSnapshot 和 VolumeSnapshotContent 建立/更新/刪除事件。經過 Snapshotter == <CSI 卷插件名字>過濾掉不符合的 VolumeSnapshot 實例，並使用具備指數退避的工做隊列處理這些事件。
• 對於動態建立的快照，它應該關聯某個 VolumeSnapshotClass。用戶能夠在 VolumeSnapshot API 對象中顯式指定 VolumeSnapshotClass。若是用戶未指定 VolumeSnapshotClass，則將使用 admin 建立的默認 VolumeSnapshotClass。這和使用默認的 StorageClass 來配置 PersistentVolumeClaim 類似。
• 對於靜態綁定快照，user/admin 必須爲 VolumeSnapshot 和 VolumeSnapshotContent 正確指定雙向指針，以便控制器知道如何綁定它們。不然，若是 VolumeSnapshot 指向不存在的 VolumeSnapshotContent，或者是 VolumeSnapshotContent 並未指向 VolumeSnapshot，則將 VolumeSnapshot 設置爲錯誤狀態。
• 針對每個 CSI 卷插件，external-snapshotter、external-attacher和external-provisioner 運行在同一個 sidecar 中。
• 在當前設計中，當存儲系統沒法建立快照時，將不會在控制器中執行重試。這是由於當快照建立的時間很重要時，用戶可能不想在獲取一致性快照或計劃快照時重試。在未來的版本中，將添加 maxRetries 標誌或重試終止時間戳，以容許用戶控制是否須要重試。

本篇文章主要介紹了 snapshot 的 API 對象，以及 external-snapshotter 的架構設計和實現原理，下篇文章，咱們將會介紹從snapshot 還原數據卷，以及演示如何使用這兩種特性，敬請期待。