kube.netes 集群管理員如何創建 VolumeSnapshotContents？

Question

Kube.netes 卷快照概念文檔提到可以預先配置卷快照；

集群管理員創建了許多 VolumeSnapshotContents。 它們攜帶存儲系統上真實卷快照的詳細信息，可供集群用戶使用。 它們存在於 Kube.netes API 中，可供消費。

這是怎么做到的？

一些背景：我正在嘗試從 EBS 快照創建 k8s 卷快照 (VS)。 我想使用 VS 恢復使用 Bitnami helm chart 部署的 mongodb 副本集。

我嘗試使用此方法創建 VS 而無需創建 VolumeSnapshotContents：

1. 創建 EBS 快照。
2. 從快照創建 EBS 卷。
3. 從 EBS 卷創建持久卷 (PV)。
4. 創建持久卷聲明 (PVC) 以綁定到 PV。
5. 通過使用 PVC 創建 pod 將 PVC 綁定到 PV。
6. 從 PVC 創建 VolumeSnapshot (VS)。

最后一步失敗並出現此錯誤：

Events:
  Type     Reason                         Age   From                 Message
  ----     ------                         ----  ----                 -------
  Warning  SnapshotContentCreationFailed  21s   snapshot-controller  Failed to create snapshot content with error cannot find CSI PersistentVolumeSource for volume mongo-with-data

這是因為在步驟 3 中創建的 PV 將其作為其來源：

Source:
    Type:       AWSElasticBlockStore (a Persistent Disk resource in AWS)
    VolumeID:   vol-049483f660a6a66cf
    FSType:
    Partition:  0
    ReadOnly:   false

而通過使用 PVC 創建 pod （在幕后）創建的 PV 具有此來源

Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            ebs.csi.aws.com
    FSType:            ext4
    VolumeHandle:      vol-05b14044113937bee
    ReadOnly:          false
    VolumeAttributes:      storage.kubernetes.io/csiProvisionerIdentity=1625656807749-8081-ebs.csi.aws.com

兩個 PV 具有相同的StorageClass 。

Answer 1

這是怎么做到的？

底層驅動程序決定了這一點。 該驅動程序可以是 CSI 驅動程序或傳統的樹驅動程序。 大多數涉及兩個不同驅動程序的場景（即使兩者都是 CSI，但它們是不同的 CSI 驅動程序）不受支持，因為許多資源（如VolumeSnapshotContent ）本質上是不透明的。 這就是第 6 步失敗的原因。

我對整個工作流程感到有點迷茫，我不確定集群是如何設置的，CSI 驅動程序和樹驅動程序都試圖使用相同的存儲 class...但是，您可以逐步制作 CSI 類型的 PV 3. 你關注過這個樣本嗎？

我還認為，通過直接利用 EBS 卷而不是創建中間 PV，可以簡化整個過程。 我沒有要確認的 AWS 帳戶，但 AWS 似乎為您提供了 EBS 快照 ID，您可以根據此示例直接在VolumeSnapshotContent中引用它。

Answer 2

兩個 PV 具有相同的StorageClass是沒有意義的，因為 StorageClass 的 provisioner 參數決定了源類型。

對於以下存儲 class 配置，源類型是“AWSElasticBlockStore（AWS 中的永久磁盤資源）”，因為provisioner: kube.netes.io/aws-ebs

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4

對於以下存儲 class 配置，源類型為“CSI（容器存儲接口 (CSI) 卷源）”，因為provisioner: ebs.csi.aws.com

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4

如果你的兩個pvc都是使用相同的StorageClass制作的，我認為有人在制作兩個 pvc 之間更新了provisioner參數，因為StorageClass的變化不會改變已經創建的 pvcs 回顧