Sauvegarde : les 5 clés pour protéger un environnement Kubernetes

Le container est un format d’instance virtuelle de plus en plus utilisé pour exécuter les applications. Selon le cabinet d’études ESG, la moitié des entreprises auraient intégré une forme de containers à leur SI et les deux tiers d’entre elles les utiliseraient en production. Ce succès soulève toutefois des questions sur la protection des applications à ce format : à l’évidence, on ne sauvegarde pas des containers avec les outils qui servent à sauvegarder des machines virtuelles.

Les outils conventionnels qui sauvegardent les machines virtuelles ne sont pas bien adaptés aux containers, car ils échouent à suivre les containers dans les différents endroits où ils peuvent être exécutés, sur site ou en cloud. Les outils de sauvegarde des machines virtuelles sont conçus pour sauvegarder des disques et des volumes logiques à un endroit prédéterminé.

Pire, les containers se trouvent dans une zone d’ombre de la sauvegarde. Ils sont souvent déployés et contrôlés par les équipes DevOps en tant que composants temporaires, ou affiliés aux ressources en cloud. Cela signifie qu’ils n’apparaissent donc pas nécessairement dans l’inventaire des équipes responsable des sauvegardes et restaurations.

Associés à l’origine aux microservices – des modules applicatifs que l’on peut mettre individuellement à jour pour ne pas avoir à redéployer toute une application quand on ne change qu’un de ses composants – les containers sont des instances virtuelles bien plus légères que les machines virtuelles. Débarrassés de toute la couche OS, ils sont plus facilement transposables d’une infrastructure à l’autre, plus légers en termes de stockage et moins coûteux en ce qui concerne la puissance de calcul.

Ces avantages ont amené les entreprises à utiliser les containers à la place des VM pour exécuter n’importe quelle application et plus nécessairement celles qu’elles développaient elles-mêmes pour le web. En pratique, cela signifie faire exécuter les applications par un orchestrateur Kubernetes, plutôt que par un hyperviseur ESXi, Hyper-V ou KVM.

Cette évolution dans l’usage a nécessité de transformer un peu le principe technique. À la base, les containers étaient censés être des instances « stateless » (état indéterminé) : ils ne conservaient pas dans leur coquille les données qu’ils généraient, de sorte que déployer, déplacer, éteindre des instances applicatives revenait simplement à générer ou à détruire les clones d’un modèle générique. Mais ce n’est pas ainsi que fonctionnent les applications classiques, lesquelles baignent dans un environnement « stateful » (état pris en compte) : elles ont besoin d’avoir dans leur coquille des données qui évoluent ou se créent constamment et ces données doivent être conservées même lorsque l’application redémarre, éventuellement ailleurs.

En cas d’incident, les entreprises ont besoin de pouvoir restaurer les clusters de containers qui exécutent leurs applications. Cela signifie qu’elles doivent être en mesure de récupérer leur état, leurs données et même la façon dont les clusters sont orchestrés. C’est pourquoi la sauvegarde des environnements Kubernetes est récemment devenue un sujet de première importance.

1. Ce qu’il faut sauvegarder : les containers avec leur environnement Kubernetes

Même dans le cas des premiers containers stateless, ceux qui sont conçus pour accomplir leur tâche, comme la manipulation d’un ensemble externe de données, puis disparaître, il est utile de sauvegarder l’ensemble du container. Dans tous les cas, une entreprise voudra probablement être en mesure de régénérer le container dans l’état le plus proche de celui qu’il avait avant l’incident, c’est-à-dire soit avec les données en cours de traitement, soit avec le lien pour y accéder dans Kubernetes. Ne pas protéger l’orchestration soulève le risque réel que le processus métier – ou l’application – ne puisse pas être reconstruit après une panne.

Protéger les clusters d’applications orchestrés par Kubernetes signifie aussi protéger tous les clusters : ceux sur site, qu’ils fonctionnent sous Linux ou Windows, et ceux en cloud, qu’ils reposent sur une infrastructure IaaS ou qu’il s’agisse de services Kubernetes prêts à l’emploi, comme chez Google GCP, Amazon AWS et Microsoft Azure. En effet, ces clusters sont susceptibles de tous fonctionner ensemble ; c’est le principe du cloud hybride.

Selon Christophe Bertrand, analyste au bureau ESG, les entreprises doivent élaborer une politique de sauvegarde qui inclut les containers de développement et de production. Les outils de protection des données doivent donc reconnaître l’environnement Kubernetes. Il faudra aussi prendre en compte dans les règles de sauvegarde le cas d’un container ou de tout un cluster qui passe de la phase de développement à celle de la production.

2. Les éléments de Kubernetes à protéger

Dans le détail, les composants d’état d’un cluster Kubernetes sont conservés dans sa base de clés etcd. Cette base etcd est donc la partie la plus critique, car c’est elle qui fait le lien entre les containers et le stockage local. Et c’est aussi elle qui enregistre l’état global de l’environnement.

Le deuxième élément à sauvegarder est bien entendu les applications, c’est-à-dire leurs « pods », à savoir leurs containers accompagnés des fichiers de configuration qui stipulent leur adresse IP, leurs ressources de stockage, leur manière d’être exécutés, etc.

Le troisième élément à protéger est l’ensemble des volumes de stockage persistants, avec leurs droits d’accès.

Enfin, il restera à sauvegarder les fichiers de configuration qui définissent les ressources accessibles, les noms de domaine et les dépôts depuis lesquels récupérer les images des containers.

Dans un environnement Kubernetes, les nœuds-serveurs sont censés être simples à redémarrer. Cependant, les équipes informatiques doivent toujours vérifier en amont qu’elles savent le faire après tout type de panne, surtout si cette panne a eu lieu sur du matériel local qui sert à exécuter des clusters Kubernetes.

3. Les méthodes pour sauvegarder les environnements Kubernetes

En termes de solutions sur étagères, ne sont utilisables que les logiciels de sauvegarde spécialement dédiés à Kubernetes, ou ceux spécifiquement mis à jour pour prendre en charge les containers et l’orchestrateur. Citons le service SaaS Metallic de Commvault, par exemple, qui fournit des sauvegardes complètes et incrémentielles de clusters Kubernetes. Il est improbable que les solutions de sauvegarde traditionnelles parviennent à générer assez fréquemment des copies, ou qu’elles prennent en compte suffisamment d’éléments fonctionnels, pour protéger convenablement un cluster Kubernetes.

Sans solution sur étagère, les administrateurs peuvent utiliser des tâches Cron pour créer des snapshots d’etcd, afin de capturer les configurations et les données à un instant T. Ces snapshots permettent alors de recréer un déploiement Kubernetes complet à partir de dépôts Git contenant toutes les ressources. Ces snapshots constituent aujourd’hui le principal moyen de sauvegarde dans les environnements Kubernetes de production.

Notons qu’il existe un outil open source, kube-backup, qui exporte les ressources configurées dans un cluster Kubernetes vers un dépôt Git. Cette approche est cependant peu susceptible d’être utilisable dans des environnements qui évoluent sans cesse. De plus, kube-backup a le défaut de ne pas prendre en compte les volumes persistants.

4. Les principaux outils de sauvegarde de Kubernetes

La plupart des grands fournisseurs de stockage prennent désormais en charge la protection des containers eux-mêmes, en tant qu’instances. La sauvegarde d’environnements Kubernetes complets repose en revanche sur des outils spécialisés.

Commvault prend en charge Kubernetes par le biais de son service en ligne Metallic VM & Kubernetes Backup. Cette solution SaaS fonctionne en ligne avec les services Kubernetes Azure AKS et Amazon EKS, ainsi que sur site avec les distributions Kubernetes Red Hat OpenShift et VMWare Tanzu.

Kasten, qui édite une solution de gestion des contenus Kubernetes, est désormais la propriété de Veeam. Son application K10 fonctionne dans le cloud et sur site.

Portworx PX-Backup peut sauvegarder des containers, des clusters ou des espaces de noms Kubernetes entiers. Le fournisseur appartient désormais à Pure Storage.

TrilioVault de Trilio est une application de protection des données native du cloud qui fonctionne avec OpenShift de Red Hat et la version communautaire de Kubernetes. Cette solution est censée être compatible avec tous les services Kubernetes qui fonctionnent en cloud.

L’outil Velero (anciennement Heptio ARK) peut sauvegarder et récupérer les clusters Kubernetes ainsi que le stockage persistant, à la fois sur site et dans le cloud.

5. Intégrer les sauvegardes Kubernetes dans les processus de PRA existants

Construire une infrastructure de sauvegarde et de récupération entièrement nouvelle pour Kubernetes demandera beaucoup de ressources et posera le risque, comme dans tout nouveau projet, que des lacunes de protection persistent jusqu’à ce qu’on les découvre.

« Si votre fournisseur de sauvegarde habituel a une solution, alors cela vaut la peine de la tester car elle simplifiera le processus d’intégration de Kubernetes à votre PRA. Mais attention à bien vérifier qu’elle supporte l’élasticité de votre déploiement », conseille Christophe Bertrand.

Si ce n’est pas le cas, les DSI devraient plutôt opter pour un outil de sauvegarde supplémentaire et entièrement dédié à Kubernetes plutôt que vers une nouvelle solution qui promet de tout sauvegarder. Christophe Bertrand estime en effet que le marché n’en est encore qu’à ses balbutiements dans ce domaine et que les offres sont susceptibles de considérablement évoluer dans les semaines ou les mois à venir.