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 !
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 :
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 !
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 :
K8S ressources
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 :
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 donc 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 :
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.
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 »
É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.
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 :
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, Directeur des opérations
