Les 10 acteurs clés de la sauvegarde sous Kubernetes

Les containers – et l’orchestration de containers, le plus souvent via Kubernetes – changent la façon dont les entreprises développent et exécutent leurs applications. Les architectures containerisées permettent aux entreprises de développer, déployer et décommissionner des applications rapidement. En outre, les applications containerisées sont plus facilement transférables entre le cloud et les systèmes sur site. Pour certaines entreprises, il s’agit là de leur principal avantage.

Mais à mesure que les entreprises utilisent plus largement les applications containerisées, elles s’en servent aussi pour gérer des données plus critiques – et ces données doivent être sauvegardées.

L’un des arguments en faveur des containers est qu’aucune sauvegarde n’est nécessaire, car l’architecture est « sans état » (ou « stateless » en anglais). Cela signifie que, idéalement, chaque application fonctionne avec des données qu’elle n’apporte ni n’enregistre elle-même : elle envoie des requêtes à des services tiers (le plus souvent de stockage objet S3) pour qu’ils modifient ces données. Les données évoluent, ailleurs, mais l’application déployée demeure durant toute son activité telle qu’elle a été conçue par le développeur, il n’y a aucune raison d’en faire une sauvegarde.

Bien entendu, ces applications produisent elles-mêmes des informations de fonctionnement, qui leur permettent de savoir où elles en sont depuis leur initialisation et qui sont stockées dans la base etcd. Cependant, ces applications sont souvent conçues pour que leur instance en production ait une durée de vie très courte (la plupart fonctionnent moins d’une journée). Quand elles sont éteintes, une nouvelle copie leur succède, avec une base etcd vierge.

Cela fonctionne parfaitement bien pour le développement rapide d’applications et les opérations basées sur le Web. Mais à mesure que les entreprises placent les containers au cœur de leurs opérations et les utilisent potentiellement pour remplacer les applications traditionnelles, elles ont besoin d’un niveau de protection plus élevé. Cela signifie qu’il faut protéger leur base de données etcd et toutes les données (des fichiers…) que ces applications ont stockées de manière traditionnelle sur des volumes persistants.

« En général, les entreprises ne sauvegardent pas Kubernetes avec des outils conçus pour Kubernetes », explique Brent Ellis, analyste chez Forrester. « De nombreuses équipes sauvegardent avec des outils classiques la base de données de configuration etcd de leurs clusters, puis elles sauvegardent le stockage primaire dans lequel sont stockées les images de containers et toutes les références des volumes persistants dans les fichiers yaml. »

« Cela fonctionne très bien si vous avez un faible degré de complexité, avec des applications dont l’état n’évolue pas ou peu. Mais, globalement, vous avez besoin de la conscience applicative pour sauvegarder l’état d’une application. C’est-à-dire que vous devez savoir à quelle étape particulière d’une application il y aurait eu une transformation des données qui aurait précédé un incident. »

Ce besoin a conduit à deux approches principales pour la sauvegarde de Kubernetes : soit des produits dédiés à ce système, soit des outils de sauvegarde/restauration traditionnels qui prennent désormais en charge les environnements de containers en plus des ressources habituelles (serveurs virtuels, machines physiques). Cet article liste un aperçu des solutions du marché, il n’est en aucun cas exhaustif.

• Kasten K10

Kasten positionne son logiciel K10 comme une solution de gestion des données conçue pour Kubernetes. L’application s’exécute dans son propre espace de noms sur un cluster Kubernetes et prend en charge toutes les principales plateformes cloud, ainsi que les architectures sur site. L’outil recherche les composants qui doivent être sauvegardés, notamment les volumes de stockage persistants et les bases de données. Les utilisateurs peuvent définir leurs propres politiques de protection des données, de sauvegarde et de reprise après sinistre (PRA).

En 2020, le fournisseur de sauvegarde Veeam a racheté Kasten.io.

• Portworx

Portworx a été l’un des premiers fournisseurs à développer un système de stockage persistant pour les containers. Il est donc bien placé pour fournir aussi une sauvegarde des environnements Kubernetes. L’éditeur le fait par le biais de son logiciel PX-Backup, qui, selon ses dires, est « granulaire pour les containers et conscient des applications ». L’outil prend en charge le stockage par blocs, fichiers et objets, ainsi que le stockage en cloud. Il dispose d’outils de découverte et de provisionnement du stockage, ainsi que de fonctions de sauvegarde, de PRA, de sécurité et de migration.

Pure Storage a racheté Portworx en 2020.

• Velero 

Verelo est un outil Open source de sauvegarde, de restauration, de récupération et de migration pour Kubernetes. Il peut sauvegarder des clusters entiers, ou des parties d’un cluster en utilisant des espaces de noms ou en sélectionnant les étiquettes qui leur sont accolées. L’outil peut désormais également restaurer les groupes API Kubernetes par niveau de priorité. Velero s’appelait auparavant Heptio Ark.

Bien que Velero soit Open source, il est soutenu par VMWare, et le fournisseur dispose d’un certain nombre de ressources Velero dans son centre de développement Tanzu.

• Red Hat OpenShift Container Storage (OCS)

Red Hat – qui fait désormais partie d’IBM – a introduit une importante prise en charge de Kubernetes dans sa gamme de fonctions de stockage en 2020, en remplacement des offres précédentes d’IBM.

Red Hat OpenShift Container Storage ajoute les outils de protection des données de l’éditeur aux environnements de containers, sans, dit Red Hat, technologie ou infrastructure supplémentaire. Les fonctionnalités comprennent des snapshots via l’interface de stockage des containers et des clones de volumes de données existants. On y trouve aussi, au sein des API OpenShift, la restauration des données et des applications dans les pods de containers, ainsi que la restauration des connexions entre les espaces de noms et les données persistantes.

L’ensemble d’outils peut par ailleurs s’interfacer avec des outils de sauvegarde tiers, comme Spectrum Protect Plus d’IBM, TrilioVault et Kasten K10.

• NetApp Astra Data Store

Astra Data Store de NetApp est un service de fichiers pour les containers et les machines virtuelles basé sur un client NFS standard. Astra est censé simplifier et rendre plus efficace le stockage dans les containers et les machines virtuelles. Il permet aux entreprises d’utiliser le même pool de stockage et les mêmes outils de sauvegarde dans les deux architectures.

NetApp a mis à jour son logiciel Astra Control au début de l’année pour prendre en charge d’autres plateformes Kubernetes, notamment Rancher et les implémentations libres de Kubernetes. Il utilise les technologies historiques de NetApp pour la protection des données, le PRA et la migration.

• Rancher Backup

Le système de stockage Rancher fournit son propre outil de sauvegarde et de restauration à partir de sa version 2.5. Le module, l’app Rancher Backup, doit être installé dans le cluster Kubernetes local. L’interface utilisateur permet les sauvegardes de etcd et du cluster, y compris au moyen de snapshots. Les sauvegardes peuvent être stockées localement ou sur un service cloud compatible S3.

• TrilioVault

Trilio positionne son outil TrilioVault comme une protection des données en cloud pour Kubernetes. Trilio affirme prendre en charge le type d’application à sauvegarder et dispose d’un large éventail de fonctions particulières, que ce soit pour la plateforme Kubernetes ou pour un service en cloud. L’outil utilise les API de base de Kubernetes et son pilote CSI, tandis que la console de gestion prend en charge la découverte des applications et la gestion des règles de sauvegarde, de restauration et de PRA. L’outil prend également en charge les snapshots.

TrilioVault est certifié pour une série de déploiements, notamment sur HPE, VMWare Tanzu et Rancher.

• Cohesity

Cohesity présente lui aussi son outil de sauvegarde Helios comme un service cloud-native pour les containers. Le fournisseur propose de sauvegarder sur AWS, Azure ou Google GCP les états des containers, les volumes persistants et les métadonnées opérationnelles des applications. La prise en charge multicloud signifie que les sauvegardes et les restaurations peuvent aller d’un cloud public à l’autre, pour une résilience supplémentaire.

Les outils de Cohesity offrent également des clones à coût nul afin que les équipes DevOps puissent utiliser les données de sauvegarde pour le développement d’applications.

• Veritas NetBackup

Le logiciel NetBackup de Veritas prend désormais en charge des fonctions de sauvegarde, de restauration et de continuité d’activité adaptées à Kubernetes. Outre les sauvegardes standards, Veritas propose la protection contre les ransomwares, via des sauvegardes immuables sur AWS S3, et la gestion des données Kubernetes avec reprise après sinistre intégrée. Veritas affirme également que ses outils permettent aux utilisateurs de passer d’une distribution Kubernetes à l’autre pour une approche de type « sauvegarde unique, restauration et transfert n’importe où ».

• Cloudcasa

Cloudcasa de Catalogic est relativement inhabituel sur le marché, car il fonctionne comme un service de sauvegarde à la demande. Il fournit une restauration au niveau du cluster à partir de snapshots gratuitement conservés pendant 30 jours. À cela s’ajoutent des options payantes, notamment des sauvegardes Kubernetes Persistent Volume (PV). Cloudcasa prend en charge les snapshots d’Amazon EBS et ceux faits au niveau du pilote CSI.