Sauvegarder et restaurer Kubernetes

Dans un environnement Kubernetes, les incidents ne préviennent pas : une erreur humaine, une défaillance matérielle ou une attaque peuvent vite mettre en péril vos applications. Pour éviter toute perte, il est essentiel de disposer d’une stratégie claire de sauvegarde et de restauration du cluster. Dans ce guide, je vous partage une méthode simple et efficace pour protéger vos ressources Kubernetes, inspirée des meilleures pratiques en production.

Pourquoi la sauvegarde des clusters Kubernetes est-elle indispensable ?

Kubernetes est aujourd’hui au cœur de l’infrastructure de nombreuses entreprises. Mais derrière sa puissance se cache une réalité : un cluster peut tomber à tout moment. Alors, pourquoi est-il indispensable d’en faire des sauvegardes régulières ?

D’abord, parce que les déploiements Kubernetes ne sont pas immuables. À chaque mise à jour, chaque nouvelle configuration, vous prenez le risque d’introduire un bug, de supprimer une ressource critique ou de corrompre un service. Et si cette modification n’est pas réversible, les conséquences peuvent être graves.

Ensuite, les pannes matérielles, les erreurs humaines, les mises à jour ratées ou même les cyberattaques peuvent affecter votre cluster. Sans sauvegarde, il est souvent impossible de revenir à un état stable. Vous perdez alors vos configurations, vos secrets, voire les données de vos utilisateurs.

Enfin, certaines entreprises ont des obligations réglementaires. Le RGPD, par exemple, impose de pouvoir restaurer rapidement des données personnelles en cas d’incident. Une stratégie de sauvegarde devient alors non seulement une bonne pratique, mais une exigence légale.

À mon avis, la vraie question n’est pas « faut-il sauvegarder **Kubernetes **? », mais plutôt « combien de temps pouvez-vous vous permettre d’être sans votre cluster ? ». Mieux vaut anticiper que réparer.

Composants clés à sauvegarder

Sauvegarder un cluster Kubernetes ne se résume pas à copier quelques fichiers. Il faut d’abord savoir ce qu’il faut sauvegarder. Tous les éléments du cluster ne sont pas critiques, mais certains sont absolument indispensables pour assurer une restauration fonctionnelle. Voici ceux que je considère comme prioritaires :

1. L’état du cluster (etcd)

Le cœur du cluster, c’est etcd. C’est une base de données clé-valeur distribuée qui contient l’intégralité de l’état du cluster : les pods en cours d’exécution, les services, les secrets, les ConfigMaps, les rôles, les bindings, etc. Perdre etcd, c’est comme perdre la mémoire de Kubernetes.

Sans une copie de cette base, impossible de reconstituer l’environnement tel qu’il était. C’est donc le premier composant à sauvegarder régulièrement, surtout si vos ressources sont créées directement dans le cluster (et non redéployées via GitOps ou CI/CD).

2. Les volumes persistants (PVs)

Les données de vos applications — bases de données, fichiers, documents utilisateur — sont stockées dans les volumes persistants. Ces données ne sont pas gérées par Kubernetes directement, mais par le système de stockage sous-jacent (via le CSI).

Si vous avez des applications stateful comme PostgreSQL, Elasticsearch ou Nextcloud, il est impératif de sauvegarder ces volumes. Sinon, vous pourrez bien restaurer le cluster, mais avec des applications… vides.

3. Les configurations (ConfigMaps, Secrets)

Les ConfigMaps et Secrets sont souvent négligés, mais ils contiennent des paramètres critiques : connexions aux bases de données, clés API, chemins de configuration, options d’exécution. En cas de restauration, sans eux, votre application ne redémarrera pas correctement, ou pas du tout.

4. Les ressources applicatives

Enfin, il faut inclure toutes les ressources Kubernetes qui composent vos applications : Deployments, StatefulSets, Services, Ingress, NetworkPolicies, etc. Ce sont elles qui définissent l’architecture de votre application et son comportement dans le cluster.

Même si certaines peuvent être redéployées via un pipeline CI/CD, avoir une copie complète dans les sauvegardes vous permet de restaurer plus vite en cas d’urgence ou de désastre total.

Défis et meilleures pratiques

Mettre en place une stratégie de sauvegarde et de restauration pour Kubernetes, ce n’est pas simplement installer un outil et oublier. Il y a des pièges fréquents, des erreurs que j’ai moi-même commises (ou vues ailleurs), et des bonnes pratiques que je recommande pour éviter les mauvaises surprises.

1. Assurer la consistance des données

L’un des grands défis, c’est la cohérence entre les différentes parties de la sauvegarde. Sauvegarder les ressources Kubernetes sans les volumes peut suffire pour une application stateless, mais pas pour une base de données. À l’inverse, sauvegarder uniquement les volumes sans les ConfigMaps ou Secrets peut rendre l’application inutilisable après restauration.

Je recommande donc d’utiliser des outils qui peuvent capturer l’état global d’une application, comme Velero ou Kasten K10, en un seul flux cohérent.

2. Respecter les exigences réglementaires

Selon votre secteur, vous êtes peut-être soumis à des obligations comme le RGPD, la conservation longue durée, ou la traçabilité des accès aux données. Cela impacte la manière dont vous stockez vos sauvegardes : durée de rétention, chiffrement, localisation des données (UE ou non), etc.

Il me semble important d’impliquer les équipes légales ou conformité dès le début, pour éviter de devoir tout revoir après coup.

3. Sécuriser les sauvegardes

Une erreur fréquente est de sauvegarder… mais de laisser les sauvegardes en clair, sur un stockage accessible à tous, ou sans authentification. C’est une faille de sécurité majeure : si un attaquant accède à ces données, il peut récupérer tous les secrets du cluster.

À mon avis, il faut systématiquement chiffrer les sauvegardes, utiliser un stockage restreint (bucket S3 avec politiques d’accès par rôle, par exemple), et surveiller les accès à ces ressources.

4. Tester les restaurations

Sauvegarder sans tester, c’est comme acheter un extincteur sans vérifier s’il fonctionne. Il faut automatiser des tests de restauration sur un cluster de test, au moins tous les mois. C’est le seul moyen de s’assurer que tout est en place et fonctionnel.

Ces tests révèlent souvent des oublis : un volume non sauvegardé, une dépendance non documentée, un problème de version… Mieux vaut les découvrir à froid qu’en pleine crise.

5. Documenter et automatiser

Enfin, la documentation est votre meilleure alliée. Notez où sont les sauvegardes, comment les restaurer, qui contacter en cas d’urgence. Et dès que possible, automatisez ces procédures : scripts de restauration, pipelines CI pour les sauvegardes, alertes sur les échecs.

Stratégies de sauvegarde recommandées

Mettre en place une sauvegarde Kubernetes efficace, ce n’est pas juste déclencher une tâche cron une fois par semaine. Il s’agit de choisir une stratégie adaptée à votre environnement, à votre niveau de complexité… et à votre budget. Voici les approches que j’ai testées ou vues en production, avec leurs avantages.

1. Sauvegarde au niveau de l’application : Cette approche consiste à sauvegarder chaque application de façon indépendante. On récupère ses ressources Kubernetes (manifests YAML), ses configurations, et ses volumes de données. C’est une stratégie granulaire, idéale pour restaurer une seule application sans toucher au reste du cluster. Je la recommande particulièrement si vous avez plusieurs équipes qui déploient sur le même cluster, ou si vous gérez des applications critiques que vous souhaitez isoler.
2. Sauvegarde au niveau du cluster : Ici, on sauvegarde l’intégralité du cluster : etcd, objets Kubernetes, volumes persistants, configurations réseau… C’est la méthode la plus complète, souvent utilisée dans les contextes de haute disponibilité ou de reprise après sinistre. Elle permet de reconstruire un cluster entier en cas de crash majeur, mais elle demande plus de ressources (stockage, bande passante) et plus de temps pour la restauration.
3. Snapshots de volumes : Certaines solutions de stockage compatibles avec Kubernetes (via le CSI) permettent de prendre des snapshots des volumes. C’est rapide, efficace, et souvent automatisable. Attention cependant : ces snapshots ne suffisent pas seuls. Ils ne couvrent ni l’état du cluster (etcd), ni les objets Kubernetes. Je les vois plutôt comme un complément à une stratégie plus globale.

Considérations pour la restauration des données

Sauvegarder, c’est bien. Mais restaurer, c’est tout aussi critique — et parfois bien plus délicat. Une restauration mal préparée peut empirer la situation, corrompre vos données, ou créer des incohérences dans votre cluster. Voici, d’après mon expérience, les points essentiels à prendre en compte pour réussir une restauration sans mauvaise surprise.

1. Vérifier l’intégrité des sauvegardes : Avant toute chose, il faut s’assurer que les sauvegardes sont utilisables. Une sauvegarde corrompue, incomplète ou chiffrée sans la clé de déchiffrement est… inutile. Je recommande de mettre en place une vérification automatique (checksum, test de montage, logs d’erreurs) après chaque opération de backup. Encore mieux : faire des restaurations à blanc régulièrement sur un cluster de test. Cela permet d’avoir la certitude que le processus fonctionne quand on en a vraiment besoin.
2. Gérer la compatibilité des versions : Le cluster dans lequel vous restaurez les données doit être compatible avec l’environnement d’origine. Par exemple, une sauvegarde d’etcd issue de Kubernetes 1.28 peut ne pas être directement restaurable sur une version 1.32. Même chose pour les API deprecated ou modifiées entre deux versions. À mon avis, il vaut mieux documenter les versions exactes de Kubernetes, d’etcd et des plugins utilisés au moment de la sauvegarde. Cela évite bien des surprises au moment critique.
3. Considérer l’environnement cible: Restaurer sur le même cluster ou sur un environnement différent (cloud, autre data center) n’implique pas les mêmes contraintes. Les adresses IP, les volumes, ou les classes de stockage peuvent varier. Il faut parfois adapter les manifests YAML ou les paramètres réseau. C’est pour ça que je privilégie des sauvegardes portables, avec des ressources décrites de façon générique (sans dépendance forte à un nom de node ou une IP statique).
4. Restaurer dans le bon ordre : La restauration doit suivre une séquence logique. Si vous commencez par restaurer des volumes ou des pods avant d’avoir restauré les configurations (etcd, ConfigMaps, Secrets), vous risquez des échecs ou un comportement incohérent.

L’ordre que je recommande est :

1. etcd et les ressources critiques (RBAC, namespaces)
2. Configurations (ConfigMaps, Secrets, CRDs)
3. Ressources applicatives (Deployments, Services…)
4. Volumes persistants (snapshots, data)

Respecter cet ordre permet à Kubernetes de retrouver un état cohérent et fonctionnel.

Les Solutions de sauvegarde et de restauration

Il existe de nombreuses solutions pour mettre en place une stratégie efficace de sauvegarde et de restauration dans Kubernetes. Certaines sont légères et simples à déployer, d’autres plus complètes et pensées pour les environnements à grande échelle. Plutôt que de tout aborder ici, j’ai choisi de consacrer un guide dédié à chaque solution que je considère pertinente. Cela me permettra de vous proposer des tutoriels clairs, adaptés à différents contextes et niveaux de maturité.

Voici les outils que je vais explorer plus en détail dans les prochains guides :

1. Velero : C’est sans doute l’outil de référence open-source pour la sauvegarde de clusters Kubernetes. Il permet de sauvegarder les ressources Kubernetes, les volumes persistants, et même de migrer des workloads entre clusters. Je vous montrerai comment le déployer, le connecter à un stockage cloud (S3, Azure Blob, etc.), planifier les sauvegardes et tester des restaurations.
2. Kasten K10 : Kasten est une solution commerciale pensée pour les environnements d’entreprise. Elle offre une interface graphique complète, des politiques de sauvegarde flexibles, et une intégration native avec les principales plateformes cloud. Je vous guiderai à travers son installation, ses principales fonctionnalités, et son usage dans un contexte multicluster.
3. Stash : Moins connu mais très intéressant, Stash permet de sauvegarder à la fois les ressources Kubernetes et les bases de données, via des intégrations avec des outils comme Restic et VolumeSnapshotter. Je vous expliquerai comment l’utiliser pour gérer des workloads complexes avec peu de configuration.
4. TrilioVault : Une autre solution orientée entreprise, TrilioVault propose une approche modulaire avec de puissantes options de gestion de la restauration et de la conformité. Je vous montrerai comment l’intégrer à un cluster, définir des politiques de protection, et restaurer à différents niveaux de granularité.
5. Longhorn (pour la gestion des volumes) : Longhorn n’est pas un outil de backup à proprement parler, mais une solution de stockage distribué qui inclut des fonctionnalités de snapshots et de restauration. Si vous utilisez Rancher ou souhaitez une alternative légère à CSI+snapshots, vous verrez comment tirer parti de Longhorn pour sécuriser vos volumes.

Conclusion

Travailler avec Kubernetes, c’est accepter que l’imprévu peut frapper à tout moment. Mais c’est aussi avoir les moyens de s’en relever rapidement — à condition d’avoir préparé le terrain avec une stratégie de sauvegarde bien pensée.

Dans ce guide, je vous ai présenté les bases : pourquoi sauvegarder, quoi sauvegarder, quelles approches adopter, et les précautions à prendre pour restaurer sans accrocs. Ce n’est qu’un point de départ.

Je vais prochainement publier une série de guides détaillés sur les solutions les plus efficaces pour protéger vos clusters :

• sauvegarde manuelle et restauration d’etcd
• utilisation de Velero
• déploiement de Kasten K10
• configuration de Stash ou TrilioVault
• snapshots de volumes avec Longhorn

Si vous voulez suivre leur publication, je vous invite à rester connecté sur mon compte LinkedIn ↗ où je partagerai chaque guide au fur et à mesure. C’est le meilleur moyen pour vous former, à votre rythme, avec des contenus pratiques, pensés pour les admins système et DevOps du quotidien.