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 hébergez des applications à état, PostgreSQL, Elasticsearch ou Nextcloud, la sauvegarde de leurs volumes n'est pas optionnelle. Sans elle, vous restaurerez le cluster et retrouverez les 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.

Sauvegarder les objets d'un namespace, et pourquoi kubectl ne suffit pas

Des quatre composants ci-dessus, deux ont déjà leur procédure ailleurs : etcd est traité dans sa propre leçon, et les volumes dépendent de votre système de stockage. Reste les objets, que beaucoup croient sauvegarder avec une seule commande. Elle existe, et le résultat ne se restaure pas.

L'export brut, et ce qu'il contient vraiment

kubectl -n mon-app get all,configmap,secret,ingress,pvc -o yaml > sauvegarde.yaml

Sur un namespace de test contenant un Deployment, une ConfigMap et un Secret, donc six objets, le fichier produit fait 9418 octets et porte 32 champs que le cluster gère lui-même : uid, resourceVersion, creationTimestamp, blocs status. Il contient aussi une ConfigMap que vous n'avez pas créée, kube-root-ca.crt, que Kubernetes place dans chaque namespace.

Rejouez ce fichier sur un namespace recréé, et voici ce que vous obtenez :

Error from server (Conflict): error when applying patch:
Resource: "/v1, Resource=configmaps", Name: "kube-root-ca.crt"
Operation cannot be fulfilled on configmaps "kube-root-ca.crt":
the object has been modified; please apply your changes to the latest version

L'export n'est pas une sauvegarde restaurable. Il décrit un état passé, avec l'identité des objets de l'époque, et se heurte à celle des objets actuels. Le drapeau --show-managed-fields=false n'y change rien : les trois champs d'identité restent dans la sortie.

Le Secret n'est pas protégé dans cet export

kubectl -n mon-app get secret cred-app -o yaml

data:
  JETON: dmFsZXVyLWRlLWRlbW9uc3RyYXRpb24=
kind: Secret

Cette chaîne n'est pas chiffrée, elle est encodée en base64, et un base64 -d rend valeur-de-demonstration. Toute personne qui ouvre votre fichier de sauvegarde lit vos jetons et vos mots de passe. C'est pour cela que le chiffrement de la sauvegarde, évoqué plus bas, n'est pas une précaution mais une obligation.

Ce qu'il faut en conclure

Deux chemins seulement tiennent en production. Le premier est GitOps : les manifestes vivent dans un dépôt, ils sont la source de vérité, et vous n'avez pas d'objets à sauvegarder puisqu'ils se redéploient. Le second est un outil dédié comme Velero, qui nettoie les champs d'identité, gère l'ordre de restauration et couvre les volumes dans le même flux. L'export kubectl garde une seule utilité : inspecter un état avant une manipulation risquée.

Snapshots de volume : ce que votre cluster permet, ou non

Un snapshot CSI n'est pas une fonctionnalité de Kubernetes mais de votre pilote de stockage. Avant de bâtir une stratégie dessus, vérifiez qu'il existe chez vous :

kubectl get volumesnapshotclass

Sur un cluster kind, la réponse est sans appel :

error: the server doesn't have a resource type "volumesnapshot"

Le provisionneur par défaut de kind est rancher.io/local-path, qui écrit dans un répertoire du nœud et n'implémente pas les snapshots ; les définitions de ressources correspondantes ne sont même pas installées. Ce n'est pas une panne, c'est une limite à connaître : les snapshots de volume ne se pratiquent pas sur un lab kind par défaut, il faut un pilote CSI qui les supporte.

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 presque toujours un oubli : un volume non sauvegardé, une dépendance non documentée, une incompatibilité 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.

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.
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.
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.

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.
Gérer la compatibilité des versions : Le cluster dans lequel vous restaurez les données doit être compatible avec l'environnement d'origine. Un instantané etcd n'est pas un format universel : il porte le schéma de stockage de la version qui l'a produit. Restaurer un instantané pris sur un cluster nettement plus ancien que le cluster cible peut donc échouer, et la règle de montée de version s'applique ici aussi, de proche en proche. 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.
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).
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 :

etcd et les ressources critiques (RBAC, namespaces)
Configurations (ConfigMaps, Secrets, CRDs)
Ressources applicatives (Deployments, Services…)
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, des plus légères aux plus complètes. Le tableau mental à garder est simple : aucune ne remplace les autres, elles couvrent des périmètres différents, et le choix se fait sur ce que vous devez protéger plutôt que sur la richesse de l'outil.

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.
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.
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.
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é.
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.

Testez vos connaissances

Cinq questions sur ce qui sépare une sauvegarde d'une illusion de sauvegarde : ce qu'un export kubectl ne restaure pas, ce qu'etcd ne protège pas, et ce que votre pilote de stockage permet réellement.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

5 questions

5 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

À retenir

Une sauvegarde Kubernetes couvre quatre composants distincts : l'état du cluster dans etcd, les volumes persistants, les configurations et les ressources applicatives. Aucun ne remplace les autres.
Sauvegarder etcd ne protège pas vos données : elles vivent dans les volumes, donc dans le système de stockage sous-jacent.
Un export kubectl get -o yaml ne se restaure pas : il embarque l'identité des objets de l'époque et échoue en conflit au réapplication.
Un Secret exporté est encodé, pas chiffré : la sauvegarde doit l'être.
Les snapshots CSI dépendent du pilote de stockage, pas de Kubernetes, et n'existent pas sur un cluster kind par défaut.
Une sauvegarde non testée n'est pas une sauvegarde. La restauration se répète périodiquement sur un cluster de test.
L'ordre de restauration compte : etcd, configurations, applications, volumes.