Cinq questions clés sur kubernetes sauvegarde répondu

L’écart de sauvegarde

Les conteneurs existent dans un blackspot de secours. Ils sont souvent gérés par les équipes DevOps, et en tant que technologies temporaires ou basées sur le cloud, ils peuvent ne pas être visibles par les spécialistes de sauvegarde et de récupération des équipes informatiques.

Les outils conventionnels qui permettent de récupérer des machines virtuelles ne conviennent pas le mieux aux conteneurs, qui peuvent fonctionner dans une gamme d’endroits, localement et dans le cloud. Les outils de sauvegarde des machines virtuelles (VM), par exemple, sont toujours conçus pour sauvegarder les disques et les volumes.

« Vous pourriez avoir des données très, très critiques générées par ces applications fonctionnant dans des conteneurs », explique Christophe Bertrand, analyste chez ESG. « Le fait que cela soit sur le point de devenir la plate-forme de production de choix souligne la nécessité d’excellentes capacités de sauvegarde et de récupération. »

Ici, nous brisons cinq des considérations les plus importantes pour la protection de l’infrastructure Kubernetes.

1. Avez-vous toujours besoin de récupérer des conteneurs et des Kubernetes?

La réponse aujourd’hui est presque toujours oui. Les conteneurs apatrides antérieurs ont été conçus pour accomplir leur tâche, comme gérer un ensemble de données, puis disparaître. Ces cas d’utilisation existent toujours, mais une entreprise est susceptible de vouloir être en mesure de recréer le conteneur ou le cluster après une panne et être en mesure d’accéder à ses données.

Selon M. Bertrand, les organisations ont besoin d’une politique de sauvegarde forte qui soutienne les conteneurs de développement et de production. Les outils de protection des données doivent reconnaître l’environnement kubernetes et, par exemple, ajuster la politique si un conteneur ou un cluster est promu du développement à la production.

2. Que devez-vous protéger à Kubernetes?

Au plus haut niveau, les utilisateurs de conteneurs doivent protéger leurs clusters orchestrés. Cela inclut les opérations sur place, sous Linux ou Windows, dans le cloud, et à travers toutes les instances gérées de plate-forme Kubernetes en tant que service (PaaS), y compris celles de Google, Amazon Web Services ou Microsoft Azure. Ne pas protéger l’orchestration augmente le risque réel que le processus d’affaires ou l’application ne puisse pas être reconstruit après un échec.

Dans un cluster, les composants stateful sont maintenus dans la base de données de valeur clé etcd, de sorte que le plan de contrôle etcd est la partie la plus critique car il relie le stockage persistant aux conteneurs ainsi que l’enregistrement de l’état de l’environnement.

L’organisation doit ensuite protéger les applications, y compris les pods, les déploiements, les statefulsets et les charges de travail.

Les volumes persistants doivent être protégés, tout comme les demandes de volume persistantes. Enfin, les entreprises doivent prendre en compte les définitions de ressources personnalisées, les définitions d’espace nominatif et les registres d’images de conteneurs qui s’exécutent à l’intérieur de Kubernetes.

Les nœuds des travailleurs sont conçus pour tourner facilement, mais les équipes informatiques doivent vérifier qu’elles peuvent le faire en production après une panne, surtout si elles exécutent des conteneurs sur du matériel local.

3. Quelles sont les principales méthodes pour faire reculer les environnements Kubernetes?

Les principales méthodes de sauvegarde kubernetes sont les outils spécialisés, ou les applications de sauvegarde d’entreprise qui ont été mises à jour pour prendre en charge les conteneurs et les Kubernetes. Les outils de sauvegarde conventionnels sont peu susceptibles de faire des copies assez fréquentes, ou ont la portée à travers les systèmes pour capturer tous les états dans un environnement de production Kubernetes.

Au niveau le plus bas, les développeurs peuvent être en mesure d’utiliser les travaux Cron pour créer des instantanés d’etcd, pour capturer des configurations et des données. Un déploiement Kubernetes pourrait même être recréé à partir de repos git.

L’outil open source kube-backup exporte des ressources Kubernetes configurées vers un référentiel git, bien qu’il s’agit d’une approche qui est peu susceptible d’être mise à l’échelle. Il ne traitera pas non plus des volumes persistants.

Les instantanés, cependant, sont le principal outil pour environnements Kubernetes. C’est toutefois la fréquence qui distingue la sauvegarde du conteneur des autres outils. Metallic de Commvault, par exemple, fournit des sauvegardes complètes et incrémentielles. Le fournisseur décrit son approche comme des « sauvegardes incrémentielles pour toujours », qui peuvent être utilisées pour construire une sauvegarde complète.

S’assurer que les données critiques sont stockées à l’extérieur du disque local d’un nœud rendra également la récupération plus fiable.

4. Quels sont les principaux outils de sauvegarde Kubernetes?

La plupart des grands fournisseurs de stockage soutiennent maintenant la protection des conteneurs sous une forme ou une autre. La sauvegarde pour des environnements Kubernetes entiers repose davantage sur des outils spécialisés.

Commvault soutient Kubernetes à travers son logiciel en tant que service (SaaS) basé sur Metallic VM & Kubernetes Backup. Cela fonctionne avec Azure AKS et Amazon EKS, ainsi que Red Hat OpenShift et VMWare Tanzu.

Kasten est un fournisseur de gestion de données Kubernetes, aujourd’hui propriété de Veeam. Son application K10 fonctionne dans le cloud et sur place.

Portworx PX-Backup peut sauvegarder des conteneurs, des clusters ou des espaces nominatifs Kubernetes entiers. Le fournisseur appartient maintenant à Pure Storage.

TrilioVault de Trilio est une application de protection des données native du cloud qui fonctionne avec OpenShift et Kubernetes, et est agnostique de plate-forme cloud.

L’outil OS Velero (précédemment Heptio ARK) peut récupérer les clusters Kubernetes ainsi que le stockage persistant, sur place et dans le cloud.

5. Comment intégrer la sauvegarde Kubernetes dans les processus existants de récupération et de sauvegarde en cas de catastrophe ?

La construction d’une toute nouvelle infrastructure de sauvegarde et de récupération pour Kubernetes peut être gourmande en ressources et risque de laisser des lacunes dans la protection.

« Si votre fournisseur de sauvegarde titulaire a une solution, alors il vaut la peine de le vérifier car il simplifie le processus, mais en s’assurant qu’il fonctionne à l’échelle », conseille Bertrand ESG. « Cela aidera à [disaster recovery] si la sauvegarde de conteneurs natifs peut être intégrée à la RD existante.

Si ce n’est pas le cas, les DSI devraient examiner la protection des Kubernetes indigènes comme la plus robuste. Mais le marché évolue rapidement, note M. Bertrand, avec un plus grand nombre de fournisseurs qui construisent plus de capacités. Comme Kubernetes devient plus grand public, la protéger dans la production devrait devenir plus facile.