Sauvegarde & Kubernetes : Pourquoi et comment ?

<< retour au blog

Sauvegarde &#038; Kubernetes : Pourquoi et comment ?

22 septembre 2021
6 mn de lecture

Nous traitons régulièrement de la gestion des sauvegardes lors de nos projets, que ce soit pour des environnements physiques, virtuels ou cloud. Récemment un client m’a demandé « Est-ce qu’il faut également que je sauvegarde mes environnements Kubernetes ? Si oui, que faut-il faire, comment et avec quelle solution ? »

Ces questions, et les réponses que nous avons pu lui apporter, m’ont inspiré pour rédiger un article. Non seulement le sujet est intéressant, mais je pense que notre client n’est pas le seul à se poser la question. A travers cet article, je vous explique le tout !

Pourquoi sauvegarder ?

Avant de parler plus spécifiquement de la sauvegarde d’environnements Kubernetes, il est nécessaire de faire un rappel des objectifs de la sauvegarde.

Les sauvegardes sont utilisées pour remonter dans le temps afin de répondre principalement à deux objectifs :

  • Pallier la corruption ou la perte de données causées par diverses causes (pannes matérielles, bugs logiciels, erreurs humaines, attaques virales…).
  • Répondre aux contraintes légales de conservation des données.

Les sauvegardes peuvent également être utilisées pour d’autres aspects de disponibilité comme pour un PSI (Plan de Secours Informatique) par exemple, à condition que le RPO (Recovery Point Objective) et le RTO (Recovery Time Objective) correspondent aux attentes des métiers.

 

 

Évidemment, inutile de souligner que dans le contexte actuel, où les attaques virales sont de plus en plus présentes, la bonne sécurisation des données sauvegardées devient de plus en plus essentielle. Cela passe notamment par une bonne isolation réseau, gestion des comptes à privilèges, diminution de la surface d’attaque ou encore l’utilisation de fonctionnalités de type Object lock (création de copies immuables).

Il est important de rappeler que la base de tout cela est la définition d’une politique de sauvegarde ! Et que sauvegarder, c’est bien, mais être capable de restaurer c’est encore mieux !

Environnement Kubernetes : Que faut-il sauvegarder ?

 Revenons au sujet qui nous intéresse : la sauvegarde des environnements Kubernetes

Malgré tous les avantages sus cités ; automatisation, scalabilité, disponibilité…, Kubernetes ne permet pas nativement d’assurer un niveau de protection des données correspondant aux exigences des entreprises. Mais alors comment sauvegarder correctement nos applications ?

Même si à l’origine la majorité des applications conteneurisées étaient « stateless », notamment pour simplifier leur mobilité et leur scalabilité (vers le haut et vers le bas), la donnée a changé depuis. En effet, aujourd’hui, l’exécution d’applications « stateful » sur Kubernetes n’est plus un mythe car les solutions de gestion du stockage sont désormais matures.

Il est donc important de comprendre que la description d’une application déployée sur Kubernetes va inclure différents éléments : la configuration de l’application, les ressources Kubernetes utilisées, et les données.

 

 

Afin d’avoir une sauvegarde cohérente, vous aurez donc besoin de sauvegarder tous ces éléments.

    • App configuration

Pour ce qui est de la configuration des applications, elle peut provenir de plusieurs sources :

  • Directement incluse dans la ou les images de conteneurs utilisées : pensez donc à sauvegarder vos images et les fichiers de description associés ! Sachant que j’imagine que vos images sont stockées sur un registre (Harbor, Dragonfly,Azure Registry, Amazon ECR…) et que vos fichiers sur un gestionnaire de code (Github, Gitlab, Azure DevOps…). Enfin, j’espère que l’ensemble est sauvegardé !
  • Ou dans des ressources Kubernetes de type ConfigMap ou Secret par exemple K8S ressources.

 

    • K8S ressources

Au-delà de ces ressources utiles à la configuration de l’application, d’autres ressources peuvent être utilisées dans l’architecture de l’application. Ci-dessous un exemple d’architecture applicative :

Sans refaire une formation sur Kubernetes, l’état de ces différentes ressources, et plus largement de l’état global du cluster, sont détenues dans la base de données Kubernetes : etcd !

Il « suffit » donc de sauvegarder cette base de données. Cela est possible manuellement en créant un snapshot de la base via la commande etcdctl snapshot save db.

Pour autant, nous allons voir que des solutions permettent d’éviter de le faire manuellement.

    • Data

Pour rappel, afin d’en conserver leur état, des volumes persistants sont utilisés, soit pré-provisionnés ou provisionnés automatiquement.

Il y a évidemment plusieurs méthodes pour provisionner des Persistent Volumes mais également plusieurs possibilités quant aux types de stockage et protocoles que l’on peut utiliser, que nous n’allons pas détailler dans cet article.

Pour autant, peu importe le type de stockage utilisé, une problématique bien connue reste présente lorsqu’on sauvegarde : la consistance !

En effet, l’idéal est que la solution de sauvegarde soit en mesure de comprendre l’application qui utilise ce PersistentVolume, puis de discuter avec elle afin d’éviter un arrêt de service pour être sûr d’avoir une sauvegarde consistante.

Pour résumer simplement, plusieurs éléments doivent être sauvegardés dans un environnement Kubernetes :

  • Les images et les fichiers associés
  • La base etcd du cluster Kubernetes
  • Les données se trouvant dans les PersistentVolumes

Dans le cas où vous auriez besoin de reconstruire votre cluster K8S, il est important de rappeler que la conservation de la configuration liée au déploiement et son écosystème (LB, ingress, IAM…) est indispensable.

Ok, on doit sauvegarder un environnement Kubernetes, mais avec quelle solution ?

Les environnements basés sur des conteneurs et Kubernetes sont très différents des environnements « legacy », comme ceux basés sur des hyperviseurs et des machines virtuelles. C’est pourquoi, comme à chaque évolution, on retrouve les acteurs « traditionnels » de la sauvegarde essayant d’adapter leur solution, et les nouveaux, qui eux construisent des solutions « from scratch ».

Sur ce marché, on peut donc principalement distinguer 3 catégories de solutions :

  • Les solutions « traditionnelles », supportant les environnements Kubernetes
  • Les solutions de stockage Cloud-Native, offrant des fonctionnalités de protection de données
  • Les solutions de sauvegarde Cloud-Native, spécialement conçues pour ces environnements

Nous ne traiterons pas des possibilités de protection de données via des snapshots directement réalisés sur les baies de stockage hébergeant les PersistentVolumes.

Pourquoi ? Principalement pour des raisons de granularité de sauvegarde et restauration, généralement à la granularité d’un LUN/volume complet, ce qui ne répond que peu aux besoins des utilisateurs.

Afin de présenter les acteurs du marché appelé « Kubernetes data protection », je propose de faire référence à une étude comparative réalisée par Enrico Signoretti, fin 2020 « Gigaom radar kubernetes data protection« . Même si cette étude serait à mettre à jour sur certaines nouvelles fonctionnalités, elle permet de mieux comprendre les possibilités des principales solutions.

Elle compare 12 solutions comme le montre le radar ci-après :

Les solutions les plus proches du centre, sont considérées comme celles avec la valeur la plus élevée (maturité, innovation, fonctionnalités, compatibilité).

Quelques points importants à noter sur les solutions les plus centrales :

Aucune solution « traditionnelle » n’est présente même si la solution Commvault s’y approche. L’éditeur a commencé dès 2017 à s’intéresser à Kubernetes et tire vraiment son épingle jeu comparé aux autres solutions « traditionnelles »

  • La solution Portworx, rachetée par PureStorage, est à l’origine une solution de stockage Cloud-Native offrant des fonctionnalités de protection de données. A noter que la version open source reste limitée.
  • La solution Robin est également une solution de stockage Cloud-Native, Cependant, aujourd’hui, les fonctionnalités de protection de données ne sont pas complètement intégrées à la solution de stockage.
  • Les solutions Kasten (rachetée par Veeam) et Trilio sont quant à elles des solutions de sauvegarde conçues pour des environnements Kubernetes.
  • La solution Velero (anciennement Heption ARK), solution opensource mais principalement maintenue par les équipes VMware, fait partie intégrante des distributions Kubernetes VMware (vSphere7 with K8S, TKG, TKI)

Évidemment, l’ensemble des solutions offrant des fonctionnalités de protection de données n’ont pas été étudiées. En effet, plusieurs solutions présentes dans la catégorie « Cloud Native Storage » de la CNCF landscape possèdent ce genre de fonctionnalités.

On peut également noter l’absence de certains acteurs tels que Cohesity ou Rubrik, solutions bien connues dans le monde de la sauvegarde, qui offrent une compatibilité avec des environnements Kubernetes.

 

Hmm, quelle solution ?

Encore une fois, comme plusieurs domaines du monde Cloud-Native, le marché est encore diffus, ce qui rend complexes les choix.

Solution mature ? Solution innovante ? Des fonctionnalités du type « Data management » ?

Comme pour chaque choix, la question à laquelle il vous faudra répondre pour retenir la solution la plus adaptée est : « Quels sont mes besoins ? ».

Les solutions de sauvegarde Cloud-Native, comme Kasten par exemple, restent les solutions les plus avancées et offrant les fonctionnalités les plus avancées, notamment grâce à leur meilleure compréhension du contexte.

En tout cas, ce qui est sûr, c’est que :

Votre environnement Kubernetes doit être sauvegardé !

En l’occurrence pour le client cité en introduction, le choix a été fait de partir sur la solution Kasten afin de sauvegarder l’ensemble de ces environnements. Pourquoi ?

Principalement pour les raisons évoquées précédemment, mais également car il utilise déjà la solution Veeam B&R pour la sauvegarde de ces autres environnements (physiques, virtuels et cloud), et qu’il en est satisfait. Kasten ayant été racheté par Veeam, le client fait également le pari d’une mutualisation de l’ensemble des consoles au sein d’une seule et unique interface #SPOG.

 

Adrien Huerre
Responsable de l’offre Cloud & Infrastructure Moderne de Data center