Architecture des applications pour Kubernetes

Concevoir et exécuter des applications avec évolutivité, portabilité et robustesse peut être un défi, en particulier à mesure que la complexité du système augmente. L'architecture d'une application ou d'un système influe considérablement sur la manière dont elle doit être exécutée, sur ce qu'elle attend de son environnement et sur son couplage étroit avec les composants associés. Le suivi de certains modèles au cours de la phase de conception et le respect de certaines pratiques opérationnelles peuvent aider à contrer certains des problèmes les plus courants rencontrés par les applications lors de l'exécution dans des environnements hautement distribués.

Alors que les modèles de conception de logiciels et les méthodologies de développement peuvent produire des applications avec les bonnes caractéristiques de dimensionnement, l’infrastructure et l’environnement influencent le fonctionnement du système déployé. Des technologies telles queDocker etKubernetes aident les équipes à créer des packages de logiciels, puis à les distribuer, les déployer et les évoluer sur des plates-formes d'ordinateurs distribués. Apprendre à exploiter au mieux la puissance de ces outils peut vous aider à gérer les applications avec plus de flexibilité, de contrôle et de réactivité.

Dans ce guide, nous aborderons certains des principes et modèles que vous pouvez souhaiter adopter pour vous aider à faire évoluer et gérer votre charge de travail sur Kubernetes. Bien que Kubernetes puisse exécuter de nombreux types de charges de travail, les choix que vous faites peuvent influer sur la facilité d'utilisation et les possibilités de déploiement. La manière dont vous concevez et construisez vos applications, empaquetez vos services dans des conteneurs, configurez la gestion du cycle de vie et le comportement au sein de Kubernetes peuvent chacun influencer votre expérience.

Lors de la production d'un logiciel, de nombreuses exigences affectent les modèles et l'architecture que vous choisissez d'utiliser. Avec Kubernetes, l'un des facteurs les plus importants est la possibilité descale horizontally, en ajustant le nombre de copies identiques de votre application pour répartir la charge et augmenter la disponibilité. C'est une alternative àvertical scaling, qui tente de manipuler les mêmes facteurs en déployant sur des machines avec plus ou moins de ressources.

En particulier,microservices est un modèle de conception logicielle qui fonctionne bien pour les déploiements évolutifs sur des clusters. Les développeurs créent de petites applications composables qui communiquent sur le réseau par le biais d’API REST bien définies, au lieu de programmes composés plus volumineux qui communiquent via des mécanismes de programmation internes. La décomposition d'applications monolithiques en composants à usage unique discrets permet de redimensionner chaque fonction indépendamment. Une grande partie de la complexité et de la composition qui existeraient normalement au niveau de l'application est transférée au domaine opérationnel où elle peut être gérée par des plates-formes telles que Kubernetes.

Au-delà des modèles logiciels spécifiques, les applicationscloud native sont conçues avec quelques considérations supplémentaires à l'esprit. Les applications natives en nuage sont des programmes qui suivent un modèle d'architecture microservices avec une résilience, une observabilité et des fonctionnalités administratives intégrées pour s'adapter à l'environnement fourni par les plates-formes en cluster dans le nuage.

Par exemple, les applications natives en nuage sont construites avec des métriques de rapport d'intégrité pour permettre à la plate-forme de gérer les événements du cycle de vie si une instance devient malsaine. Ils produisent (et mettent à disposition pour l'exportation) des données de télémesure robustes pour alerter les opérateurs des problèmes et leur permettre de prendre des décisions éclairées. Les applications sont conçues pour gérer les redémarrages et les échecs réguliers, les modifications de la disponibilité du back-end et la charge élevée sans altérer les données ni ne plus répondre.

Kubernetes utilise des conteneurs pour exécuter des applications packagées isolées sur ses nœuds de cluster. Pour fonctionner sur Kubernetes, vos applications doivent être encapsulées dans une ou plusieurs images de conteneur et exécutées à l'aide d'un environnement d'exécution de conteneur tel que Docker. Bien que la conteneurisation de vos composants soit une exigence de Kubernetes, elle permet également de renforcer de nombreux principes de la méthodologie à douze facteurs décrite ci-dessus, facilitant ainsi la mise à l'échelle et la gestion.

Par exemple, les conteneurs fournissent une isolation entre l'environnement de l'application et le système hôte externe, prennent en charge une approche réseau de la communication inter-application orientée service Les conteneurs eux-mêmes encouragent la concurrence basée sur les processus et aident à maintenir la parité dev / prod en étant indépendamment évolutifs et en regroupant l'environnement d'exécution du processus. Ces caractéristiques permettent de conditionner vos applications de manière à ce qu'elles fonctionnent correctement sur Kubernetes.

Alors que vos applications doivent être conteneurisées pour s'exécuter sur un cluster Kubernetes,pods est la plus petite unité d'abstraction que Kubernetes puisse gérer directement. Un pod est un objet Kubernetes composé d'un ou de plusieurs conteneurs étroitement couplés. Les conteneurs d'un pod partagent un cycle de vie et sont gérés ensemble comme une seule et même unité. Par exemple, les conteneurs sont toujours planifiés sur le même nœud, démarrés ou arrêtés à l'unisson et partagent des ressources telles que les systèmes de fichiers et l'espace IP.

Au début, il peut être difficile de trouver le meilleur moyen de diviser vos applications en conteneurs et en modules. Il est donc important de comprendre comment Kubernetes gère ces composants et ce que chaque couche d’abstraction fournit à vos systèmes. Quelques considérations peuvent vous aider à identifier des points naturels d’encapsulation pour votre application avec chacune de ces abstractions.

Une façon de déterminer une portée efficace pour vos conteneurs consiste à rechercher des limites de développement naturelles. Si vos systèmes utilisent une architecture de microservices, des conteneurs bien conçus sont souvent conçus pour représenter des unités discrètes de fonctionnalités pouvant souvent être utilisées dans divers contextes. Ce niveau d'abstraction permet à votre équipe de publier les modifications apportées aux images de conteneur, puis de déployer cette nouvelle fonctionnalité dans tout environnement où ces images sont utilisées. Les applications peuvent être construites en composant des conteneurs individuels qui remplissent chacun une fonction donnée mais ne peuvent pas accomplir tout un processus seul.

Contrairement à ce qui précède, les pods sont généralement construits en réfléchissant aux parties de votre système qui pourraient le plus bénéficier desmanagement indépendants. Etant donné que Kubernetes utilise les pods comme la plus petite abstraction pour l’utilisateur, ce sont les unités les plus primitives que les outils et l’API de Kubernetes peuvent interagir et contrôler directement. Vous pouvez démarrer, arrêter et redémarrer des pods, ou utiliser des objets de niveau supérieur construits sur des pods pour introduire des fonctionnalités de réplication et de gestion du cycle de vie. Kubernetes ne vous permet pas de gérer les conteneurs d’un pod indépendamment, vous ne devez donc pas regrouper les conteneurs qui pourraient bénéficier d’une administration distincte.

Étant donné que de nombreuses caractéristiques et abstractions de Kubernetes traitent directement avec les pods, il est logique de regrouper des éléments devant être redimensionnés dans un seul pod et de séparer ceux qui doivent évoluer indépendamment. Par exemple, en séparant vos serveurs Web de vos serveurs d'applications dans des pods différents, vous pouvez redimensionner chaque couche indépendamment si nécessaire. Toutefois, il peut être judicieux de regrouper un serveur Web et un adaptateur de base de données dans le même module si celui-ci fournit les fonctionnalités essentielles dont le serveur Web a besoin pour fonctionner correctement.

Alors que la configuration d'applicationcan est intégrée dans des images de conteneur, il est préférable de rendre vos composants configurables au moment de l'exécution pour prendre en charge le déploiement dans plusieurs contextes et permettre une administration plus flexible. Pour gérer les paramètres de configuration d'exécution, Kubernetes propose deux objets appelésConfigMaps etSecrets.

Les ConfigMaps sont un mécanisme utilisé pour stocker des données pouvant être exposées à des pods et à d'autres objets au moment de l'exécution. Les données stockées dans ConfigMaps peuvent être présentées sous forme de variables d'environnement ou montées sous forme de fichiers dans le pod. En concevant vos applications pour qu'elles lisent depuis ces emplacements, vous pouvez injecter la configuration au moment de l'exécution à l'aide de ConfigMaps et modifier le comportement de vos composants sans avoir à reconstruire l'image du conteneur.

Les secrets sont un type d'objet Kubernetes similaire, utilisé pour stocker en toute sécurité des données sensibles et permettre aux pods et autres composants d'accéder au besoin. Les secrets sont un moyen pratique de transmettre des documents sensibles aux applications sans les stocker sous forme de texte brut dans des emplacements facilement accessibles de votre configuration normale. Sur le plan fonctionnel, ils fonctionnent de la même manière que ConfigMaps. Ainsi, les applications peuvent utiliser les mêmes données pour configMaps et Secrets.

ConfigMaps et Secrets vous aident à éviter de placer la configuration directement dans les définitions d'objet Kubernetes. Vous pouvez mapper la clé de configuration à la place de la valeur, ce qui vous permet de mettre à jour la configuration à la volée en modifiant ConfigMap ou Secret. Cela vous donne la possibilité de modifier le comportement d'exécution actif des pods et autres objets Kubernetes sans modifier les définitions Kubernetes des ressources.

Kubernetes inclut de nombreuses fonctionnalités prédéfinies pour gérer les cycles de vie des composants et garantir la disponibilité et la santé de vos applications. Cependant, pour tirer parti de ces fonctionnalités, Kubernetes doit comprendre comment surveiller et interpréter la santé de votre application. Pour ce faire, Kubernetes vous permet de définir les sondesliveness etreadiness.

Les sondes Liveness permettent à Kubernetes de déterminer si une application d'un conteneur est active et en cours d'exécution. Kubernetes peut périodiquement exécuter des commandes dans le conteneur pour vérifier le comportement de base d'une application ou envoyer des requêtes réseau HTTP ou TCP à un emplacement désigné pour déterminer si le processus est disponible et capable de répondre comme prévu. En cas d'échec d'une sonde d'activité, Kubernetes redémarre le conteneur pour tenter de rétablir la fonctionnalité dans le pod.

Les sondes de disponibilité sont un outil similaire utilisé pour déterminer si un module est prêt à gérer le trafic. Les applications d’un conteneur peuvent devoir exécuter des procédures d’initialisation avant d’être en mesure d’accepter les demandes des clients ou peuvent avoir besoin de recharger lorsqu’elles sont informées de la nouvelle configuration. Lorsqu'une analyse de disponibilité échoue, au lieu de redémarrer le conteneur, Kubernetes arrête d'envoyer des requêtes au pod temporairement. Cela permet à la nacelle de terminer ses routines d'initialisation ou de maintenance sans nuire à la santé du groupe dans son ensemble.

En combinant des sondes d'activité et de préparation, vous pouvez demander à Kubernetes de redémarrer automatiquement les pods ou de les supprimer des groupes de back-end. La configuration de votre infrastructure pour tirer parti de ces fonctionnalités permet à Kubernetes de gérer la disponibilité et la santé de vos applications sans opération supplémentaire.

Un peu plus tôt, lorsque nous avons abordé certains principes de base de la conception de pod, nous avons également mentionné que d’autres objets Kubernetes s’appuient sur ces primitives pour offrir des fonctionnalités plus avancées. Undeployment, l'un de ces objets composés, est probablement l'objet Kubernetes le plus couramment défini et manipulé.

Les déploiements sont des objets composés qui s'appuient sur d'autres primitifs Kubernetes pour ajouter des fonctionnalités supplémentaires. Ils ajoutent des fonctionnalités de gestion du cycle de vie aux objets intermédiaires appelésreplicasets, comme la possibilité d'effectuer des mises à jour progressives, de revenir aux versions antérieures et de passer d'un état à l'autre. Ces jeux de réplicas vous permettent de définir des modèles de pod pour la création et la gestion de plusieurs copies d'une même conception de pod. Cela vous aide à faire évoluer facilement votre infrastructure, à gérer les exigences de disponibilité et à redémarrer automatiquement les pods en cas de défaillance.

Ces fonctionnalités supplémentaires fournissent un cadre administratif et des capacités d'auto-guérison à l'abstraction relativement simple des pods. Les pods sont les unités qui exécutent les charges de travail que vous définissez, mais ce ne sont pas les unités que vous devriez normalement configurer et gérer. Pensez plutôt aux pods comme à un bloc de construction capable d'exécuter des applications de manière robuste lorsqu'ils sont configurés via des objets de niveau supérieur, tels que des déploiements.

Les déploiements vous permettent de provisionner et de gérer des ensembles de modules interchangeables afin de faire évoluer vos applications et de répondre aux demandes des utilisateurs. Cependant, le routage du trafic vers les pods provisionnés est une préoccupation distincte. Au fur et à mesure que les pods sont échangés dans le cadre de mises à jour progressives, redémarrés ou déplacés en raison d'échecs de l'hôte, les adresses réseau précédemment associées au groupe en cours changent. Kubernetesservices vous permet de gérer cette complexité en conservant les informations de routage pour les pools dynamiques de pods et en contrôlant l'accès aux différentes couches de votre infrastructure.

Dans Kubernetes, les services sont des mécanismes spécifiques qui contrôlent la façon dont le trafic est routé vers des ensembles de pods. Qu'il s'agisse de transférer le trafic de clients externes ou de gérer les connexions entre plusieurs composants internes, les services vous permettent de contrôler la manière dont le trafic doit être traité. Kubernetes mettra alors à jour et maintiendra toutes les informations nécessaires pour transférer les connexions vers les pods concernés, même si l'environnement change et que le paysage réseau change.

Kubernetes offre une grande flexibilité dans la définition et le contrôle des ressources déployées sur votre cluster. En utilisant des outils commekubectl, vous pouvez impérativement définir des objets ad-hoc à déployer immédiatement sur votre cluster. Bien que cela puisse être utile pour déployer rapidement des ressources lors de l’apprentissage de Kubernetes, cette approche présente des inconvénients qui la rendent indésirable pour une administration de production à long terme.

L’un des problèmes majeurs de la gestion impérative est qu’elle ne conserve aucun enregistrement des modifications que vous avez déployées dans votre cluster. Cela rend difficile voire impossible la récupération en cas de défaillance ou le suivi des modifications opérationnelles appliquées à vos systèmes.

Heureusement, Kubernetes fournit une syntaxe déclarative alternative qui vous permet de définir complètement les ressources dans des fichiers texte, puis d'utiliserkubectl pour appliquer la configuration ou la modification. Le stockage de ces fichiers de configuration dans un référentiel de contrôle de version constitue un moyen simple de surveiller les modifications et de l'intégrer aux processus de révision utilisés pour d'autres parties de votre organisation. La gestion basée sur les fichiers facilite également l’adaptation de modèles existants à de nouvelles ressources en copiant et en modifiant les définitions existantes. Le stockage de vos définitions d'objet Kubernetes dans des répertoires versionnés vous permet de conserver un instantané de l'état de votre cluster souhaité à chaque instant. Cela peut s'avérer très utile lors des opérations de récupération, des migrations ou lors de la recherche de la cause première des modifications non intentionnelles introduites dans votre système.

Gérer l'infrastructure qui exécutera vos applications et apprendre à tirer le meilleur parti des fonctionnalités offertes par les environnements d'orchestrations modernes peut être décourageant. Cependant, de nombreux avantages offerts par des systèmes tels que Kubernetes et des technologies telles que les conteneurs deviennent plus clairs lorsque vos pratiques de développement et d'exploitation s'alignent sur les concepts sur lesquels l'outillage est construit. L'architecture de vos systèmes à l'aide des modèles Kubernetes excelle et sa compréhension de la capacité de certaines fonctionnalités à atténuer certains des défis associés aux déploiements extrêmement complexes peut améliorer votre expérience de fonctionnement sur la plate-forme.