Qu'est-ce que la sauvegarde Kubernetes ?
La sauvegarde Kubernetes protège les applications exécutées sur un cluster Kubernetes en capturant ensemble deux éléments : les définitions de ressources qui décrivent chaque application et les données de ses volumes persistants. L'objectif est de pouvoir recréer une application, avec ses données, sur le même cluster ou sur un autre.
Que contient une sauvegarde Kubernetes ?
Une application sur Kubernetes est un ensemble d'objets stockés dans l'API du cluster, comme les deployments, les services, les config maps et les secrets, auxquels s'ajoutent les données des volumes persistants. Les images de conteneurs ne sont en général pas sauvegardées, car elles sont de nouveau téléchargées depuis un registre.
| Composant | Nature | Mode de capture |
|---|---|---|
| Définitions de ressources | Objets qui décrivent l'application | Export depuis l'API Kubernetes |
| Données des volumes persistants | Bases de données, files d'attente, fichiers téléversés | Snapshot de stockage exporté, ou copie au niveau fichier |
| État du cluster (etcd) | Configuration de l'ensemble du cluster | Snapshot etcd distinct, pour reconstruire le cluster lui-même |
| Images de conteneurs | Code applicatif | Conservées dans un registre, en général hors de la sauvegarde |
En quoi diffère-t-elle de la sauvegarde de machines virtuelles ?
La sauvegarde de machines virtuelles capture l'image disque d'une machine à longue durée de vie. Les workloads Kubernetes se répartissent entre des conteneurs éphémères, planifiés là où il y a de la capacité : aucun disque unique ne représente l'application. Les outils de sauvegarde travaillent donc au niveau de l'application ou du namespace, sélectionnent ce qu'il faut protéger au moyen de labels et appellent des hooks dans les conteneurs pour amener les bases de données à un état cohérent avant un snapshot. C'est l'équivalent Kubernetes de la sauvegarde cohérente avec les applications.
Pourquoi les sauvegardes Kubernetes vont-elles sur du stockage objet ?
Presque tous les outils de sauvegarde Kubernetes écrivent sur un stockage objet compatible S3. Il est joignable en HTTP depuis n'importe quel cluster, il s'étend sans volumes préalloués et il se trouve hors du cluster. Ce dernier point est essentiel : une sauvegarde stockée sur le cluster qu'elle protège disparaît avec lui. Le même stockage peut servir plusieurs clusters, ce qui en fait aussi le moyen de déplacer des applications de l'un à l'autre. Quand le stockage prend en charge Object Lock S3, les sauvegardes peuvent être rendues immuables.
Qu'est-ce qui influe sur le dimensionnement et la reprise ?
La capacité dépend des données des volumes persistants, de leur taux de changement et du calendrier de rétention, pas du nombre de conteneurs. Les sauvegardes produisent aussi beaucoup de petits objets : le stockage objet doit gérer un grand nombre d'objets et des listages fréquents. Côté reprise, deux questions se posent : combien de temps faut-il pour restaurer la plus grosse application avec état, et une restauration complète vers un cluster neuf et vide a-t-elle déjà été essayée ? L'article Rétention des sauvegardes Kubernetes et dimensionnement S3 détaille les chiffres.
Questions fréquentes
La sauvegarde d'etcd suffit-elle à protéger les applications Kubernetes ?
Non. Un snapshot etcd restaure la configuration du cluster. Il ne contient pas les données des volumes persistants.
Faut-il sauvegarder les applications sans état ?
Leurs définitions, oui, sauf si elles peuvent être redéployées entièrement depuis un dépôt source. Elles ne détiennent aucune donnée propre.
Une sauvegarde Kubernetes peut-elle être restaurée sur un autre cluster ?
Oui. C'est l'un de ses principaux usages, pour la migration, les mises à niveau et la reprise après sinistre, à condition que les classes de stockage et les versions soient compatibles.