Devriez-vous exécuter des applications avec état dans Kubernetes ?

Kubernetes est souvent abordé du point de vue des systèmes sans état. Une application sans état est facile à conteneuriser, à distribuer et à mettre à l’échelle, car elle n’a pas besoin de stocker de données en dehors de son environnement. Peu importe si le conteneur est arrêté ou déplacé vers un autre hôte – de nouvelles instances peuvent remplacer les anciennes sans aucune répercussion.

Cependant, la plupart des applications réelles ne sont pas comme ça. Tous les systèmes, sauf les plus simples, possèdent un état qui est généralement stocké dans une base de données ou un système de fichiers persistant. Les données qui configurent votre service ou qui sont créées par les utilisateurs doivent être conservées et rendues accessibles à tous vos conteneurs, quel que soit leur emplacement.

Le défi de maintenir l’état dans les environnements transitoires est rencontré par la plupart des organisations qui utilisent des conteneurs, l’orchestration et des pratiques de travail natives du cloud. Les charges de travail avec état peuvent être prises en charge par Kubernetes, mais des alternatives externes existent également. Dans cet article, vous découvrirez certaines des approches qui permettent à Kubernetes de fonctionner avec des applications avec état.

Les problèmes avec l’État

Le terme « état » décrit les données associées à une application à un moment donné. Il s’agit d’informations de longue durée telles que le contenu de la base de données et les comptes d’utilisateurs qui devront être récupérées tout au long de la durée de vie du système. L’état change continuellement au fur et à mesure que les données sont créées et modifiées pendant que votre service est en cours d’utilisation.

Le bon fonctionnement de l’application dépend de la capacité de chaque instance à accéder à l’état persistant. Si vous distribuez quatre répliques d’un composant sur deux hôtes physiques, ces deux machines auront besoin d’accéder à votre magasin de données. Cela signifie que les instances d’application ont des dépendances interconnectées qui ne peuvent pas être remplacées automatiquement.

Les contraintes autour des services avec état entrent en conflit avec le modèle Kubernetes de conteneurs éphémères qui peuvent être remplacés à tout moment. Lorsque vous travaillez avec une application avec état, vous devez prendre des dispositions spéciales pour que les conteneurs puissent accéder de manière fiable à l’état dont ils ont besoin. Cela nécessite une configuration supplémentaire pour fournir une persistance des données fiable qui reste stable à mesure que votre application évolue.

Exécution de services avec état dans Kubernetes

La prise en charge de Kubernetes pour les systèmes avec état a augmenté au cours des dernières années, soutenue par une augmentation de l’intérêt de la communauté. Les applications avec état peuvent être assemblées à partir de ressources officiellement prises en charge telles que des ensembles avec état et des volumes persistants. Ceux-ci offrent des méthodes intégrées pour stocker et gérer vos données.

Les volumes persistants fournissent un stockage de données à vos pods. Les fichiers écrits sur un volume persistant sont stockés indépendamment du pod qui les crée. Le contenu du volume persiste dans votre cluster après la destruction des pods, permettant à leurs remplaçants d’accéder à l’état stocké.

Les StatefulSets sont des objets d’API qui représentent des applications avec état. Ils fonctionnent de la même manière que les déploiements, mais attribuent un identifiant unique à chaque pod qu’ils encapsulent. Les pods conservent leurs identifiants même s’ils sont redémarrés ou programmés sur un autre nœud. Cela vous permet de mettre en œuvre des procédures où la commande et l’identité des pods sont importantes. Les identifiants fiables vous permettent de réassocier les volumes aux pods après un événement de planification et de déployer en douceur les mises à jour des applications dans l’ordre.

Ces fonctionnalités signifient qu’il est désormais possible d’exécuter des applications avec état dans votre cluster Kubernetes. Vous pouvez écrire des données sur des volumes persistants et utiliser des StatefulSets au lieu de Deployments lorsque les pods doivent se souvenir de leurs identités.

État de gestion en dehors de Kubernetes

Un itinéraire populaire pour exécuter des services avec état dans Kubernetes consiste à localiser l’état à l’extérieur votre grappe. Vous concevez votre système de sorte que ses composants soient découplés du stockage dont ils ont besoin. Ils peuvent accéder à des données persistantes dans des services distincts sur le réseau.

Vous pouvez gérer votre propre serveur de base de données, vous connecter à des partages de fichiers réseau existants ou utiliser un service entièrement géré de votre fournisseur de cloud. Les applications de votre cluster Kubernetes doivent être configurées pour interagir avec vos systèmes de stockage à l’aide de leurs API ou de leurs protocoles d’accès direct.

C’est un bon moyen de favoriser le découplage dans vos services. La suppression de l’accès persistant au système de fichiers de vos applications conteneurisées les rend plus portables d’un environnement à l’autre. Les conteneurs peuvent être lancés à l’aide de modèles de déploiement sans état car leurs dépendances de stockage sont réduites à des appels réseau de base. Vous pouvez bénéficier de la flexibilité de Kubernetes sans encourir le coût de complexité lié à l’utilisation de volumes persistants et d’ensembles avec état pour stocker l’état dans votre cluster.

Éviter Kubernetes pour les services avec état

Une troisième école de pensée consiste à éviter complètement Kubernetes pour les services avec état. Il s’agit généralement d’une réaction excessive. Si vous n’êtes pas à l’aise pour maintenir l’état de votre cluster, vous pouvez toujours utiliser la méthode décrite ci-dessus pour déployer vos applications à l’aide d’un fournisseur de stockage adjacent.

Néanmoins, il existe encore des systèmes qui pourraient ne pas avoir de sens dans Kubernetes. Les architectures extrêmement dépendantes du système de fichiers qui fonctionnent avec un grand nombre de fichiers peuvent être difficiles à mettre en œuvre et à mettre à l’échelle à l’aide de volumes persistants. Un système de stockage externe géré avec Kubernetes peut ajouter une latence inacceptable lorsque les interactions avec les fichiers sont la fonction principale de votre service.

Dans ces circonstances, vous devrez peut-être rechercher d’autres approches de déploiement qui vous donneront plus de contrôle sur le stockage des données et les opérations d’E/S. Cependant, des travaux sont en cours dans l’écosystème pour améliorer les options de stockage des systèmes conteneurisés. Les solutions de stockage cloud natives émergent en tant qu’abstractions de haut niveau de concepts tels que les volumes persistants et les ensembles avec état, mettant en œuvre des systèmes de fichiers distribués qui restent performants lorsqu’ils sont utilisés sur plusieurs nœuds. Ceph, Minio et Portworx sont quelques-uns des prétendants dans cet espace.

Devriez-vous exécuter des applications avec état dans Kubernetes ?

La plupart des applications avec état peuvent être déployées sans problème à l’aide de Kubernetes. La décision principale est de savoir si vous conservez vos données persistantes à l’intérieur de votre cluster, en utilisant des volumes persistants et des ensembles avec état, ou une interface avec un magasin de données géré en externe.

Les volumes persistants fonctionnent pour la plupart des cas d’utilisation, mais ils s’accompagnent de certaines limitations. Tous les modes d’accès au volume ne sont pas pris en charge par chaque implémentation. Il est donc important de vérifier les fonctionnalités prises en charge par votre distribution Kubernetes.

Relativement peu de conducteurs offrent le ReadWriteMany mode qui permet au volume d’être lié à plusieurs nœuds simultanément, chacun d’eux pouvant lire et écrire des données. La ReadWriteOnce Le mode est le plus largement pris en charge, permettant à chaque nœud de lire des données mais à un seul d’entre eux d’écrire. Ces contraintes peuvent affecter la planification de votre application – un système avec plusieurs pods qui doivent écrire dans une instance de base de données partagée devra tous les exécuter sur un seul nœud, à moins que ReadWriteMany est disponible. Cela limite votre capacité à faire évoluer vos services.

L’utilisation d’une base de données gérée en externe ou d’un système de stockage d’objets est un moyen efficace d’atténuer ces problèmes persistants tout en bénéficiant de la flexibilité de Kubernetes. Cela nécessite que votre application soit entièrement découplée de son stockage, ce qui peut ne pas être une option si vous migrez un service hérité.

Travailler avec des applications plus anciennes présente les arguments les plus solides pour ne pas exécutant une application avec état dans Kubernetes. Vous pouvez vous heurter à des barrages routiers si vous n’êtes pas en mesure d’être intentionnel quant à l’emplacement de stockage de l’état et à la manière dont il est géré. Dans ces situations, il est généralement préférable de refactoriser votre système avant d’essayer de le distribuer sur les nœuds de déploiement.

Sommaire

Bien que les applications avec état et Kubernetes ne correspondent pas tout à fait naturellement, il est possible d’accueillir des données persistantes dans votre cluster en combinant des ensembles avec état et des volumes persistants. Celles-ci fournissent des méthodes officiellement prises en charge pour orchestrer des systèmes avec état à l’aide de Kubernetes, mais vous devez garder à l’esprit les contraintes de planification qu’elles imposent.

Étant donné que la gestion de l’état dans le cluster ajoute de la complexité, la conservation des données persistantes dans un service externe est un moyen populaire de rationaliser vos déploiements. Les bases de données gérées, les plates-formes de stockage d’objets et les réseaux privés vous permettent de provisionner le stockage en dehors de votre cluster, puis de le consommer en toute sécurité depuis l’intérieur. Vous devrez adapter votre application pour prendre en charge les interfaces de stockage externes, mais vous pourrez alors bénéficier d’une flexibilité de déploiement accrue.

Les applications où l’état consiste en de simples fichiers de configuration peuvent utiliser ConfigMaps pour s’exécuter dans Kubernetes sans avoir à adopter un stockage de fichiers persistant. Les ConfigMaps sont des objets de première classe qui sont automatiquement fournis à vos pods lorsqu’ils sont nécessaires, sous forme de variables d’environnement ou de fichiers montés. Ils éliminent le besoin de volumes persistants lorsque vous ne stockez qu’une poignée de paramètres de longue durée.