Quantifier et répondre aux défis spécifiques de la sauvegarde de Kubernetes

Le Google Cloud offre peut-être le meilleur aperçu de l'omniprésence que Kubernetes pourrait prendre dans les entreprises.
Écrit par :
Subbiah Sundaram
Publié le :

Sommaire exécutif

Presque toutes les entreprises s'attendent, au cours des prochaines années, à introduire et à adopter Kubernetes dans leur environnement de production.

Ces mêmes entreprises reconnaissent également que le passage de Kubernetes en production exige qu'il réponde aux mêmes normes que leurs autres applications de production. Parmi ces exigences, elles doivent disposer d'un moyen de sauvegarder et de récupérer les applications conteneurisées qu'elles hébergent dans Kubernetes.

D'un point de vue positif, il existe des points communs entre la sauvegarde des applications conteneurisées et celle des VM. Toutes les applications sont virtuelles, il existe des API pour effectuer des sauvegardes et les données de sauvegarde sont toujours constituées de uns et de zéros à la base. Il est donc possible de sauvegarder et de stocker les sauvegardes des applications conteneurisées et des VM dans les mêmes chambres fortes de sauvegarde.

Cependant, la sauvegarde des applications conteneurisées dans Kubernetes présente cinq défis distincts. Il s'agit notamment de :

  1. Protéger les données temporelles et le stockage des applications conteneurisées
  2. Gérer la nature imprévisible des applications conteneurisées
  3. Répondre à la dynamique des environnements Kubernetes en évolution rapide
  4. Fournir toute l'étendue des capacités de sauvegarde nécessaires pour Kubernetes
  5. Créer des restaurations fiables à partir d'un environnement Kubernetes de production en constante évolution

Pour répondre à ces cinq défis des sauvegardes Kubernetes, toute solution de sauvegarde doit capitaliser sur les caractéristiques spécifiques de Kubernetes. Au premier rang de celles-ci, elle doit utiliser les métadonnées associées à chaque application conteneurisée. De cette façon, elle peut quantifier si elle doit sauvegarder l'application conteneurisée et, le cas échéant, comment la sauvegarder au mieux.

Elle doit ensuite utiliser ces étiquettes de métadonnées à des fins multiples. Au minimum, il doit les utiliser pour identifier de manière unique quelle sauvegarde est laquelle. Elle doit également coordonner les sauvegardes sur plusieurs conteneurs afin de pouvoir synchroniser des restaurations fiables, si nécessaire.

Enfin, les entreprises auront besoin d'une solution de sauvegarde fournie sur une architecture cloud-native pour s'adapter dynamiquement à un environnement Kubernetes en constante évolution. Idéalement, la solution de sauvegarde sera également fournie en tant que service et gérera à la fois les sauvegardes d'applications conteneurisées et de VM.

HYCU répond à ces défis spécifiques des sauvegardes Kubernetes. Elle répond aux besoins continus des entreprises de protéger leurs environnements virtualisés tout en les positionnant pour sauvegarder leur nouvel environnement Kubernetes. Elles sont ainsi en mesure de gérer les sauvegardes d'applications conteneurisées et de machines virtuelles de la même manière, avec un minimum de perturbations opérationnelles, voire aucune.

Le futur, c'est Kubernetes

L'une des plus grandes transformations de l'histoire de l'informatique semble sur le point de se produire. Dans cette itération, les organisations se concentrent moins sur le matériel, les logiciels, la mise en réseau, la virtualisation ou les technologies cloud qu'elles utilisent. Au contraire, elles peuvent déployer des applications conteneurisées sur n'importe quelle plateforme cloud dans n'importe quel environnement.

Cette vision est sur le point de devenir une réalité.

Le déploiement d'applications conteneurisées gérées par Kubernetes hébergées sur des plateformes natives du cloud met cet idéal à portée de main.

En adoptant ces technologies de nouvelle génération, les organisations peuvent :

  • Accélérer et raccourcir le développement et le déploiement des applications
  • Aligner le placement des applications sur les plateformes cloud avec leurs besoins en termes d'activités, de coûts, de performances, de coûts, de performances et de ressources
  • Mieux prévoir les coûts et les besoins en ressources futurs
  • Héberger des applications sur n'importe quelle plateforme cloud à tout moment
  • Augmenter ou réduire l'infrastructure informatique à la demande
  • Utiliser moins de ressources informatiques pour développer et héberger des applications
  • Utiliser et réutiliser les ressources informatiques disponibles de manière plus efficace

Ces avantages incitent de nombreuses entreprises à considérer ces technologies comme l'avenir des technologies de l'information. Parmi elles, les entreprises prévoient spécifiquement d'utiliser Kubernetes pour coordonner et orchestrer les charges de travail et les services conteneurisés dans plusieurs environnements cloud.

Une enquête réalisée en juin 2020 par la Cloud Native Computing Foundation a révélé que 78 % de ses membres utilisent déjà Kubernetes sous une forme ou une autre. Une autre enquête a révélé que 64 % des professionnels de l'informatique d'entreprise ont déjà déployé Kubernetes sur site.

Le Google Cloud offre peut-être le meilleur aperçu de l'omniprésence que Kubernetes pourrait prendre dans les entreprises. Google exécute déjà toutes ses applications sur des conteneurs au sein de son nuage lançant des milliards de conteneurs chaque semaine. Il utilise Kubernetes pour déployer, gérer, exploiter et orchestrer le déploiement d'applications conteneurisées au sein de son cloud.

Pour que cette vision devienne réalité, les entreprises doivent déployer une infrastructure qui protège ces applications conteneurisées et leurs données. Dans le cadre de cette infrastructure émergente, de nombreuses entreprises ont besoin d'une solution de sauvegarde en place avant d'adopter officiellement Kubernetes. Idéalement, elles espèrent utiliser le même logiciel pour sauvegarder leur environnement virtuel existant et leur nouvel environnement Kubernetes.

Commonalités dans les caractéristiques de sauvegarde

Les conteneurs et les machines virtuelles (VM) partagent plusieurs caractéristiques qui permettent aux entreprises d'envisager l'utilisation d'une solution unique pour protéger les deux.

Trois caractéristiques qui se distinguent :

  • Les conteneurs et les VM sont tous les deux virtuels. Les conteneurs et les machines virtuelles fonctionnent indépendamment de la plate-forme qui les héberge. Un logiciel de sauvegarde conçu de manière appropriée peut traiter et protéger à la fois les conteneurs et les VM en tant qu'objets.
  • API disponibles. Les plateformes Kubernetes et d'hyperviseur sous-jacentes qui hébergent les conteneurs et les VM offrent des API. Le logiciel de sauvegarde interagit avec ces API pour effectuer des tâches telles que la prise d'instantanés de conteneurs ou de VM individuels.
  • Les données sont des données. Que les entreprises hébergent leurs données dans des conteneurs ou des VM, les données restent des données. Les logiciels de sauvegarde stockent et gèrent toutes les données de sauvegarde essentiellement de la même manière, quelle que soit leur origine.

Malgré ces similitudes et d'autres, les logiciels de sauvegarde doivent gérer les sauvegardes et les restaurations de conteneurs différemment des sauvegardes de VM.

Les cinq défis de la sauvegarde Kubernetes

Les logiciels de sauvegarde doivent relever cinq défis spécifiques que la sauvegarde et la récupération de conteneurs dans Kubernetes créent.

1. Stockage éphémère

Le déploiement d'applications conteneurisées dans Kubernetes diffère de manière significative du déploiement d'applications sur des VM. Si une application ou sa VM hôte s'arrête, les données de l'application et le stockage de la VM persistent. Ainsi, la prochaine fois que l'application au sein de la VM ou que la VM démarre, elle peut accéder aux données ou au stockage qui lui ont été alloués.

Kubernetes gère différemment les données et les ressources de stockage associées aux applications conteneurisées et à leurs pods. Une fois qu'une application ou un pod s'arrête, Kubernetes récupère automatiquement ses ressources allouées, pour inclure son stockage. Une fois récupérées, les données associées à cette application ou à ce module sont effectivement "perdues".

Cela crée un double défi du point de vue de la sauvegarde.

D'abord, le logiciel de sauvegarde doit être informé de l'existence de l'application conteneurisée.

Deuxièmement, les applications conteneurisées peuvent n'exister que pendant une courte période. Par conséquent, on ne peut pas programmer des sauvegardes quotidiennes et s'attendre à ce qu'elles protègent les données de ces applications. Les sauvegardes doivent avoir lieu pendant la durée d'existence de l'application conteneurisée.

2. imprévisibilité

La flexibilité qu'offre Kubernetes pour démarrer des conteneurs n'importe où et à n'importe quel moment sur presque n'importe quel cloud renforce son attrait pour les entreprises. Cependant, cette même flexibilité introduit également des niveaux d'imprévisibilité et de complexité qui peuvent dépasser de loin les environnements avec VM.

Une solution de sauvegarde doit effectuer plusieurs tâches pour sauvegarder cet environnement. Elle doit d'abord relever les défis associés aux applications conteneurisées et à leur stockage éphémère. Elle doit également déterminer si elle doit sauvegarder chaque application conteneurisée, car tous les conteneurs ne nécessitent pas de sauvegardes.

Si elle doit sauvegarder l'application conteneurisée, elle doit utiliser la politique appropriée pour la sauvegarder. La politique déterminera la fréquence à laquelle la solution doit sauvegarder l'application. Une sauvegarde peut être effectuée une seule fois, par exemple juste avant l'arrêt de l'application conteneurisée. La solution de sauvegarde doit disposer de ressources suffisantes pour détecter toutes les applications conteneurisées, planifier les tâches de sauvegarde et les gérer. La solution doit également posséder des ressources suffisantes pour effectuer la gestion des données de sauvegarde en arrière-plan et réaliser des restaurations.

Déployé dans des infrastructures cloud, Kubernetes exacerbe encore les défis en matière de sauvegarde. Le nombre d'applications conteneurisées actives peut augmenter ou diminuer de façon spectaculaire, avec peu ou pas d'avertissement préalable.

Pour répondre à cet environnement et le gérer, la solution de sauvegarde doit s'y adapter automatiquement et de façon rentable. Au fur et à mesure que les applications conteneurisées démarrent, la solution de sauvegarde doit évoluer de manière dynamique. De même, lorsque les conteneurs sont mis hors ligne, la solution de sauvegarde doit évoluer dynamiquement à la baisse.

4. Étendue des capacités de sauvegarde Kubernetes

Le choix d'une solution de sauvegarde par une entreprise dépendra, en partie, de la maturité de son déploiement Kubernetes. Dans un environnement Kubernetes stable et plus mature, une entreprise écrit souvent des scripts qui automatisent le déploiement des composants Kubernetes de base. Dans ces environnements, une entreprise peut ne sauvegarder que ses applications conteneurisées hébergées dans son environnement Kubernetes.

En revanche, une entreprise qui a adopté Kubernetes plus récemment peut être confrontée à des défis de sauvegarde différents. Il se peut qu'elle n'ait pas encore fini de construire son environnement Kubernetes. Dans les deux cas, l'entreprise n'a probablement pas encore créé de scripts pour recréer sa place de contrôle Kubernetes. Par conséquent, elle aura besoin d'une solution dotée d'une plus grande étendue de capacités de sauvegarde. La solution devra sauvegarder à la fois le plan de contrôle Kubernetes et les applications et données conteneurisées.

5. Récupération

Alors que la sauvegarde des applications conteneurisées présente des défis, les récupérations des applications conteneurisées présentent des défis encore plus importants. Pour effectuer une récupération, le logiciel de sauvegarde doit d'abord associer chaque sauvegarde à une application, un utilisateur ou une autre constante environnementale spécifique.

Si une entreprise a besoin d'effectuer une récupération, elle doit disposer d'un moyen d'identifier la sauvegarde à récupérer. La nature temporelle des applications conteneurisées dans les environnements Kubernetes nécessite des procédures fiables pour lancer la récupération.

Dans le cadre de la récupération, une entreprise doit également déterminer l'étendue de la récupération dans l'environnement Kubernetes. Le logiciel peut n'avoir besoin de récupérer qu'une seule application conteneurisée. Cependant, des interdépendances peuvent exister et existent souvent entre plusieurs conteneurs. L'ampleur de la perte de données influencera également les composants Kubernetes que le logiciel de sauvegarde doit récupérer. Si un déploiement Kubernetes est compromis, le logiciel de sauvegarde peut également devoir récupérer le plan de contrôle Kubernetes.

Les entreprises doivent également tenir compte des exigences émergentes en matière de récupération des applications conteneurisées dans d'autres déploiements Kubernetes. De plus en plus d'entreprises utilisent des clouds hybrides avec différentes versions de Kubernetes s'exécutant dans chaque cloud. Lorsqu'elles effectuent des restaurations, elles peuvent vouloir récupérer des applications dans un nuage différent de celui où elles ont été sauvegardées à l'origine.

Les déploiements Kubernetes utilisés dans différents nuages possèdent de nombreuses similitudes. Cependant, des différences existent. Il faut s'assurer que la solution de sauvegarde prend en charge le déploiement Kubernetes dans n'importe quel cloud vers lequel ils pourraient avoir besoin de récupérer.

Répondre aux défis de la sauvegarde Kubernetes

Pour répondre à ces cinq défis associés à la sauvegarde des environnements Kubernetes, les entreprises doivent gérer les sauvegardes différemment. Ce changement dans la gestion des sauvegardes commence dans la façon dont les entreprises déploient les applications conteneurisées dans Kubernetes.

Utiliser efficacement les étiquettes des conteneurs
Toutes les applications conteneurisées peuvent facultativement posséder des métadonnées qui contiennent des étiquettes. L'utilisation de ces étiquettes devient obligatoire pour soutenir ces applications conteneurisées dans Kubernetes.

Chaque fois qu'une application conteneurisée démarre, elle doit s'enregistrer auprès du service de nœuds Kubernetes.

Lors de son enregistrement, trois événements se produisent.

  • Premièrement, le service de nœuds Kubernetes lit les étiquettes de métadonnées préexistantes du conteneur.
  • Deuxièmement, Kubernetes ajoute des paires de valeurs clés aux étiquettes du conteneur.
  • Troisièmement, ces valeurs clés permettent d'identifier les ressources d'application qui vont ensemble, car elles peuvent avoir besoin les unes des autres pour fonctionner.

Utiliser efficacement les étiquettes de conteneur

Une solution de sauvegarde doit capitaliser sur ces fonctionnalités. Elle surveille les démarrages de conteneurs Kubernetes et leur contenu en métadonnées. Le logiciel de sauvegarde utilise les métadonnées de chaque conteneur pour déterminer si, quand et comment il doit sauvegarder et récupérer les applications conteneurisées. Il crée et attribue les politiques de sauvegarde appropriées pour répondre à leurs besoins de récupération. Les sauvegardes sont ensuite synchronisées entre les applications conteneurisées qui dépendent les unes des autres dans la production. Pour ce faire, la solution de sauvegarde peut programmer une ou plusieurs tâches de sauvegarde dans le planificateur Kube. Le travail de sauvegarde sauvegardera alors ces applications conteneurisées et ses applications associées aux intervalles appropriés. Il peut également effectuer des sauvegardes lors d'événements spécifiques, tels que l'arrêt du conteneur.

Assigner des constantes aux sauvegardes

Pour réussir à récupérer une application conteneurisée, il faut que le logiciel de sauvegarde identifie exactement le moment où une sauvegarde d'application se produit. Pour ce faire, le logiciel de sauvegarde doit attribuer une ou plusieurs constantes environnementales à chaque sauvegarde. Les constantes environnementales affectées à la sauvegarde peuvent inclure un horodatage et des identifiants spécifiques de nœuds, de pods et de conteneurs. Les applications conteneurisées doivent résider dans un pod et les pods doivent exister avec un nœud. Cette combinaison de variables permet de classer de manière unique l'endroit et le moment où chaque sauvegarde d'application a eu lieu.

Architecture cloud-native

La mise à l'échelle pour répondre aux exigences de sauvegarde de milliers, de millions ou de milliards d'applications conteneurisées nécessite l'utilisation d'une architecture cloud-native. De cette manière, une solution de sauvegarde peut évoluer de manière efficace et rentable vers le haut ou vers le bas de manière dynamique pour sauvegarder les applications.

HYCU : A Cloud-native Solution for Kubernetes and VM Backups

Kubernetes crée une nouvelle norme selon laquelle les entreprises ont besoin de mesurer les solutions de sauvegarde. Si certains principes d'exécution des sauvegardes dans les environnements virtualisés s'appliquent à la protection des applications conteneurisées, il existe de nouvelles exigences en matière de sauvegarde et de récupération.

Dans les environnements Kubernetes, le logiciel de sauvegarde doit effectuer les tâches suivantes de manière dynamique :

  • Détecter la création d'applications conteneurisées
  • Appliquer la bonne politique de sauvegarde à chacune d'entre elles
  • Identifier les dépendances qui peuvent exister entre diverses applications conteneurisées
  • Évoluer à la hausse ou à la baisse pour gérer potentiellement des millions d'activités différentes liées à la sauvegarde

HYCU accorde aux entreprises la possibilité de répondre à leurs besoins en matière de sauvegarde et de récupération dans un environnement Kubernetes.

Construit sur une architecture cloud-native, HYCU se met automatiquement et dynamiquement à l'échelle pour répondre à l'évolution des charges de travail de sauvegarde Kubernetes.

En interagissant avec Kubernetes, il protège à la fois le plan de contrôle de Kubernetes et les applications conteneurisées. Pour protéger les applications, HYCU lit les étiquettes de métadonnées préexistantes des applications. HYCU attribue ensuite de manière programmatique les politiques de sauvegarde appropriées à chaque application conteneurisée en fonction de leurs étiquettes.

HYCU propose également des services de validation de récupération pour prendre en charge la récupération d'application(s) hébergée(s) dans Kubernetes dans d'autres clouds. Elle prend déjà en charge le moteur Google Kubernetes (GKE), et la prise en charge d'autres services cloud Kubernetes est prévue prochainement. La plateforme unique de HYCU offre une expérience utilisateur unifiée pour gérer la protection des données sur Google Compute Engine (GCE), Google Cloud Storage et GKE. Les entreprises peuvent attribuer aux applications GKE les mêmes politiques que celles qu'elles utilisent déjà pour protéger les instances GCE et les applications qui s'y exécutent.

Délivré sous forme de service, HYCU offre aux entreprises une solution unique pour protéger à la fois leurs applications conteneurisées et virtuelles. Sa console de gestion administre à la fois Kubernetes et les environnements virtuels. Les entreprises sont ainsi équipées pour planifier et effectuer des sauvegardes de manière centralisée ; archiver
et copier les copies de sauvegarde ; attribuer des politiques de sauvegarde ; et, effectuer des restaurations.

En adoptant HYCU, les entreprises peuvent continuer à répondre aux besoins de sauvegarde en constante évolution de leur environnement virtualisé existant

HYCU les positionne simultanément pour répondre à leurs exigences émergentes en matière de sauvegarde Kubernetes. Ce faisant, HYCU constitue une excellente option pour les entreprises qui souhaitent passer à Kubernetes tout en garantissant l'intégrité de leurs données dans les deux environnements.
 

A propos de DCIG

Le Data Center Intelligence Group (DCIG) donne au secteur des technologies de l'information les moyens d'effectuer des analyses exploitables. Les analystes de DCIG fournissent une analyse tierce informée de diverses technologies de cloud, de protection des données et de stockage des données. DCIG développe de manière indépendante du contenu sous licence sous la forme de rapports TOP 5 et de profils de solutions.
Plus d'informations sont disponibles sur www.dcig.com.

SVP of Product

Subbiah Sundaram est SVP, Product chez HYCU. Subbiah dirige la gestion des produits, le marketing produit, les alliances, l'ingénierie des ventes et la réussite des clients, avec plus de 20 ans d'expérience dans la fourniture de solutions de protection des données multi-cloud et sur site de premier ordre. Diplômé d'un MBA de la Kellogg Management School, Subbiah a travaillé avec des entreprises de premier plan telles que EMC, NetApp, Veritas, BMC, CA et DataGravity.

Découvrez la première plateforme SaaS de protection des données

Essayez HYCU par vous-même et devenez un adepte.