Le 10 septembre 2026, la CNCF a publié des recommandations fondées sur trois scénarios de défaillance reproductibles, afin de tester la reprise après sinistre d’applications Kubernetes avec état, et non de se contenter de vérifier que la sauvegarde s’est terminée avec le statut Completed. Les expériences, qui peuvent être exécutées sur un ordinateur portable depuis le dépôt du laboratoire, ont utilisé une application PostgreSQL contenant des données connues composées de quatre lignes, afin de pouvoir vérifier le résultat réel de la restauration plutôt que de s’appuyer sur des indicateurs d’état généraux.
Le document a été préparé par Saiyam Pathak et Saloni Narang, tous deux ambassadeurs de la CNCF. Son périmètre se limite à la restauration de l’état des applications au sein de Kubernetes ; il ne traite pas des cadres de conformité, de la comparaison des produits, ni de la restauration de l’infrastructure fondamentale du cloud ou du centre de données. Des outils tels que Velero et les interfaces CSI Snapshot y apparaissent comme des implémentations de référence pour les scénarios, tandis que les modes de défaillance s’appliquent aux outils qui remplissent les mêmes fonctions.
Une sauvegarde terminée ne prouve pas la restaurabilité
Dans le premier scénario, les composants d’une sauvegarde Kubernetes ont été séparés en définitions de ressources au format YAML et en données des volumes persistants. Le laboratoire a utilisé Velero avec un mécanisme de transfert des données vers un stockage objet compatible S3 situé à l’extérieur des deux clusters. L’examen des objets DataUpload a montré que 47,989,888 octets de données du volume avaient effectivement été transférés vers le stockage externe.
Après la suppression de l’espace de noms, y compris du PVC, la restauration a rétabli les quatre mêmes lignes en environ deux minutes. Toutefois, la CNCF avertit que la protection des données d’un volume ne rend pas automatiquement une sauvegarde de base de données cohérente au niveau applicatif ; les applications peuvent avoir besoin d’opérations de flush ou de quiesce. Une restauration sur une architecture différente peut également nécessiter l’adaptation de la StorageClass et d’autres transformations que l’équipe doit concevoir et tester.
Plus important encore, les outils de sauvegarde restaurent les ressources dans un cluster déjà existant et ne créent ni les nœuds, ni le réseau, ni les équilibreurs de charge, ni le DNS. Le plan de reprise doit donc définir clairement l’environnement qui recevra la sauvegarde, en confiant, si nécessaire, la restauration de Kubernetes à l’infrastructure en tant que code ou à Cluster API.
Git restaure l’intention, pas l’état stocké
Dans le deuxième scénario, le cluster de production a été arrêté, tandis qu’un cluster de reprise existait déjà et contenait un contrôleur GitOps lié à un dépôt Git ainsi qu’un outil de sauvegarde connecté au stockage partagé. La synchronisation de l’application a réussi, le StatefulSet était en fonctionnement et le tableau de bord affichait un état sain, mais l’interrogation de la base de données a renvoyé l’erreur : relation "attendees" does not exist.
La cause n’était ni une défaillance de Kubernetes ni un problème de GitOps. Le dépôt ne contenait que les définitions ; le contrôleur a donc recréé un StatefulSet, un Service et un nouveau volume de stockage vide. En pratique, Git stocke l’état déclaré ou l’intention de l’équipe, tandis que les sauvegardes stockent les données réelles ; aucun des deux ne peut, à lui seul, restaurer entièrement l’application.
La méthode de reprise du laboratoire consistait à supprimer l’application vide créée par la synchronisation, puis à restaurer l’application avec ses volumes depuis le stockage des sauvegardes, et enfin à comparer les données avec le contenu attendu. Le délai entre l’arrêt de la production et l’apparition de données vérifiées a été de quatre minutes lors de l’expérience en direct et d’un peu moins de deux minutes lors de la répétition du test. La CNCF précise que ces chiffres couvrent uniquement la partie automatisée et n’incluent pas la détection de l’incident, la prise de décision, le basculement du trafic ni le retour à l’environnement d’origine.
Des instantanés isolés peuvent produire un point de restauration qui n’a jamais existé
Le troisième scénario a testé une application utilisant deux volumes de stockage interdépendants : l’un pour les commandes et l’autre pour les paiements. Le laboratoire écrivait des paires correspondantes à raison de cinq fois par seconde, avec pour condition que chaque paiement corresponde à une commande. Lors de la prise de deux instantanés séparés de cinq secondes, chaque instantané semblait prêt et sain individuellement, mais la restauration a révélé que la dernière commande enregistrée était 108352, contre 108377 paiements, soit 25 paiements sans commande correspondante.
Le résultat montre que la réussite de chaque opération de stockage prise isolément ne garantit pas la cohérence d’une application utilisant plusieurs volumes ; les deux instantanés peuvent ensemble décrire un moment qui n’a jamais réellement existé. Le document indique que l’écart peut s’accroître en production lorsque l’outil de sauvegarde parcourt un grand nombre de PVCs l’un après l’autre.
VolumeGroupSnapshot, qui a atteint le statut GA dans Kubernetes 1.36, fournit un mécanisme permettant d’identifier les volumes au moyen d’une seule étiquette et de demander un point de restauration cohérent via CSI. Lors de l’expérience coordonnée, le dernier numéro des commandes et des paiements correspondait à 109169, et la vérification de leur relation a réussi. Toutefois, la prise en charge dépend du pilote ; la prise en charge des VolumeSnapshots ordinaires ne prouve pas celle des instantanés de groupes, et la plupart des principaux pilotes cloud examinés pour le laboratoire ne les implémentaient pas encore à la mi-2026. Les CRDs, la fonctionnalité d’instantanés et les composants supplémentaires associés doivent également être activés explicitement.
Que doit mesurer un test de reprise ?
- Restaurer une application complète vers une cible propre qui ne l’a jamais exécutée auparavant, plutôt que de simplement supprimer un Pod et d’observer sa recréation.
- Vérifier les données et le chemin d’accès de l’utilisateur au moyen d’un contenu attendu, sans se limiter à l’état des ressources ou aux couleurs des tableaux de bord.
- Mesurer l’ensemble du processus avec un chronomètre, en gardant à l’esprit que le temps réel de restauration inclut la détection, la décision, le basculement du trafic et, éventuellement, le retour à l’environnement d’origine.
- Utiliser deux domaines de défaillance indépendants, par exemple un cluster de production et un cluster de reprise, et placer le stockage des sauvegardes à l’extérieur des deux.
Lecture éditoriale : l’écart entre les outils et la séquence de reprise
Le changement pratique mis en évidence par ces expériences consiste à déplacer le critère de réussite de « la sauvegarde est terminée » à « les bonnes données sont revenues et sont accessibles ». La limite plus large est que Kubernetes de base ne définit pas de contrat commun pour coordonner les données, l’application, le cluster, le trafic et l’identité, et ne fournit pas de ressource standard et durable décrivant l’unité complète de reprise de l’application et ses dépendances externes. Les frontières entre GitOps, la sauvegarde, l’infrastructure et le parcours utilisateur restent donc sous la responsabilité de l’équipe, même lorsque des outils matures sont disponibles pour chaque couche. La CNCF indique que l’initiative Cloud Native Business Continuity de la CNCF TAG Operational Resilience cherche à rassembler des contributions sur l’analyse des lacunes de l’écosystème, les recommandations de reprise et les architectures de référence.