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

Kubernetes est souvent abordé du level de vue des systèmes sans état. Une software 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 additionally 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 options externes existent également. Dans cet report, vous découvrirez certaines des approches qui permettent à Kubernetes de fonctionner avec des apps avec état.

Les problèmes avec l’État

Le terme « état » décrit les données associées à une software à 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 very long de la durée de vie du système. L’état adjust continuellement au fur et à mesure que les données sont créées et modifiées pendant que votre services est en cours d’utilisation.

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

Les contraintes autour des providers avec état entrent en conflit avec le modèle Kubernetes de conteneurs éphémères qui peuvent être remplacés à tout second. 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 secure à mesure que votre software évolue.

Exécution de expert services avec état dans Kubernetes

Prise en demand de Kubernetes pour les systèmes avec état a grandi ces dernières années, soutenu 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 demand telles que 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 purposes avec état. Ils fonctionnent de la même manière que les déploiements, mais attribuent un identifiant distinctive à 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 programs dans l’ordre.

Ces fonctionnalités signifient qu’il est désormais achievable 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 memento de leurs identités.

État de gestion en dehors de Kubernetes

Un itinéraire populaire pour exécuter des expert 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 companies distincts sur le réseau.

Vous pouvez gérer votre propre serveur de foundation de données, vous connecter à des partages de fichiers réseau existants ou utiliser un company 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 programs conteneurisées les rend as well as portables d’un environnement à l’autre. Les conteneurs peuvent être lancés à l’aide de modèles de déploiement sans état vehicle 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 products and services avec état

Une troisième école de pensée consiste à éviter complètement Kubernetes pour les solutions 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 apps à 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 services.

Dans ces circonstances, vous devrez peut-être rechercher d’autres approches de déploiement qui vous donneront additionally 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. Solutions de stockage natives dans le cloud émergent comme des abstractions de haut niveau de principles tels que les volumes persistants et les ensembles avec état, implémentant des systèmes de fichiers distribués qui restent performants lorsqu’ils sont utilisés sur plusieurs nœuds. Céph, Minioet 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 limits. Pas tout le quantity modes d’accès sont pris en cost par chaque implémentation, il est donc vital de vérifier quelles fonctionnalités votre distribution Kubernetes prend en demand.

Relativement peu de conducteurs offrent le ReadWriteMany mode qui permet au quantity 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 cost, 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 foundation 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 companies.

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 software soit entièrement découplée de son stockage, ce qui peut ne pas être une selection si vous migrez un support hérité.

Travailler avec des purposes additionally anciennes présente les arguments les furthermore 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 predicaments, 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 programs avec état et Kubernetes ne soient pas tout à fait une correspondance naturelle, il est achievable d’accueillir des données persistantes dans votre cluster en combinant 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 support 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 software 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.