Introducing Alpha Support for Volume Snapshotting in Kubernetes 1.12

A young woman using a DSLR camera

3 min read

Kubernetes v1.12 now offers alpha support for volume snapshotting. This will allow users to create or delete volume snapshots, and natively create new volumes from a snapshot using the Kubernetes API.

A snapshot represents a copy of a volume at that particular instant of time. This snapshot can be used to provision a new volume that can be pre-populated with the snapshot data or to restore the existing volume to a previous state.

Importance of adding Snapshots to Kubernetes

The main goal of the Kubernetes team is to create an abstraction layer between distributed systems applications and underlying clusters. The layer will ensure that application deployment requires no “cluster specific” knowledge.

Snapshot operations are a critical functionality for many stateful workloads. For instance, a database administrator may want to snapshot a database volume before starting a database operation. By providing a standard way to trigger snapshot operations in the Kubernetes API, users don’t have to manually execute storage system specific operations around the Kubernetes API. They can instead incorporate snapshot operations in a cluster agnostic way into their tooling and policy assured that it will work against arbitrary Kubernetes clusters regardless of the underlying storage.

These snapshot primitives help to develop advanced, enterprise-grade, storage administration features for Kubernetes which includes data protection, data replication, and data migration.

3 new API objects introduced by Kubernetes Volume Snapshots:

#1 VolumeSnapshot

The creation and deletion of this object depicts if a user wants to create or delete a cluster resource (a snapshot). It is used to request the creation of a snapshot for a specified volume. It gives the user information about snapshot operations like the timestamp at which the snapshot was taken and whether the snapshot is ready to use.

#2 VolumeSnapshotContent

This object is created by the CSI volume driver once a snapshot has been successfully created. It contains information about the snapshot including its ID. This object represents a provisioned resource on the cluster (a snapshot). Once a snapshot is created, the VolumeSnapshotContent object binds to the VolumeSnapshot– with a one to one mapping- for which it was created.

#3 VolumeSnapshotClass

This object created by cluster administrators describes how snapshots should be created. It includes the driver information, how to access the snapshot, etc.

These Snapshot objects are defined as CustomResourceDefinitions (CRDs). End users need to verify if CSI driver that supports snapshots is deployed on their Kubernetes cluster. CSI Drivers that support snapshots will automatically install the required CRDs.

Limitations of the alpha implementation of snapshots

The alpha implementation does not support reverting an existing volume to an earlier state represented by a snapshot
It does not support “in-place restore” of an existing PersistentVolumeClaim from a snapshot. Users can provision a new volume from a snapshot. However, updating an existing PVC to a new volume and reverting it back to an earlier state is not allowed.
No snapshot consistency guarantees given beyond any of those provided by storage system

An example of creating new snapshots and importing existing snapshots is explained well on the Kubernetes Blog. Head over to the team’s Concepts page or Github to find more official documentation of the snapshot feature.