Kubernetes 1.36: Volume Group Snapshots Now Generally Available

By ⚡ min read

Since their introduction as an alpha feature in Kubernetes v1.27, volume group snapshots have progressed through beta stages (v1.32 and v1.34) and are now reaching General Availability (GA) with the v1.36 release. This milestone brings a production-ready mechanism for creating crash-consistent snapshots across multiple volumes, enabling robust data protection for stateful applications that rely on storage consistency.

What Are Volume Group Snapshots?

Volume group snapshots allow you to capture a point-in-time copy of multiple volumes simultaneously, ensuring write-order consistency. Unlike individual volume snapshots, which may capture data at different moments, group snapshots guarantee that all volumes in the group reflect the same application state. This feature is especially critical for workloads such as databases, message queues, or logging systems where data and logs reside on separate volumes.

Kubernetes 1.36: Volume Group Snapshots Now Generally Available

The implementation leverages a set of extension APIs in Kubernetes. To create a group snapshot, you define a VolumeGroupSnapshot object that references multiple PersistentVolumeClaims (PVCs) using a label selector. The storage backend then takes a coordinated snapshot of the selected volumes, which can later be restored to new PVCs or used to roll back existing ones to the captured state.

Why Volume Group Snapshots Matter for Multi-Volume Applications

Kubernetes already offers the VolumeSnapshot API for protecting individual persistent volumes. However, many enterprise applications span multiple volumes—for instance, a content management system might store database files in one volume and transaction logs in another. Snapshotting these volumes independently at different times would lead to an inconsistent recovery point, potentially corrupting the entire application.

Traditional workarounds involve quiescing the application (pausing all I/O) and taking snapshots sequentially. This process is error-prone, time-consuming, and often impractical for high-availability environments. Volume group snapshots eliminate this complexity by providing a crash-consistent snapshot without requiring application quiescence. The storage system handles the coordination, delivering a single, consistent recovery point across all volumes in the group.

How Volume Group Snapshots Work in Kubernetes

The group snapshot feature relies on three core API objects working together:

The Three API Objects

VolumeGroupSnapshot – Created by a user or automated system to request a group snapshot. It specifies which PVCs to include (via a label selector) and references a VolumeGroupSnapshotClass.
VolumeGroupSnapshotContent – A cluster resource that represents the actual snapshot taken by the storage backend. It is created by the snapshot controller and bound to the corresponding VolumeGroupSnapshot upon successful creation.
VolumeGroupSnapshotClass – Defines the storage driver and configuration parameters (e.g., snapshot retention policy, deletion policy) for group snapshots. This class is referenced by the VolumeGroupSnapshot object.

Behind the scenes, Kubernetes uses a label selector to group PVCs into a logical set. The storage driver (CSI) then takes a crash-consistent snapshot of all selected volumes at the same instant. The resulting VolumeGroupSnapshotContent can be used to restore the entire group to new volumes—ideal for cloning environments or disaster recovery.

Note: This feature is only supported for CSI volume drivers that implement the GroupSnapshot capability.

Getting Started with Volume Group Snapshots

To use volume group snapshots in Kubernetes v1.36, follow these steps:

Ensure your CSI driver supports group snapshots. Check the driver's documentation for a list of compatible versions and required parameters.
Install the snapshot controller and CRDs. The volume-group-snapshot-controller handles the lifecycle of VolumeGroupSnapshot and VolumeGroupSnapshotContent objects.
Create a VolumeGroupSnapshotClass. Define the deletion policy and any driver-specific configuration. Example:

apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshotClass
metadata:
  name: csi-groupsnapclass
deletionPolicy: Delete
driver: csi-driver.example.com

Label your PVCs. Apply a common label (e.g., group: my-app) to the PVCs you want to include in the snapshot group.
Create a VolumeGroupSnapshot. Reference the label selector and the VolumeGroupSnapshotClass:

apiVersion: groupsnapshot.storage.k8s.io/v1beta1
kind: VolumeGroupSnapshot
metadata:
  name: my-app-snapshot
spec:
  volumeGroupSnapshotClassName: csi-groupsnapclass
  source:
    selector:
      matchLabels:
        group: my-app

Once created, the controller binds the VolumeGroupSnapshot to a VolumeGroupSnapshotContent. You can then use the group snapshot to create new PVCs pre-populated with the snapshot data by referencing the snapshot’s dataSource field.

Conclusion and Future Directions

The GA release of volume group snapshots in Kubernetes 1.36 marks a significant step forward for data management in containerized environments. By providing native crash consistency across multiple volumes, this feature simplifies backup and restore workflows for complex stateful applications. It also aligns with Kubernetes’ goal of workload portability, allowing teams to move or recover entire application stacks without worrying about storage inconsistencies.

Looking ahead, the Kubernetes community may explore further enhancements such as cross-cluster group snapshots, improved integration with backup tools, and support for non-CSI drivers. For now, volume group snapshots offer a robust, production-ready solution that operators and developers can rely on to protect their data.