|Status||Min K8s Version||Max K8s Version||external-snapshotter Version||external-provisioner Version|
Many storage systems provide the ability to create a "snapshot" of a persistent volume. A snapshot represents a point-in-time copy of a volume. A snapshot can be used either to provision a new volume (pre-populated with the snapshot data) or to restore the existing volume to a previous state (represented by the snapshot).
Kubernetes CSI currently enables CSI Drivers to expose the following functionality via the Kubernetes API:
- Creation and deletion of volume snapshots via Kubernetes native API.
- Creation of new volumes pre-populated with the data from a snapshot via Kubernetes dynamic volume provisioning.
To implement the snapshot feature, a CSI driver MUST:
- Implement the
CREATE_DELETE_SNAPSHOTand, optionally, the
DeleteSnapshot, and, optionally, the
ListSnapshots, controller RPCs.
For details, see the CSI spec.
The Kubernetes CSI development team maintains the external-snapshotter Kubernetes CSI Sidecar Containers. This sidecar container implements the logic for watching the Kubernetes API for snapshot objects and issuing the appropriate CSI snapshot calls against a CSI endpoint. For more details, see external-snapshotter documentation.
Similar to the API for managing Kubernetes Persistent Volumes, the Kubernetes Volume Snapshots introduce three new API objects for managing snapshots:
VolumeSnapshotClass. See Kubernetes Snapshot documentation for more details.
Unlike the core Kubernetes Persistent Volume objects, these Snapshot objects are defined as Custom Resource Definitions (CRDs). This is because the Kubernetes project is moving away from having resource types pre-defined in the API server. This allows the API server to be reused for projects other than Kubernetes, and consumers (like Kubernetes) simply install the resource types they require as CRDs. Because the Snapshot API types are not built in to Kubernetes, they must be installed prior to use.
The schema definition for the custom resources (CRs) can be found here: https://github.com/kubernetes-csi/external-snapshotter/blob/master/pkg/apis/volumesnapshot/v1alpha1/types.go
In addition to these new CRD objects, a new, alpha
DataSource field has been added to the
PersistentVolumeClaim object. This new field enables dynamic provisioning of new volumes that are automatically pre-populated with data from an existing snapshot.
Since volume snapshot is an alpha feature in Kubernetes v1.12, you need to enable a new alpha feature gate called
VolumeSnapshotDataSource in the Kubernetes master.
Use the following example yaml files to test the snapshot feature.
Create a StorageClass:
kubectl create -f storageclass.yaml
Create a PVC:
kubectl create -f pvc.yaml
Create a VolumeSnapshotClass:
kubectl create -f snapshotclass.yaml
Create a VolumeSnapshot:
kubectl create -f snapshot.yaml
Create a PVC from a VolumeSnapshot:
kuberctl create -f restore.yaml
PersistentVolumeClaim is not bound, the attempt to create a volume snapshot from that
PersistentVolumeClaim will fail. No retries will be attempted. An event will be logged to indicate that the
PersistentVolumeClaim is not bound.
Note that this could happen if the
PersistentVolumeClaim spec and the
VolumeSnapshot spec are in the same YAML file. In this case, when the
VolumeSnapshot object is created, the
PersistentVolumeClaim object is created but volume creation is not complete and therefore the
PersistentVolumeClaim is not yet bound. You must wait until the
PersistentVolumeClaim is bound and then create the snapshot.
See the Drivers for a list of CSI drivers that implement the snapshot feature.