Switch branches/tags
v5.3.0-alpha.1 v5.2.0 v5.1.0 v5.0.1 v5.0.0 v4.0.0 v4.0.0-beta v3.0.0-beta.2 v3.0.0-beta.1 v3.0.0-beta v2.1.0 v2.0.0 v2.0.0-beta v1.10.beta v1.8.0 v1.0.0 standalone-cinder-provisioner-v1.0.0-k8s1.10 rbd-provisioner-v2.1.1-k8s1.11 rbd-provisioner-v2.1.0-k8s1.11 rbd-provisioner-v2.0.1-k8s1.11 rbd-provisioner-v2.0.0-k8s1.11 rbd-provisioner-v1.1.1-k8s1.11 rbd-provisioner-v1.1.0-k8s1.10 rbd-provisioner-v1.0.0-k8s1.10 rbd-provisioner-v0.1.1 rbd-provisioner-v0.1.0 openebs-provisioner-v0.1.0 nfs-provisioner-v2.2.0-k8s1.12 nfs-provisioner-v2.1.0-k8s1.11 nfs-provisioner-v2.0.1-k8s1.11 nfs-provisioner-v2.0.0-k8s1.11 nfs-provisioner-v1.1.0-k8s1.10 nfs-provisioner-v1.0.9 nfs-client-provisioner-v3.1.0-k8s1.11 nfs-client-provisioner-v3.0.2-k8s1.11 nfs-client-provisioner-v3.0.1-k8s1.11 nfs-client-provisioner-v3.0.0-k8s1.11 nfs-client-provisioner-v2.1.2-k8s1.11 nfs-client-provisioner-v2.1.1-k8s1.10 nfs-client-provisioner-v2.1.0-k8s1.10 nfs-client-provisioner-v2.0.1 nfs-client-provisioner-v2.0.0 nfs-client-provisioner-arm-v2.1.1-k8s1.10 nfs-client-provisioner-arm-v2.1.0-k8s1.10 local-volume-provisioner-v2.2.0 local-volume-provisioner-v2.1.0 local-volume-provisioner-v2.0.0 local-volume-provisioner-v1.0.1 local-volume-provisioner-v1.0.0 local-volume-provisioner-bootstrap-v1.0.1 local-volume-provisioner-bootstrap-v1.0.0 kubernetes-1.12.0-beta.1 iscsi-controller-v0.0.3 iscsi-controller-v0.0.2 iscsi-controller-v0.0.1 glusterfs-simple-provisioner-v2.1.0-k8s1.11 glusterfs-simple-provisioner-v2.0.1-k8s1.11 glusterfs-simple-provisioner-v2.0.0-k8s1.11 glusterfs-simple-provisioner-v1.0.0-k8s1.10 glusterfs-simple-provisioner-v0.1.0 glusterblock-provisioner-v2.1.0-k8s1.11 glusterblock-provisioner-v2.0.1-k8s1.11 glusterblock-provisioner-v2.0.0-k8s1.11 glusterblock-provisioner-v1.0.2 glusterblock-provisioner-v1.0.1 glusterblock-provisioner-v1.0.0 glusterblock-provisioner-v0.9.5 glusterblock-provisioner-v0.9.0 flex-provisioner-v2.1.0-k8s1.11 flex-provisioner-v2.0.1-k8s1.11 flex-provisioner-v2.0.0-k8s1.11 flex-provisioner-v1.0.1-k8s1.10 flex-provisioner-v1.0.0-k8s1.10 efs-provisioner-v2.1.0-k8s1.11 efs-provisioner-v2.0.1-k8s1.11 efs-provisioner-v2.0.0-k8s1.11 efs-provisioner-v1.0.0-k8s1.10 efs-provisioner-v0.1.2 efs-provisioner-v0.1.1 efs-provisioner-v0.1.0 cephfs-provisioner-v2.1.0-k8s1.11 cephfs-provisioner-v2.0.1-k8s1.11 cephfs-provisioner-v2.0.0-k8s1.11 cephfs-provisioner-v1.1.0-k8s1.10 cephfs-provisioner-v1.0.0-k8s1.10 cephfs-provisioner-v0.1.2 cephfs-provisioner-v0.1.1 cephfs-provisioner-v0.1.0 1.8.1
Nothing to show
Find file Copy path
165 lines (141 sloc) 6.85 KB

Volume Snapshots in Kubernetes

This document describes current state of Volume Snapshot support in Kubernetes provided by external controller and provisioner. Familiarity with Persistent Volumes, Persistent Volume Claims and Dynamic Provisioning is recommended.


Many storage systems provide the ability to create "snapshots" of a persistent volume to protect against data loss. The external snapshot controller and provisioner provide means to use the feature in Kubernetes cluster and handle the volume snapshots through Kubernetes API.


  • Create snapshot of a PersistentVolume bound to a PersistentVolumeClaim
  • List existing VolumeSnapshots
  • Delete existing VolumeSnapshot
  • Create a new PersistentVolume from an existing VolumeSnapshot
  • Supported PersistentVolume types:
    • Amazon EBS
    • GCE PD
    • HostPath
    • OpenStack Cinder
    • GlusterFS

Lifecycle of a Volume Snapshot and Volume Snapshot Data


Prerequisites for using the snapshotting features are described in sections "Persistent Volume Claim and Persistent Volume" and "Snapshot Promoter".

Persistent Volume Claim and Persistent Volume

The user already created a Persistent Volume Claim that is bound to a Persistent Volume. The Persistent Volume type must be one of the snaphot supported Persistent Volume types.

Snapshot Promoter

An admin created a Storage Class like the one shown below:

kind: StorageClass
  name: snapshot-promoter

Such Storage Class is necessary for restoring a Persistent Volume from already created Volume Snapshot and Volume Snapshot Data.

Creating Snapshot

Each VolumeSnapshot contains a spec and status, which is the specification and status of the Volume Snapshot.

kind: VolumeSnapshot
  name: snapshot-demo
  persistentVolumeClaimName: ebs-pvc
  • persistentVolumeClaimName: name of the Persistent Volume Claim that is bound to a Persistent Volume. This particular Persistent Volume will be snapshotted.

Volume Snapshot Data is automatically created based on the Volume Snapshot. Relationship between Volume Snapshot and Volume Snapshot Data is similar to the relationship between Persistent Volume Claim and Persistent Volume.

Depending on the Persistent Volume type the operation might go through several phases which are reflected by the Volume Snapshot status:

  1. The new Volume Snapshot object is created.
  2. The controller starts the snapshot operation: the snapshotted Persistent Volume might need to be frozen and the applications paused.
  3. The storage system finishes creating the snapshot (the snapshot is "cut") and the snapshotted Persistent Volume might return to normal operation. The snapshot itself is not ready yet. The last status condition is of Pending type with status value "True". A new VolumeSnapshotData object is created to represent the actual snapshot.
  4. The newly created snapshot is completed and ready to use. The last status condition is of Ready type with status value "True"


  • It is the user's responsibility to ensure the data consistency (stop the pod/application, flush caches, freeze the filesystem, ...).
  • In case of error in any of the steps the Volume Snapshot status is appended with an Error condition.

A Volume Snapshot status can be displayed as shown below:

$ kubectl get volumesnapshot -o yaml
  kind: VolumeSnapshot
    clusterName: ""
    creationTimestamp: 2017-09-19T13:58:28Z
    generation: 0
      Timestamp: "1505829508178510973"
    name: snapshot-demo
    namespace: default
    resourceVersion: "780"
    selfLink: /apis/
    uid: 9cc5da57-9d42-11e7-9b25-90b11c132b3f
    persistentVolumeClaimName: ebs-pvc
    snapshotDataName: k8s-volume-snapshot-9cc8813e-9d42-11e7-8bed-90b11c132b3f
    - lastTransitionTime: null
      message: Snapshot created successfully
      reason: ""
      status: "True"
      type: Ready
    creationTimestamp: null

Restoring Snapshot

In order to restore a Persistent Volume from a Volume Snapshot a user creates the following Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
  name: snapshot-pv-provisioning-demo
  annotations: snapshot-demo
  storageClassName: snapshot-promoter
  • annotations: the name of the Volume Snapshot that will be restored.
  • storageClassName: Storage Class created by admin for restoring Volume Snapshots.

A Persistent Volume will be created and bound to the Persistent Volume Claim. The process may take several minutes depending on the Persistent Volume Type.

Deleting Snapshot

A Volume Snapshot snapshot-demo can be deleted as shown below:

$ kubectl delete volumesnapshot/snapshot-demo

The Volume Snapshot Data that are bound to the Volume Snapshot are also automatically deleted.

Managing Snapshot Users

Depending on the cluster configuration it might be necessary to allow non-admin users to manipulate the VolumeSnapshot objects on the API server. This might be done by creating a ClusterRole bound to a particular user or group.

Assume the user 'alice' needs to be able to work with snapshots in the cluster. The cluster admin needs to define a new ClusterRole.

apiVersion: v1
kind: ClusterRole
  name: volumesnapshot-admin
- apiGroups:
  - ""
  attributeRestrictions: null
  - volumesnapshots
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch

Now the cluster role has to be bound to the user 'alice' by creating a ClusterRole binding object.

kind: ClusterRoleBinding
  name: volumesnapsot-admin
  kind: ClusterRole
  name: volumesnapshot-admin
- kind: User
  name: alice

This is only an example of API access configuration. Note the VolumeSnapshot objects behave just like any other Kubernetes API objects. Please refer to the API access control documentation for complete guide on managing the API RBAC.