This document describes the current state of
VolumeSnapshots in Kubernetes. Familiarity with persistent volumes is suggested.
Similar to how API resources
PersistentVolumeClaim are used to provision volumes for users and administrators,
VolumeSnapshot API resources are provided to create volume snapshots for users and administrators.
VolumeSnapshotContent is a snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a PersistentVolume is a cluster resource.
VolumeSnapshot is a request for snapshot of a volume by a user. It is similar to a PersistentVolumeClaim.
VolumeSnapshots allow a user to consume abstract storage resources, cluster administrators
need to be able to offer a variety of
VolumeSnapshotContents without exposing
users to the details of how those volume snapshots should be provisioned. For these needs
there is the
Users need to be aware of the following when using this feature:
VolumeSnapshotClassare CRDs, not part of the core API.
VolumeSnapshotsupport is only available for CSI drivers.
external-snapshotter. It watches
VolumeSnapshotobjects and triggers
DeleteSnapshotoperations against a CSI endpoint.
VolumeSnapshotContents are resources in the cluster.
VolumeSnapshots are requests for those resources. The interaction between
VolumeSnapshots follow this lifecycle:
There are two ways snapshots may be provisioned: statically or dynamically.
A cluster administrator creates a number of
VolumeSnapshotContents. They carry the details of the real storage which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
When none of the static
VolumeSnapshotContents the administrator created matches a user’s
the cluster may try to dynamically provision a volume snapshot specially for the
This provisioning is based on
VolumeSnapshot must request a
volume snapshot class and
the administrator must have created and configured that class in order for dynamic
provisioning to occur.
A user creates, or has already created in the case of dynamic provisioning, a
VolumeSnapshot with a specific amount of storage requested and with certain access modes. A control loop watches for new VolumeSnapshots, finds a matching VolumeSnapshotContent (if possible), and binds them together. If a VolumeSnapshotContent was dynamically provisioned for a new VolumeSnapshot, the loop will always bind that VolumeSnapshotContent to the VolumeSnapshot. Once bound,
VolumeSnapshot binds are exclusive, regardless of how they were bound. A VolumeSnapshot to VolumeSnapshotContent binding is a one-to-one mapping.
VolumeSnapshots will remain unbound indefinitely if a matching VolumeSnapshotContent does not exist. VolumeSnapshots will be bound as matching VolumeSnapshotContents become available.
The purpose of the Persistent Volume Claim Object in Use Protection feature is to ensure that in-use PVC API objects are not removed from the system (as this may result in data loss).
If a PVC is in active use by a snapshot as a source to create the snapshot, the PVC is in-use. If a user deletes a PVC API object in active use as a snapshot source, the PVC object is not removed immediately. Instead, removal of the PVC object is postponed until the PVC is no longer actively used by any snapshots. A PVC is no longer used as a snapshot source when
ReadyToUse of the snapshot
Deletion removes both the
VolumeSnapshotContent object from the Kubernetes API, as well as the associated storage asset in the external infrastructure.
Each VolumeSnapshotContent contains a spec, which is the specification of the volume snapshot.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshotContent metadata: name: new-snapshot-content-test spec: snapshotClassName: csi-hostpath-snapclass source: name: pvc-test kind: PersistentVolumeClaim volumeSnapshotSource: csiVolumeSnapshotSource: creationTime: 1535478900692119403 driver: csi-hostpath restoreSize: 10Gi snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002
A VolumeSnapshotContent can have a class, which is specified by setting the
snapshotClassName attribute to the name of a
A VolumeSnapshotContent of a particular class can only be bound to VolumeSnapshots requesting
that class. A VolumeSnapshotContent with no
snapshotClassName has no class and can only be bound
to VolumeSnapshots that request no particular class.
Each VolumeSnapshot contains a spec and a status, which is the specification and status of the volume snapshot.
apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot metadata: name: new-snapshot-test spec: snapshotClassName: csi-hostpath-snapclass source: name: pvc-test kind: PersistentVolumeClaim
A volume snapshot can request a particular class by specifying the name of a
using the attribute
Only VolumeSnapshotContents of the requested class, ones with the same
as the VolumeSnapshot, can be bound to the VolumeSnapshot.
You can provision a new volume, pre-populated with data from a snapshot, by using
the dataSource field in the
For more details, see Volume Snapshot and Restore Volume from Snapshot.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.