Defining a default VolumeSnapshotClass for dynamic provisioning

Question

Pulumi · Accepted Answer

In Kubernetes, a `VolumeSnapshotClass` is a way to define different "classes" for creating `VolumeSnapshot` objects, which are snapshots of your persistent volumes. This is comparable to defining `StorageClass` resources for persistent volumes. When you create a `VolumeSnapshot`, you must specify which `VolumeSnapshotClass` to use, just like you would specify a `StorageClass` for a `PersistentVolumeClaim`.

Dynamic provisioning in Kubernetes allows storage volumes to be created on-demand. The default `StorageClass` is used for dynamic provisioning when a `PersistentVolumeClaim` does not explicitly specify a storage class. Similarly, a default `VolumeSnapshotClass` can be implicitly used when `VolumeSnapshot` resources do not specify one.

As of my knowledge cutoff in 2023, there is no built-in Kubernetes feature that specifies a default `VolumeSnapshotClass`. However, you can simulate this by creating a single `VolumeSnapshotClass` and making sure it's the only one available or by manually annotating it as default and ensuring your snapshot creation logic uses it when no other class is specified.

Below is a Pulumi program in TypeScript that defines a `VolumeSnapshotClass` in Kubernetes using Pulumi's Kubernetes provider. We will define the `VolumeSnapshotClass` with specific parameters, but keep in mind that marking it as "default" in the Kubernetes cluster involves a convention rather than an explicit field in the resource manifest.

```typescript
import * as kubernetes from "@pulumi/kubernetes";

// Define a new VolumeSnapshotClass to be used for dynamic provisioning.
const snapshotClass = new kubernetes.storage.v1.VolumeSnapshotClass("my-snapshot-class", {
    metadata: {
        // Annotations can be used to tag this snapshot class as the default
        // in your cluster. This is not a standard Kubernetes practice and is
        // dependent on your snapshot provisioning logic to respect.
        annotations: {
            "snapshot.storage.kubernetes.io/is-default-class": "true",
        },
    },
    driver: "driver-name", // Replace with your storage driver
    // `deletionPolicy` determines what happens to the snapshot when the VolumeSnapshot object is deleted.
    // "Delete" will delete the VolumeSnapshotContent which in turn will delete the snapshot on the storage system.
    // "Retain" will keep the physical snapshot and its data around until manually deleted.
    deletionPolicy: "Delete",
    // Any other parameters set by the storage driver can be included here
});

// Export the name of the snapshot class
export const snapshotClassName = snapshotClass.metadata.name;
```

In the code:

- We import the Pulumi Kubernetes package to interact with Kubernetes resources.
- We create a `VolumeSnapshotClass` with the `.storage.k8s.io/v1` API version and a `deletionPolicy`.
- We use an annotation `"snapshot.storage.kubernetes.io/is-default-class": "true"` to indicate this is the default class. Note that this is not an official Kubernetes feature, but rather a convention that you may decide to follow in your own automation and provisioning scripts.
- The `driver` property should reflect the name of the storage driver used for managing storage snapshots. This will depend on your cloud provider or storage system (e.g., `ebs.csi.aws.com` for AWS EBS, or `csi-snapshots` for a custom CSI driver).
- The `deletionPolicy` is set to "Delete", specifying that the snapshot is deleted when the `VolumeSnapshot` object is deleted. You can change it to "Retain" if you want to keep snapshots after the `VolumeSnapshot` object is removed.

Remember to replace `"driver-name"` with the actual driver's name for your storage system.

The above program can be run using the Pulumi CLI after setting up the Pulumi project and installing the necessary dependencies with npm or yarn. When you apply this Pulumi code, the declared resources will be created in your Kubernetes cluster.