Velero sauvegarde un cluster entier : ressources Kubernetes et volumes ensemble, pour une reprise après sinistre complète. VolumeSnapshot, l’API native de snapshot de Kubernetes, répond à un besoin plus étroit et bien plus fréquent au quotidien : capturer l’état d’un seul volume persistant à un instant donné, sans jamais toucher aux ressources qui l’entourent.

Ce que VolumeSnapshot capture, et ce qu’il ignore

VolumeSnapshot délègue la capture réelle au pilote CSI du fournisseur de stockage, en créant un objet Kubernetes qui référence ce snapshot sans jamais toucher aux Deployments, Services ou autres ressources qui utilisent ce volume. Un snapshot pris sur le PVC d’une base de données ne dit rien sur l’état du Deployment qui la sert : c’est une capture de données pure, pas un état de cluster.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snapshot
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: db-data

VolumeSnapshotClass : le pilote CSI décide de la mécanique réelle

VolumeSnapshotClass référence le pilote CSI responsable de la capture, exactement comme une StorageClass référence le pilote responsable du provisionnement. La mécanique exacte (copie complète, snapshot incrémental au niveau du stockage sous-jacent) dépend entièrement de ce pilote, pas de Kubernetes lui-même.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
driver: ebs.csi.aws.com
deletionPolicy: Retain

Tous les pilotes CSI ne supportent pas les snapshots : vérifier cette capacité avant de concevoir un workflow qui en dépend reste une étape obligatoire, exactement comme vérifier qu’un CNI implémente réellement les NetworkPolicy avant de s’y fier.

Le cas d’usage le plus courant : cloner un volume pour un environnement de test

Un VolumeSnapshot existant permet de créer un nouveau PVC dont les données proviennent directement du snapshot, sans jamais toucher au volume source : une copie complète et indépendante, utile pour reproduire l’état exact d’une base de données en environnement de test sans risquer la production.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-data-clone
spec:
  dataSource:
    name: db-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi

Ce clonage tourne indépendamment du volume d’origine dès sa création : aucune synchronisation continue, aucun lien maintenu après la copie initiale, une différence importante avec une réplication en continu.

Ce que VolumeSnapshot ne remplace jamais

Un VolumeSnapshot ne sauvegarde que des données de volume, jamais les ressources Kubernetes qui les entourent : un cluster entièrement détruit avec ses VolumeSnapshot intacts laisse des données récupérables mais aucune définition de Deployment, de Service, ou de Secret pour les faire revivre. Velero et VolumeSnapshot répondent à deux besoins différents et complémentaires, pas à un seul besoin sous deux formes : DR complet du cluster contre clonage ponctuel de données.

À retenir

VolumeSnapshot capture l’état d’un volume persistant à un instant donné, en délégant la mécanique réelle au pilote CSI du fournisseur de stockage via VolumeSnapshotClass, sans jamais toucher aux ressources Kubernetes qui utilisent ce volume. Le cas d’usage le plus courant clone un volume pour un environnement de test à partir d’un snapshot existant, une opération indépendante et sans lien continu avec le volume source. Ce mécanisme ne remplace jamais une sauvegarde cluster complète comme Velero : les deux répondent à des besoins distincts, un des choix d’outillage stockage qui se posent dès qu’une migration Kubernetes doit gérer des données avec état.