Je suis dans un état d’incrédulité (jeu de mots) quand, en 2024, j’entends souvent les opérateurs de plateformes dire que Kubernetes est réservé aux workloads sans état, ou qu’ils n’exigent pas de protection des données, car « toutes nos applications sont sans état ». Dans cet article, j’aborderai la place des états dans nos applications, la montée du mythe « Kubernetes = sans état » et les besoins de protection des données dans l’ensemble des environnements Kubernetes.
Avec état ou sans état : les principes de base
« Sans état » fait référence à un workload qui ne nécessite pas de persistance avec état, de sorte que le redémarrage ou le redéploiement du workload signifie que toutes les données collectées ou les paramètres modifiés ont disparu. Par comparaison, les conteneurs sont intrinsèquement sans état, contrairement à leurs prédécesseurs, les machines virtuelles (VM) avec état. Lorsqu’un conteneur est redémarré, l’utilisateur sait que le workload exécuté correspond exactement à celui défini lors de la création initiale de l’image du conteneur.
En suivant cette logique, un workload avec état est celui qui conserve les données afin qu’elles puissent être accessibles, même après un redémarrage. Parmi les workloads avec état les plus courants, on trouve des bases de données comme PostgreSQL, MySQL ou MongoDB.
Alors, qu’est-ce qu’une application sans état ?
Les applications sont généralement constituées de plusieurs workloads. Même les applications monolithiques basées sur des machines virtuelles (VM) incluent en général des workloads distincts pour l’interface utilisateur, la logique métier et la base de données. Les applications natives du cloud, basées sur des microservices se composent souvent d’un plus grand nombre de workloads distincts, chacun ayant une fonction spécifique, dans le but de permettre aux entreprises de déployer de nouvelles fonctionnalités et de nouveaux services plus rapidement que jamais.
Cela signifie que, dans leur grande majorité, les applications sans état n’existent pas.
Votre application préférée de commande de repas, une application de gestion de tâches sur votre téléphone, ou encore un formulaire pour prendre rendez-vous chez le médecin, tous ces exemples seraient pratiquement inutilisables sans des workloads avec état capables de conserver les données stratégiques associées à chacun de ces cas d’usage.
Avec Kubernetes, il est essentiel de savoir où résident les données (ou états) de vos applications, à l’intérieur ou à l’extérieur du cluster.
Comment en sommes-nous arrivés là : Kubernetes = sans état ?
Alors que Docker est devenu une plate-forme de conteneurs de facto au début et au milieu des années 2010 pour l’empaquetage de logiciels, il était essentiel de disposer d’une solution pour orchestrer des groupes de conteneurs à grande échelle afin d’extraire toute la valeur opérationnelle d’un passage aux microservices – et Kubernetes l’a fait. Les déploiements déclaratifs, la haute disponibilité et la mise à l’échelle automatisée étaient des avantages majeurs pour les workloads sans état, qui pouvaient être arrêtés, redémarrés et clonés facilement. Ces workloads, souvent utilisées pour des tâches liées au front-end ou au traitement applicatif, pouvaient être connectés à des services de données fonctionnant en dehors du cluster. Ce modèle a été salué par beaucoup comme une réussite. Kubernetes était clairement une solution conçue pour les workloads sans état, n’est-ce pas ?
Pourtant, dès Kubernetes v1.0, à côté de toutes ces fonctionnalités remarquables pour les workloads sans état, figurait déjà le concept de volume persistant : un mécanisme natif de Kubernetes permettant d’attacher un stockage persistant à des pods éphémères. De toute évidence, l’intention de prendre en charge les workloads avec état a été prise en compte dès le départ, avec plusieurs améliorations notables en cours de route :
- Décembre 2017 (v1.9) Disponibilité générale des StatefulSets (persistance des traits d’identité des pods et des opérations ordonnées)
- Décembre 2018 (v1.13) : Disponibilité officielle de l’interface CSI (Container Storage Interface) (une norme permettant à tout fabricant de stockage de créer ses propres plugins pour fournir du stockage aux workloads Kubernetes)
- Mai 2018 : Introduction du Operator Framework (un kit de développement logiciel (SDK) destiné à simplifier le déploiement et la gestion de workloads avancés, comme les bases de données, sur Kubernetes)
- Décembre 2020 (v1.20) : Disponibilité officielle des snapshots de volumes dans la spécification CSI (fournissant une interface standardisée pour effectuer des opérations de snapshot de baie de stockage dans Kubernetes)
Ces avancées, soutenues par les efforts de nombreux fournisseurs et contributeurs, ont donné naissance à un écosystème riche. Les utilisateurs bénéficient ainsi de la liberté de choisir les services de données pour gérer l’état de leurs applications et de décider où exécuter ces workloads.
L’essor de GitOps
Au cours de cette période, la communauté Kubernetes a vu naître une nouvelle idée pour améliorer l’orchestration des conteneurs : GitOps. Le concept est simple : utiliser le contrôle de version comme source de vérité, en stockant tout ce qui est nécessaire pour déployer une application, y compris le code et les ressources Kubernetes. Chaque fois que le code est fusionné dans le référentiel pour apporter une modification, un contrôleur met à jour le déploiement pour refléter l’état souhaité décrit dans Git. Les implémentations GitOps peuvent fournir un mécanisme de contrôle des changements, la possibilité de redéployer un environnement entier en un seul clic et un moyen d’annuler les mauvais changements, parfois.
Le fait que Kubernetes puisse exécuter des workloads avec état signifie-t-il pour autant que vous devriez le faire ?
Chargé de créer une application de démonstration de concept, un développeur choisit souvent une base de données gérée hébergée dans le cloud ou DBaaS, pour héberger ses données persistantes en dehors du cluster Kubernetes. Les solutions DBaaS fournissent des API conviviales pour les développeurs et un délai de rentabilité rapide pour les utilisateurs, quel que soit leur niveau d’expertise en matière d’administration de bases de données. Cependant, comme c’est souvent le cas, ce qui est le plus facile n’est pas toujours le meilleur. Explorons les raisons d’envisager d’exécuter des workloads avec état à l’intérieur ou à l’extérieur du cluster :
- Latence : Héberger les services de données aux côtés des autres workloads conteneurisés garantit une connectivité à faible latence, essentielle pour offrir une expérience utilisateur cohérente.
- Mobilité : Kubernetes offre une solide couche d’abstraction qui vous permet de déplacer le même workload entre différents clouds. Cela permet aux entreprises de répondre à leurs besoins de contrôle des données ou simplement de profiter de meilleurs prix. Cependant, si vos services de données sont liés à un DBaaS spécifique au cloud, la migration entre les environnements devient considérablement plus compliquée. Les automatisations et politiques créées pour un DBaaS devront être recréées pour une base de données gérée équivalente dans le cloud cible, à condition qu’elle existe et réponde aux exigences. Des outils et des traitements distincts seront nécessaires pour redéployer vos workloads Kubernetes à partir de vos services de données externes.
- Gestion des données de copie : Vos développeurs doivent tester l’application avec des données récentes et pertinentes, ce qui nécessite des processus distincts pour gérer et connecter ces services de données lorsqu’ils sont hébergés en dehors du cluster. Dans le cadre d’une solution entièrement déclarative exécutant à la fois des workloads avec et sans état au sein du cluster, les utilisateurs peuvent restaurer des sauvegardes d’applications complètes sous forme de clones à l’aide d’une interface native Kubernetes telle que « kubectl ».
- Persistance polyglotte : Une manière élégante de dire « le bon service de données pour le bon cas d’usage ». Lorsqu’une application héritée est reconstruite selon une architecture de microservices, Kubernetes permet aux développeurs de choisir le service de données idéal pour chaque besoin, avec un déploiement simplifié et une gestion continue facilitée par les opérateurs. Les entreprises qui exploitent des services de données en dehors de Kubernetes peuvent ne pas être en mesure d’évoluer pour répondre aux exigences opérationnelles complexes liées à la prise en charge de chacune des sélections de services de données idéaux effectuées par les développeurs.
- Coût : Avec les solutions DBaaS, vous payez pour le confort d’utilisation. Cependant, des partenaires comme EnterpriseDB ont démontré que l’hébergement de vos propres services de données sur Kubernetes permet de réduire le coût total de possession (CTP) sans compromettre de manière significative l’expérience utilisateur.
En optant pour la consolidation des workloads sans état et avec état sur Kubernetes, vous gagnez en flexibilité quant à l’emplacement d’exécution des applications. Elle peut également fournir un libre-service supplémentaire pour les DevOps, réduire les coûts et rationaliser les outils et les processus. Cela permet d’appliquer la méthodologie GitOps à toutes les parties d’une application. Il n’est donc pas surprenant que, selon le dernier rapport de Datadog sur l’utilisation réelle des conteneurs, les bases de données restent la catégorie de workloads conteneurisés la plus populaire.
Protéger vos données sur Kubernetes
Équipe « avec état »
Si vous êtes déjà convaincu que les workloads avec état sur Kubernetes sont la voie à suivre, vous comprenez probablement déjà que fournir la sauvegarde et la reprise après incident de ces applications nécessite un outil spécifiquement conçu. Chaque application est composée de nombreuses ressources Kubernetes différentes (ConfigMaps, Secrets, Deployments, etc.) ainsi que de données de volume persistantes. Qui plus est, tous ces éléments doivent être correctement détectés, pris par snapshots et exportés vers un emplacement sécurisé hors cluster.
C’est là qu’intervient Veeam Kasten for Kubernetes, une solution native Kubernetes de protection des données et de mobilité des applications. Avec Kasten, les entreprises disposent d’un moyen simple à utiliser, évolutif et sécurisé de créer des sauvegardes inaltérables et de restaurer des applications entières de manière fiable et rapide.
Comme Kasten fournit une API déclarative native Kubernetes pour définir des stratégies, exécuter des actions, etc., la protection des données peut être étroitement intégrée à n’importe quelle implémentation GitOps. C’est le cas dans tous les scénarios d’utilisation, du déploiement et de la configuration de Kasten sur un nouveau cluster à l’amélioration de GitOps grâce à l’automatisation des sauvegardes avant le déploiement des mises à jour de code. À lui seul, GitOps offre la possibilité d’annuler les modifications de configuration d’une ressource Kubernetes ; toutefois, si l’une de ces mauvaises modifications altère les données d’un volume persistant (changement de schéma incorrect ou suppression d’une table, par exemple), il vous faudra une sauvegarde récente pouvant être rapidement restaurée.
Équipe « sans état »
Pas encore prêt à abandonner votre DBaaS préféré pour une nouvelle base de données hébergée sur Kubernetes et gérée par un opérateur ? Kasten est toujours là pour vous. Voyons pourquoi la protection des données natives Kubernetes est toujours nécessaire :
- L’état doit bien résider quelque part : Où que se trouvent les données en dehors du cluster, il reste essentiel de pouvoir reproduire des déploiements d’applications à un instant précis, généralement pour des raisons de reprise après sinistre (DR) ou de conformité. Kasten est à la base un moteur d’orchestration conçu pour les opérations de protection des données. Les fonctionnalités de schéma de Kasten permettent des contrôles efficaces pour mettre en veille les services de données sur le cluster. Elles peuvent également être utilisées pour orchestrer des snapshots et des sauvegardes de services de données externes. Cela peut inclure l’orchestration des vidages logiques d’une base de données ou l’intégration directe avec des API DBaaS.
- GitOps n’est pas infaillible :De nombreux administrateurs et ingénieurs ont fait l’expérience d’une forme de « test en production ». Cela signifie que des modifications ont été apportées à une instance de production pour <insérer une raison importante ici>, contournant ainsi le processus de gestion des changements en place. Ainsi, la seule source de vérité sur ce qui a été déployé provient du cluster lui-même au moment de l’exécution. Disposer de sauvegardes régulières des manifestes associés à chaque application au fur et à mesure du déploiement permet de capturer toutes ces incohérences, ce qui permet de reproduire fidèlement l’environnement d’origine, que ce soit pour la reprise après sinistre (DR) ou pour répondre à des exigences réglementaires.
- Protection des images de conteneur — Kasten intègre la plupart des fonctionnalités avancées fournies par Red Hat OpenShift, notamment la prise en charge de la protection et de la restauration des images de conteneur ImageStream. Par rapport à Kubernetes en amont, les flux d’images offrent une multitude de fonctionnalités pour la création et le déploiement d’images de conteneurs. Les sources potentielles souvent négligées de l’état d’un cluster sont les images de conteneur ImageStream qui, par défaut, sont transmises au registre de conteneurs interne du cluster. La reconstruction à partir de la source ne garantit pas que les images résultantes seront les mêmes. Encore une fois, la capacité à reproduire entièrement un environnement ou à restaurer après une perte de cluster nécessite des sauvegardes fiables.
- Machines virtuelles sur Kubernetes : Grâce au projet KubeVirt et à ses collaborateurs, il est désormais possible d’exécuter des VM côte à côte avec des workloads conteneurisés sur Kubernetes. Cela permet aux entreprises de simplifier les outils et les processus autour de Kubernetes tout en offrant une transition facile pour les workloads qui n’ont pas encore été ou ne seront tout simplement pas transformés en applications cloud natives. Même sur Kubernetes, les machines virtuelles (VM) sont intrinsèquement avec état, mais elles ne peuvent pas être protégées avec des outils de sauvegarde traditionnels pour VM. Kasten V7.0 offre le meilleur support de sa catégorie pour la sauvegarde et la restauration des VM sur Kubernetes exécutant OpenShift Virtualization.
L’équipe Protection des données Kubernetes
Kubernetes a évolué pour prendre en charge tous les types de workloads, en dépit de la croyance persistante selon laquelle Kubernetes ne convient qu’aux workloads sans état. Alors que les entreprises s’efforcent de rentabiliser au mieux leurs investissements cloud natif, la transition vers l’exécution de workloads avec état devient inévitable. Performances et mobilité accrues, administration simplifiée des copies de données, persistance polyglotte et économies de coûts sont autant d’avantages qui attendent d’être réalisés.
Que l’on exécute des workloads avec ou sans état, la protection des données reste cruciale. Veeam Kasten for Kubernetes est une solution native Kubernetes pour la sauvegarde des applications et des données, la reprise après incident, la mobilité applicative et la protection contre les ransomwares. De plus, les méthodologies GitOps peuvent être améliorées en intégrant la protection des données dans les déploiements d’applications. Adopter les workloads avec état sur Kubernetes peut non seulement ouvrir de nouvelles opportunités de revenus, mais aussi offrir aux entreprises une plus grande flexibilité, des options en libre-service, une meilleure rentabilité et des opérations simplifiées.
Lancez-vous et essayez dès aujourd’hui notre solution gratuite Veeam Kasten Free ou la version d’essai Enterprise.