Kubernetes 1.36 adds a native VolumeGroupSnapshot API, restoring the ability to capture a true consistency group across multiple PersistentVolumeClaims. This change matters because multi‑volume stateful workloads—databases, sharded stores, and similar applications—can now be backed up without risking the cross‑volume inconsistencies that have plagued cloud‑native snapshots.
Why the Change Matters
Traditional SAN arrays offered a consistency group feature that froze all LUNs belonging to an application at the same instant, guaranteeing a coherent point‑in‑time view. The CSI snapshot model introduced later only supports a single VolumeSnapshot per PVC, which means each volume is frozen independently. When a database writes its WAL to one volume while data resides on another, the snapshots can capture mismatched states, leading to restore failures that surface only after a disaster.
How VolumeGroupSnapshot Works
The new API introduces three objects:
VolumeGroupSnapshotClass– defined by an admin, it tells the CSI driver how to create group snapshots for a particular storage backend.VolumeGroupSnapshot– the user‑facing request that includes a label selector (e.g.,app=postgres) to identify every PVC that belongs to the same logical application.VolumeGroupSnapshotContent– tracks the actual snapshot resources provisioned by the driver.
When the request is processed, the CSI driver performs a single atomic snapshot across all selected volumes, provided the underlying storage supports atomic group operations. The result is a set of per‑volume snapshots that share a common timestamp, preserving cross‑volume write ordering without requiring the application to quiesce.
Operational Impact and Integration
Backup tools that previously iterated over PVCs must switch to a grouping model. The article notes that Velero, the de‑facto Kubernetes backup project, replaced its per‑PVC loop with a group‑snapshot workflow, then continued to restore each PVC individually using the group’s shared timestamp. This approach retains compatibility with existing restore logic while delivering the consistency guarantee.
Practitioners should evaluate whether their workloads truly need group snapshots. Single‑volume services or independent volumes still benefit from the simpler VolumeSnapshot path, which avoids the coordination overhead of group operations. For databases, indexes, or any application where multiple volumes have inter‑dependent writes, the group snapshot is the safer default.
Security and Risk Considerations
Because the consistency guarantee now resides in the Kubernetes control plane rather than a proprietary array, the security posture depends on the CSI driver’s implementation and the storage backend’s support for atomic snapshots. Teams should verify that the driver correctly enforces the label selector and that the underlying storage does not expose partial snapshots through misconfiguration. Auditing snapshot creation events and ensuring RBAC policies limit who can create VolumeGroupSnapshot objects are prudent steps.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt VolumeGroupSnapshot for any stateful workload that spans more than one PVC to eliminate restore‑time corruption caused by inconsistent snapshots. Review backup pipelines (e.g., Velero) for group‑snapshot support, update documentation to reflect the new API objects, and audit permissions around snapshot creation. For workloads that remain single‑volume, continue using VolumeSnapshot to avoid unnecessary complexity.
