Une introduction à la messagerie microservice dans Kubernetes
Introduction
Vous avez du mal à connecter et à maintenir vos microservices dans Kubernetes? À mesure que le nombre de microservices augmente, la difficulté et la complexité de la maintenance de votre flotte de services distribués augmentent de façon exponentielle. La messagerie peut fournir une solution propre à ce problème, mais les files d'attente de messages héritées présentent leur propre ensemble de problèmes.
Dans cet article, je vais partager les avantages de la messagerie dans Kubernetes et les difficultés que peuvent présenter les solutions héritées. Je vais également examiner brièvement une solution à ce problème - KubeMQ - qui tente de résoudre certains des problèmes traditionnels de messagerie dans Kubernetes.
Pourquoi la messagerie dans Kubernetes?
Au fur et à mesure que l'architecture basée sur des microservices se développe, il peut être difficile de connecter chacun de ces services distribués. Les problèmes de sécurité, de disponibilité et de latence doivent être résolus pour chaque interaction point à point. De plus, à mesure que le nombre de services augmente, le nombre de connexions potentielles augmente également. Par exemple, considérons un environnement avec seulement trois services. Ces trois services ont un total de trois connexions potentielles:
Cependant, à mesure que cela augmente jusqu'à cinq services, le nombre de connexions potentielles passe à 10:
Avec 20 services, le nombre de connexions potentielles est de 190! Pour référence, voir le tableau ci-dessous:
Ceci n'est clairement pas viable pour les organisations disposant d'un large portefeuille de services. Cependant, grâce à l'utilisation d'une file d'attente de messages, nous pouvons centraliser ces connexions. Le nombre de connexions étant égal au nombre de services, il en résulte une solution qui évolue linéairement. Voir ci-dessous:
Pour une grande flotte de microservices, cela simplifie considérablement les problèmes de sécurité et de disponibilité, car chaque microservice doit communiquer principalement avec la file d'attente de messages.
C'est la raison même pour laquelle l'implémentation d'une architecture de file d'attente de messages est considérée comme la meilleure pratique lors de l'exécution d'un grand nombre de microservices dans Kubernetes. En conséquence, la sélection de la file d'attente de messages est une décision d'une importance cruciale, car toute l'architecture dépendra de la fiabilité et de l'évolutivité de celle-ci. file d'attente de messages.
Enfin, le déploiement de la file d'attente de messages dans Kubernetes vous permet d'éviter le verrouillage de la plateforme. Il existe un certain nombre de solutions de messagerie spécifiques à la plate-forme des principaux fournisseurs de cloud, mais l'exécution d'une solution indépendante de la plate-forme vous permet de maintenir la cohérence de votre architecture de microservices, quelle que soit votre plate-forme. Kubernetes est la solution d'orchestration de facto et est pris en charge par tous les principaux fournisseurs de cloud.
Maintenant que nous avons établi pourquoi la messagerie est utile, allons un peu plus loin. Cela semble être une solution si simple, alors qu'est-ce qui pourrait être si difficile?
Qu'est-ce qui est difficile avec la messagerie dans Kubernetes?
Il y a un certain nombre de problèmes lors de la tentative d'exécuter une file d'attente de messages dans Kubernetes. Examinons les différences entre un microservice classique et votre file d'attente de messages standard. J'ai résumé certaines des différences dans le tableau suivant:
Premièrement, les microservices sont conçus pour être légers. C'est à certains égards le résultat naturel d'être un microservice - chaque service remplit un seul but, et peut donc être plus petit et plus agile. En revanche, les files d'attente de messages héritées sont de grandes applications gourmandes en ressources. La dernière version d'IBM MQ au moment de la rédaction de cet article a exigences matérielles importantes . Par exemple,> 1,5 Go d'espace disque et 3 Go de RAM.
De plus, un microservice typique est sans état, car il ne contient aucune partie de l'état de l'application en soi. Cependant, de nombreuses files d'attente de messages héritées fonctionnent efficacement comme des bases de données et nécessitent un stockage permanent. Stockage persistant L'âge dans Kubernetes est mieux géré avec le Persistent Volume API , mais cela nécessite des solutions de contournement pour les solutions héritées.
Ces différences dans l'utilisation des ressources mènent naturellement au point suivant: les microservices sont simples à déployer. Les microservices sont conçus pour se déployer rapidement et dans le cadre d'un cluster. D'autre part, en raison de leur nature gourmande en ressources, les files d'attente de messages héritées ont des instructions de déploiement complexes et nécessitent une équipe dédiée pour la configuration et la maintenance.
Ensuite, les microservices sont conçus être évolutif horizontalement. La mise à l'échelle horizontale est effectuée via le déploiement d'instances supplémentaires d'un service. Cela permet à un service d'évoluer presque à l'infini, d'avoir une haute disponibilité et est généralement moins cher. En revanche, en raison des besoins en ressources et des difficultés de déploiement susmentionnés, les files d'attente de messages héritées doivent être mises à l'échelle verticalement - en d'autres termes, une machine plus grande. En plus des limitations physiques (une seule machine ne peut être que si puissante), les machines plus grandes sont chères.
Ces problèmes nécessitent généralement un investissement et un temps importants pour être résolus, ce qui réduit la valeur que la file d'attente de messages fournit à votre architecture globale. Cependant, aucun de ces problèmes n'est inhérent à la messagerie; ils sont plutôt un artefact de la conception et de la conception des principales files d'attente de messages.
Alors, comment pouvons-nous résoudre ces problèmes? Jetons un coup d'œil à une option: utiliser une file d'attente de messages native de Kubernetes telle que KubeMQ.
Une approche native de Kubernetes
KubeMQ est un moyen de résoudre les problèmes de messagerie liés à Kubernetes. Jetons un coup d'œil à plusieurs façons d'y parvenir.
Premièrement, je t est natif Kubernetes , ce qui signifie qu'il s'intègre bien à Kubernetes et est simple à déployer en tant que cluster Kubernetes. Opérateurs qui vous permettent d'automatiser des tâches au-delà de ce que Kubernetes fournit nativement sont fournis avec le produit pour la gestion du cycle de vie . La La persistance du cluster est prise en charge via le volume local et les PVC . Être natif de Kubernetes signifie également qu'il est indépendant du cloud et qu'il peut donc également être déployé sur site ou dans des environnements de cloud hybride.
De plus, c'est léger : le conteneur Docker fait environ 30 Mo, bien loin du Go d'espace requis par les solutions héritées. Cela lui permet d'être déployé pratiquement n'importe où et permet de nouveaux cas d'utilisation, tels que les déploiements périphériques pour la prise en charge des appareils Internet des objets. Malgré sa petite taille, il prend en charge une variété de modèles de messagerie.
Enfin, il est extensible . Grâce à l'utilisation de ponts, de cibles et de sources, ces connecteurs prédéfinis lui permettent de se connecter à une variété d'autres applications et services, réduisant ainsi le besoin d'intégrations personnalisées. Les ponts permettent aux clusters KubeMQ de passer des messages entre eux, permettant à KubeMQ de connecter Étant donné que KubeMQ est petit, vous pouvez l'essayer pour vous-même avec un installation locale de minikube ou accès à tout autre cluster Kubernetes.
- Inscrivez-vous pour un compte (gratuit) et obtenez un jeton de licence.
- Exécutez kubectl apply -f https://get.kubemq.io/deploy?token =
Vous pouvez vérifier l'état de votre cluster avec kubectl get kubemqclusters -n kubemq. Pour plus d'informations, consultez le documents officiels .
Résumé
Dans cet article, j'ai passé en revue les avantages d'une file d'attente de messages, examiné les difficultés de mise en œuvre messagerie dans Kubernetes, et j'ai jeté un coup d'œil à KubeMQ - une solution légère et native de Kubernetes qui peut offrir plusieurs avantages par rapport aux solutions héritées.
Également publié sur: https://dzone.com/articles/microservice-messaging-in-kubernetes"
