What’s New in Kubernetes v1.17 Beta Volume Snapshots? A Complete Guide

What Is a Volume Snapshot?

Many storage systems such as Google Cloud Persistent Disk, Amazon EBS, and various on‑premises solutions provide the ability to create a point‑in‑time copy of a persistent volume, called a snapshot. Snapshots can be used to provision new volumes pre‑filled with snapshot data or to restore an existing volume to a previous state.

Why Add Volume Snapshots to Kubernetes?

Kubernetes' volume plugin system abstracts block and file storage, enabling automatic provisioning, attachment, and mounting. Snapshots support the portability goal of Kubernetes by providing a standard API‑driven way to capture and restore stateful workloads (e.g., databases) without requiring storage‑specific commands.

New Features in the Beta Release

Snapshot API is enabled by default on standard Kubernetes deployments.

Improved VolumeSnapshot API.

CSI external‑snapshot sidecar split into a generic snapshot controller and a CSI‑specific sidecar.

DeletionPolicy is added as a comment on VolumeSnapshotContent.

A new finalizer prevents deletion of a VolumeSnapshotContent while it is bound.

Requirements for Using Volume Snapshots

Kubernetes VolumeSnapshot CRDs.

Snapshot controller.

CSI driver that supports the snapshot beta version.

Supported CSI Drivers

Only CSI drivers support snapshots. The following drivers have been updated to support the beta version at the time of writing:

GCE Persistent Disk CSI driver

Portworx CSI driver

NetApp Trident CSI driver

Beta API Changes

The transition from alpha to beta introduced several non‑backward‑compatible changes to make the API clearer and easier to use.

DeletionPolicy is now a required field in VolumeSnapshotClass and VolumeSnapshotContent.

VolumeSnapshotSpec adds a mandatory Source field, which can be either PersistentVolumeClaimName (dynamic snapshot) or VolumeSnapshotContentName (pre‑set snapshot).

VolumeSnapshotContentSpec also adds a mandatory Source field, which can be VolumeHandle or SnapshotHandle.

VolumeSnapshotStatus now includes BoundVolumeSnapshotContentName to indicate the bound content object.

VolumeSnapshotContent now contains a Status with SnapshotHandle indicating the underlying storage snapshot.

type VolumeSnapshot struct {
    metav1.TypeMeta
    metav1.ObjectMeta
    Spec   VolumeSnapshotSpec
    Status *VolumeSnapshotStatus
}

type VolumeSnapshotSpec struct {
    Source                 VolumeSnapshotSource
    VolumeSnapshotClassName *string
}

type VolumeSnapshotSource struct {
    // +optional
    PersistentVolumeClaimName *string
    // +optional
    VolumeSnapshotContentName *string
}

type VolumeSnapshotStatus struct {
    BoundVolumeSnapshotContentName *string
    CreationTime                    *metav1.Time
    ReadyToUse                      *bool
    RestoreSize                     *resource.Quantity
    Error                           *VolumeSnapshotError
}

Deploying Snapshot Support on a Cluster

In addition to the CRDs, a generic snapshot controller must be deployed. It is recommended that Kubernetes distributors bundle the controller and CRDs with the cluster.

Install beta Snapshot CRDs: kubectl create -f config/crd (GitHub: https://github.com/kubernetes-csi/external-snapshotter/tree/master/config/crd)

Install the generic snapshot controller: kubectl create -f deploy/kubernetes/snapshot-controller (GitHub: https://github.com/kubernetes-csi/external-snapshotter/tree/master/deploy/kubernetes/snapshot-controller)

Install a CSI driver that supports snapshots following the vendor's instructions.

Using Volume Snapshots

Assuming all required components are running, create a VolumeSnapshotClass to tell Kubernetes which CSI driver can handle snapshots, then create a VolumeSnapshot object.

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotClass
metadata:
  name: test-snapclass
driver: testdriver.csi.k8s.io
deletionPolicy: Delete
parameters:
  csi.storage.k8s.io/snapshotter-secret-name: mysecret
  csi.storage.k8s.io/snapshotter-secret-namespace: mysecretnamespace

Creating a VolumeSnapshot triggers the generic controller to create a corresponding VolumeSnapshotContent, which then calls the CSI driver to create the actual storage snapshot.

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: test-snapshot
spec:
  volumeSnapshotClassName: test-snapclass
  source:
    persistentVolumeClaimName: test-pvc

Restoring from a Snapshot

To create a new volume pre‑filled with snapshot data, use the dataSource field of a PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-restore
  namespace: demo-namespace
spec:
  storageClassName: testdriver.csi.k8s.io
  dataSource:
    name: test-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Importing Existing Snapshots

Cluster administrators can manually create a VolumeSnapshotContent object that references an external snapshot, then bind a VolumeSnapshot to it.

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshotContent
metadata:
  name: manually-created-snapshot-content
spec:
  deletionPolicy: Delete
  driver: testdriver.csi.k8s.io
  source:
    snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
  volumeSnapshotRef:
    name: test-snapshot
    namespace: default

Limitations of the Beta Implementation

Existing volumes cannot be reverted to an earlier state; the beta only supports creating new volumes from snapshots.

Consistency guarantees are limited to those provided by the underlying storage system.

Future Plans

Based on community feedback, the snapshot implementation is expected to graduate to GA in Kubernetes 1.18 or 1.19, with additional features such as consistency groups, application‑consistent snapshots, workload quiescence, in‑place restore, and volume backup.