How do VolumeSnapshot, VolumeSnapshotContent and VolumeSnapshotClass work together in Kubernetes, and how do you create a new PersistentVolumeClaim from a snapshot?

## The three objects Kubernetes deliberately reuses the shape of the storage API you already know. | Storage | Snapshots | Scope | |---|---|---| | StorageClass | VolumeSnapshotClass | cluster | | PersistentVolumeClaim | VolumeSnapshot | namespace | | PersistentVolume | VolumeSnapshotContent | cluster | **VolumeSnapshotClass** names the CSI driver (`driver: ebs.csi.aws.com`), driver-specific `parameters`, and a `deletionPolicy` of `Delete` or `Retain` - the same choice a PV reclaim policy gives you: does deleting the Kubernetes object destroy the snapshot in the backend? **VolumeSnapshot** is what an application team writes. It lives in the namespace of the PVC it snapshots and references it via `spec.source.persistentVolumeClaimName`. **VolumeSnapshotContent** is created by the controller (dynamic case) or pre-created by an admin (static case, pointing at an existing backend snapshot via `snapshotHandle`) and bound one-to-one with the VolumeSnapshot. ## What has to be installed This is the detail candidates most often miss: snapshot support is **not** built into a stock Kubernetes control plane. It requires - the snapshot CRDs, - the `snapshot-controller` deployment (one per cluster), and - the `external-snapshotter` sidecar in each CSI driver's controller pod, with the driver advertising the `CREATE_DELETE_SNAPSHOT` capability. Managed Kubernetes offerings usually pre-install these; on a self-managed cluster, `kubectl get volumesnapshotclasses` returning "no matches for kind" means the CRDs are absent. ## The create flow 1. User creates a VolumeSnapshot naming a Bound PVC. 2. `snapshot-controller` creates a VolumeSnapshotContent and links the pair. 3. `external-snapshotter` calls `CreateSnapshot` on the CSI controller plugin. 4. The driver takes the backend snapshot; when the backend reports completion, `status.readyToUse` becomes `true` and `restoreSize` is populated. `readyToUse: false` is the normal transient state; many backends cut the snapshot instantly but need time before it is restorable. Never assume the snapshot exists just because the object does. ## The restore flow Restoring means **provisioning a new volume** from the snapshot: ```yaml spec: dataSource: name: pg-snap-2026-08-01 kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io ``` The provisioner calls `CreateVolume` with the snapshot as content source. Constraints worth knowing: - The new PVC's requested size must be at least the snapshot's `restoreSize`; you may grow, not shrink. - The restore normally lands in the same topology (zone) as the snapshot, and generally the same StorageClass/driver. - There is no in-place restore. To "roll back" a workload you restore into a new PVC and repoint the workload at it - which for a StatefulSet means creating a PVC with the exact name the ordinal expects before scaling that pod up. ## Consistency - the answer that separates candidates A CSI snapshot captures the block device at a point in time. That is **crash consistency**: exactly what the filesystem would look like after a power cut. Journalling filesystems and databases with write-ahead logs generally recover from that, but recovery is not free and is not guaranteed for every engine or for data spread across several volumes. For **application consistency** you need the application to be quiesced or aware: flush and freeze the database, or use its native backup (a base backup plus WAL shipping, for instance). Two volumes snapshotted a second apart are not a consistent pair, which matters for any workload separating data and log onto different disks. Say this out loud in an interview: "snapshots are crash-consistent; for a database I still want a logical or engine-native backup, and I test restores." ## Operational notes - Snapshots are usually incremental in the backend but still cost money; retention needs automation, since nothing prunes them for you. - `deletionPolicy: Retain` leaves orphaned backend snapshots when the Kubernetes object goes away - deliberate for safety, a leak if unmanaged. - Deleting a source PVC while snapshots exist is guarded by finalizers in recent snapshot-controller versions, but ordering still deserves care. - A snapshot is not a backup if it lives in the same account, region and blast radius as the source volume. Treat off-cluster copies as a separate concern.