Le Changed Block Tracking CSI passe en bêta et supprime v1alpha1
Le suivi des blocs modifiés pour les drivers CSI de Kubernetes, en alpha depuis septembre 2025, passe en bêta avec la version 1.0.0 d’external-snapshot-metadata et retire l’API v1alpha1 sans conversion automatique. Les éditeurs d’outils de sauvegarde et les mainteneurs de drivers CSI doivent réappliquer le CRD et migrer leurs manifestes vers v1beta1.
Septembre 2025. Le Changed Block Tracking (CBT) pour les drivers CSI de Kubernetes sort en alpha. Mars 2026. La version 1.0.0 du projet external-snapshot-metadata le fait passer en bêta. 14 septembre 2026. Le billet officiel de Prasad Ghangal, mainteneur chez Veeam Kasten, détaille enfin ce qui change, et c’est un choix rare dans l’écosystème : l’API v1alpha1 est supprimée, pas conservée à côté de la nouvelle. Pourquoi c’est important : les sauvegardes incrémentales de volumes ne dépendront plus de scans complets du disque, mais quiconque avait adopté l’alpha doit migrer sans filet de conversion.
Le CBT résout un problème que tout exploitant de cluster connaît : sauvegarder un volume, c’est long et coûteux dès que le volume est gros. Un scan complet relit chaque bloc, même ceux qui n’ont pas bougé depuis la veille. Le suivi des blocs modifiés inverse la logique : le stockage lui-même indique quels blocs ont changé depuis un instantané, et la sauvegarde ne transfère que ceux-là.
Ce que fait le Changed Block Tracking
La fonctionnalité repose sur trois composants, décrits dès l’annonce alpha de septembre 2025. D’abord, le service gRPC SnapshotMetadata, exposé par le driver CSI. Ensuite, la ressource SnapshotMetadataService, un CRD qui annonce qu’un driver sait parler ce protocole. Enfin, le sidecar external-snapshot-metadata, déployé dans le pod du contrôleur, qui fait le pont entre l’API Kubernetes et le driver.
Deux appels suffisent à comprendre le modèle. GetMetadataAllocated renvoie la liste des blocs alloués à un volume. GetMetadataDelta renvoie, lui, la différence entre deux instantanés : exactement la liste des blocs modifiés, ajoutés ou supprimés. C’est ce second appel qui rend possible une sauvegarde incrémentale qui ne lit pas le disque entier.
Une limite est posée dès l’origine et reste vraie en bêta : le CBT ne couvre que les volumes en mode bloc. Les volumes de type fichier et les partages réseau n’entrent pas dans le périmètre. Pour les bases de données, les systèmes de fichiers et les charges stateful classiques sur EBS, Ceph RBD ou LVM, en revanche, c’est la brique qui manquait.
Ce qui change en bêta
Le changement de fond est la promotion du CRD SnapshotMetadataService de v1alpha1 vers v1beta1. Le service de métadonnées, qui servait jusqu’ici sous cbt.storage.k8s.io/v1alpha1, répond désormais sous cbt.storage.k8s.io/v1beta1.
Deux points méritent l’attention. Le schéma est inchangé : les champs, la structure et la sémantique ne bougent pas d’une version à l’autre. Mais la version v1alpha1 n’est pas servie en parallèle de la nouvelle, comme le veut pourtant l’usage dans Kubernetes. Elle est retirée, et il n’existe aucune conversion automatique entre les deux.
C’est un choix de mainteneur assumé. Servir deux versions d’une API de métadonnées de stockage, c’est doubler la surface à tester dans un domaine où un bug se paie en corruption de sauvegarde. En supprimant l’ancienne version plutôt qu’en la maintenant, l’équipe force une migration propre et définitive, au prix d’une coupure pour les premiers adoptants.
La migration en trois étapes
Pour passer de l’alpha à la bêta, le billet officiel liste trois actions, toutes obligatoires :
- Réappliquer la définition du CRD livrée avec la version
v1.0.0d’external-snapshot-metadata, qui installe le schémav1beta1. - Mettre à jour les manifestes SnapshotMetadataService pour utiliser
apiVersion: cbt.storage.k8s.io/v1beta1. - Mettre à jour le code de tout client ou contrôleur qui parle au CRD.
C’est une migration unique, pas un entretien continu. L’absence de conversion signifie qu’il n’y a pas de chemin de mise à niveau transparent : l’opérateur qui repousse la migration reste sur un schéma que plus rien ne sert, et son outil de sauvegarde cesse de fonctionner.
Compatibilité
Les prérequis sont précis et peu contraignants pour un cluster déjà à jour. La version minimale de Kubernetes est la 1.33. Le driver CSI doit implémenter la spécification 1.10 ou plus récente. L’image du sidecar est registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0.
Le déploiement se résume à trois gestes : vérifier que le driver supporte les snapshots de volume et embarque le sidecar, installer le CRD v1beta1, puis créer une ressource SnapshotMetadataService pour le driver. Un client — l’exemple snapshot-metadata-lister fourni dans le dépôt, ou une implémentation maison — appelle ensuite GetMetadataAllocated et GetMetadataDelta. Le driver hostpath sert de banc d’essai de bout en bout.
Pourquoi cela a pris si longtemps
Le CBT arrive tard dans l’histoire de Kubernetes, qui a stabilisé ses snapshots de volume dès 2019 avec le CRD VolumeSnapshot. La raison est structurelle : détecter les blocs modifiés exige que le driver CSI expose une primitive que peu de baies savent fournir de façon standard. Chaque éditeur avait son mécanisme — un agent dans la machine, un hook de snapshot, une API propriétaire — et la sauvegarde incrémentale reposait sur des intégrations maison fragiles.
La spécification SnapshotMetadata change la donne en standardisant le contrat. Le driver déclare une fois pour toutes ce qu’il sait faire, et l’outil de sauvegarde n’a plus à connaître la baie sous-jacente. C’est le même mouvement qui a fait passer les snapshots de scripts ad hoc à une API stable : la brique de base existe, et les produits se construisent dessus au lieu de la réinventer.
Le flux type d’une sauvegarde incrémentale se lit ainsi : l’outil crée un VolumeSnapshot, interroge GetMetadataDelta entre l’instantané précédent et le nouveau, obtient la liste des blocs modifiés, puis ne lit que ces blocs depuis le snapshot. Sur un volume de plusieurs téraoctets dont 2 % ont bougé, on lit des gigaoctets au lieu de tout relire — un gain qui rend des RPO d’une heure réalistes sans saturer le réseau de stockage.
La contrepartie est le temps de maturation. Entre l’alpha de septembre 2025 et la bêta de mars 2026, il a fallu stabiliser le schéma, écrire les clients de référence et convaincre les premiers drivers d’embarquer le sidecar. Le choix de supprimer v1alpha1 plutôt que de le servir en parallèle accélère cette maturation : il évite la fragmentation d’un écosystème qui se partagerait entre deux versions pendant des années.
Pourquoi c’est un enjeu de sauvegarde
Le CBT change l’économie des sauvegardes pour les charges stateful. Sans lui, une sauvegarde incrémentale doit soit relire le volume entier pour détecter les changements, soit s’appuyer sur des mécanismes externes fragiles. Avec lui, l’objectif de point de reprise (RPO) se resserre sans exploser le coût de transfert ni la charge sur le stockage.
La présence de Prasad Ghangal au générique n’est pas anodine : Veeam Kasten, éditeur de sauvegarde Kubernetes, porte activement la fonctionnalité au sein du SIG Storage. C’est le schéma classique des bonnes API de plateforme : l’éditeur qui a besoin d’une primitive la spécifie, la finance et la pousse en amont, puis tout l’écosystème en profite. Le parallèle avec le CBT de VMware, devenu le standard de fait de la sauvegarde incrémentale des machines virtuelles, est explicite.
La feuille de route pour la fin de la bêta est claire : l’adoption par davantage de drivers CSI et le retour d’expérience opérationnel avant le passage en GA. Les mainteneurs de drivers sont explicitement invités à évaluer l’ajout du support maintenant, et les éditeurs d’outils de sauvegarde à tester les clients de streaming et le paquet d’itérateurs.
Verdict
Si vous maintenez un driver CSI, c’est le moment d’évaluer l’implémentation du service SnapshotMetadata : la spécification est stable, le périmètre est borné au mode bloc, et l’adopter tôt vous place en bonne position avant la GA. Si vous construisez un outil de sauvegarde ou de reprise d’activité sur Kubernetes, intégrez GetMetadataDelta plutôt qu’un scan complet : c’est la différence entre un RPO de quelques minutes et un RPO qui dépend du temps de lecture d’un volume entier. Si vous aviez adopté l’alpha, ne tardez pas : réappliquez le CRD v1beta1, migrez vos manifestes et votre code, car la version v1alpha1 a déjà disparu et il n’existe pas de chemin de conversion.