kube.netes 集群管理员如何创建 VolumeSnapshotContents？

Question

The Kube.netes Volume Snapshots concepts documentation mentions Volume Snapshots can be pre-provisioned;

A cluster administrator creates a number of VolumeSnapshotContents. They carry the details of the real volume snapshot on the storage system which is available for use by cluster users. They exist in the Kube.netes API and are available for consumption.

How is this done?

Some background: I'm trying to create k8s Volume Snapshots (VS) from EBS snapshots. I want to use the VS to restore a mongodb replicaset that is deployed using the Bitnami helm chart.

I've tried creating the VS without creating a VolumeSnapshotContents using this method:

1. Create EBS snapshot.
2. Create EBS volume from snapshot.
3. Create Persistent Volume (PV) from EBS volume.
4. Create Persistent Volume Claim (PVC) to bind to PV.
5. Bind PVC to PV by creating pod with PVC.
6. Create VolumeSnapshot (VS) from PVC.

The last step fails with this error:

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

This is because the PV created in step 3 has this as its Source:

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

while a PV created (behind the scenes) through the creation of a pod using a PVC has this Source

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

Both PVs have the same StorageClass .

Answer 1

How is this done?

The underlying driver determines that. That driver can be a CSI driver or traditional in tree driver. Most scenarios that involve two different driver (even if both are CSI but they are different CSI drivers) is not supported as many resources (like VolumeSnapshotContent ) are opaque by nature. And that is why step 6 fails.

I feel a little bit lost about the whole workflow and I'm not sure how the cluster is set up that both CSI driver and in tree driver are trying to use same storage class... But, you can make CSI typed PV in step 3. Have you followed this sample ?

I also think the whole process can be made easier by directly leveraging EBS volume instead of creating intermediate PVs. I don't have an AWS account to confirm, but it seems AWS provides you EBS snapshot ID and you can reference it directly in VolumeSnapshotContent , based on this sample .

Answer 2

It doesn't make sense that both PVs have the same StorageClass since the StorageClass's provisioner parameter determines the source type.

For the following storage class config, the source type is "AWSElasticBlockStore (a Persistent Disk resource in AWS)" since the 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

And for the following storage class config, the source type is "CSI (a Container Storage Interface (CSI) volume source)" since the 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

If both of your pvc s were made using the same StorageClass I think that someone updated the provisioner parameter in between making both pvcs, since the change in the StorageClass will not change the already created pvcs in retrospective