Qu’est-ce qu’un service Mesh ? Pourquoi sont-ils importants ? –
Un service mesh est une couche d’infrastructure qui facilite la communication entre les composants de l’application. Les maillages fournissent des fonctionnalités telles que la découverte de services, l’équilibrage de charge et l’observabilité.
Les maillages de services se trouvent généralement dans les systèmes distribués composés de microservices. Le maillage permet à différents services d’échanger des données. Il ne gère que le trafic interne, le transmettant à une passerelle API ou à un nœud périphérique pour servir les utilisateurs. Les maillages populaires incluent Linkerd et Istio.
Sommaire
Qu’y a-t-il à l’intérieur du maillage ?
Le concept de base d’un service mesh est assez simple. La couche encapsule des proxys de réseau qui acheminent le trafic vers des services individuels. Une couche de contrôle gère les appels réseau entre les services et orchestre l’utilisation des proxys.
L’objectif fondamental du maillage est de faciliter et de fiabiliser la communication des services. Prenons une simple paire de services : une API et un système d’authentification distinct. L’API devra s’interfacer avec le service d’authentification lorsqu’elle recevra des demandes.
Avec un service mesh, vous obtenez une communication fiable entre les services en utilisant des identifiants connus. Votre API peut envoyer des appels réseau au auth-service
nom d’hôte et soyez sûr qu’il sera toujours résolu correctement, même si le service d’authentification est déplacé vers un autre emplacement du centre de données. Le maillage de services agit pour acheminer de manière transparente les demandes vers le service approprié.
L’utilisation d’un maillage de services facilite le déplacement des services. La logique de communication réseau codée en dur peut rapidement devenir contraignante. Un maillage vous offre plus de flexibilité pour répartir vos charges de travail à l’avenir.
Comment les Service Mesh sont-ils implémentés ?
La plupart des maillages de services modernes sont formés de deux composants : un plan de contrôle et un plan de données. La fonctionnalité de base appartient au plan de données, qui s’occupe des données circulant dans le système.
Chaque requête au maillage sera traitée par le plan de données. Il découvrira le service approprié à utiliser, effectuera toutes les actions de journalisation et activera les comportements conditionnels pour filtrer et rediriger le trafic.
Les services font généralement partie de votre application et peuvent donc inclure une logique de routage. Le plan de données inspecte les règles de configuration pour déterminer le point de terminaison final en fonction des en-têtes HTTP, des paramètres de demande et d’autres valeurs de la demande.
Alors que le plan de données bourdonne d’activité, le plan de contrôle est relativement plus simple. Il supervise les proxys dans le plan de données et fournit une API pour que vous puissiez interagir avec eux.
Ce diagramme du projet Istio illustre comment les composants s’emboîtent. Chaque service obtient son propre proxy. Le trafic entrant transite par les proxys. Ils peuvent communiquer avec le plan de contrôle pour découvrir d’autres services. Les proxys sont communément appelés « side-cars » car ils fonctionnent parallèlement au service qu’ils représentent.
Autres fonctions de service Mesh
Les maillages de services fournissent généralement des fonctionnalités supplémentaires au-delà de la découverte de services de base. Vous trouverez généralement l’équilibrage de charge, l’authentification au niveau de la demande et la prise en charge du chiffrement des données. Le trafic crypté peut traverser le maillage mais être transmis à vos services sous forme décryptée.
Votre maillage offrira généralement des protections contre les pannes de réseau transitoires. Les nouvelles tentatives automatiques, les basculements et les disjoncteurs rendent la communication entre les services plus résiliente. L’utilisateur final est moins susceptible de voir un état d’erreur grave. Ces capacités importantes seraient difficiles et coûteuses à mettre en œuvre à la main.
De même, les maillages de services intègrent des optimisations de performances qui aident à minimiser les frais généraux. Le maillage peut conserver les connexions aux services pour une réutilisation ultérieure, réduisant ainsi la latence lors de la prochaine requête.
Les couches de maille offrent également des protections de sécurité. Vous pouvez mettre en œuvre des politiques de contrôle d’accès au niveau du maillage qui rejettent le trafic avant qu’il n’atteigne vos services. Si vous souhaitez un limiteur de débit API global, l’intégrer à la configuration du maillage l’appliquera à tous vos services – présents et futurs.
Qu’en est-il des inconvénients?
Le plus grand défi autour des maillages de services est la complexité supplémentaire qu’ils apportent. Bien qu’ils visent à simplifier la mise en réseau des microservices, ils introduisent également leur propre courbe d’apprentissage.
Les développeurs devront se familiariser avec une autre couche au-dessus de leurs services existants. Les terminologies de maillage, telles que les proxys et les side-cars, s’ajoutent à la liste déjà longue des ressources Kubernetes gérées par les équipes d’exploitation.
Bien que les maillages ajoutent leurs propres améliorations de performances, certains déploiements peuvent constater une réduction globale du débit du réseau. Le maillage ajoute une nouvelle couche que les demandes doivent traverser, ce qui a un impact sur l’efficacité globale. Ceci est normalement plus visible si vous stockez votre maillage avec de nombreuses règles de routage.
Quand devriez-vous utiliser un service Mesh ?
Les maillages de services fonctionnent mieux lorsque vous êtes pleinement engagé dans les conteneurs et les microservices. Ils sont conçus pour résoudre les problèmes liés à l’exécution de systèmes distribués à grande échelle en production. Les déploiements plus petits peuvent toujours bénéficier d’un maillage, mais peuvent également utiliser des approches de mise en réseau plus simples, telles que les ressources réseau intégrées de Kubernetes.
Les maillages sont particulièrement utiles lorsque vous lancez fréquemment de nouveaux services ou que vous les distribuez sur plusieurs serveurs. Un maillage permet aux développeurs de se concentrer sur les fonctionnalités, au lieu de s’ennuyer à connecter différents services entre eux. Au fur et à mesure que vous déployez une flotte de services en croissance constante, vous passerez plus de temps à gérer la communication de service à service. Un maillage automatise la plupart de cette configuration, vous n’avez donc pas besoin de penser à la découverte et au routage des services.
Cette approche aide également votre système à devenir plus observable. Toutes les demandes transitent par le maillage afin que vous puissiez implémenter la journalisation et le traçage au niveau de l’infrastructure. Cela fournit une voie plus simple pour le diagnostic et la résolution des problèmes de routage. Sans maillage, vous pourriez avoir des dizaines de services qui se transmettent tous des informations directement les uns aux autres. Il est donc difficile de trouver l’origine d’un problème.
Les maillages de services les plus populaires sont faciles à configurer. Istio et Linkerd ont tous deux des guides de démarrage bien documentés pour vous aider à déployer un maillage dans votre cluster Kubernetes. Cela vaut la peine d’expérimenter même si vous n’êtes pas encore sûr que votre système est à l’échelle du maillage. S’en tenir à la communication directe des services pendant trop longtemps pourrait restreindre votre capacité à lancer de nouveaux services de manière opportune et fiable.