Qu'est-ce qu'un Service Mesh ?

Introduction au Service Mesh

Le service mesh est une infrastructure configurable utilisée pour gérer les communications interservices des systèmes de microservices. Il vise à traiter le trafic entre les microservices, également appelé trafic est-ouest.

Dans les applications cloud-native, une application peut être composée de centaines de services. Chaque service peut avoir plusieurs instances, et chacune de ces instances peut constamment changer. Dans un environnement d'exécution aussi complexe, la manière de fournir aux utilisateurs un accès fiable et de maintenir les services en fonctionnement stable est devenue un énorme défi. Ainsi, une solution appelée service mesh est née.

Le service mesh est comme le TCP/IP entre les microservices, qui gère les fonctions interservices comme les appels réseau, la limitation de débit, la surveillance, etc. Nous appliquons principalement le service mesh à la plateforme Kubernetes. De plus, le modèle le plus classique est appelé sidecar, qui abstrait certaines fonctions générales dans un conteneur sidecar et le monte avec le conteneur de service dans le même pod. L'image ci-dessous montre pourquoi on l'appelle service mesh.

Le sidecar n'est pas le seul modèle qui applique le service mesh ; en plus de cela, nous avons le modèle DaemonSet et le modèle Ambient mesh :

• La différence entre le modèle DaemonSet et le modèle sidecar est que le modèle DaemonSet ne permet qu'à chaque nœud du cluster Kubernetes d'exécuter un seul pod, et ce pod fonctionne comme un proxy sidecar. Par rapport au modèle sidecar, le modèle DaemonSet utilise beaucoup moins de ressources machine, mais il présente des inconvénients tels qu'une isolation médiocre, des appels de ressources difficiles à prévoir, etc. Vous pouvez trouver plus de différences dans cet article : Sidecars et DaemonSets : Bataille des modèles de conteneurisation.

• Ambient mesh est un nouveau mode de plan de données introduit par Istio le 7 septembre 2022. Pour résoudre le problème de couplage de l'infrastructure et du déploiement du mesh, Ambient mesh sépare le proxy du plan de données du pod d'application afin qu'il puisse être déployé séparément.

Ambient mesh divise le plan de données en une couche de superposition sécurisée et une couche de traitement L7 : La couche de superposition sécurisée gère des fonctions telles que le routage TCP, les métriques de surveillance, la journalisation des accès, le tunneling mTLS ; en plus de toutes les fonctions de la couche de superposition sécurisée, la couche de traitement L7 a de nombreuses autres fonctions comme le contrôle du trafic sur le routage HTTP, l'observabilité, et réalise des politiques d'autorisation riches en L7.

En outre, Ambient mesh utilise un agent partagé appelé ztunnel (tunnel de confiance zéro), qui fonctionne à chaque nœud à l'intérieur du cluster Kubernetes et connecte et authentifie de manière sécurisée les charges de travail à l'intérieur du mesh. Vous pouvez lire cet article si vous souhaitez en savoir plus sur le mode Ambient mesh : Introducing Ambient Mesh

Pourquoi avons-nous besoin du service mesh ?

Avant que le service mesh ne devienne populaire, la gouvernance des services de nombreuses architectures de microservices était réalisée grâce à la collaboration entre le framework de microservices et la plateforme de contrôle. Cependant, cette méthode présente les problèmes suivants :

1. Couplage étroit entre le framework et le service, ce qui rend la maintenance globale difficile et complexe. De plus, les développeurs doivent comprendre les bibliothèques publiques, ce qui les empêche de se concentrer sur les implémentations de service.
2. Il faut maintenir un framework multi-langage, ce qui augmente les coûts de maintenance.
3. Le microservice a un coût de mise à niveau élevé, et il est généralement nécessaire de redémarrer le service pendant la mise à niveau.
4. Il existe des frameworks avec de nombreuses versions différentes en ligne, ce qui oblige à considérer une compatibilité complexe.

Pour résoudre ces problèmes, l'ancien ingénieur de Twitter Willian Morgan, l'un des fondateurs de Linkerd, a proposé le concept de "Service Mesh". Le service mesh utilise un modèle sidecar pour découpler l'infrastructure de la logique de service sans affecter l'application, ce qui permet une mise à niveau et une O&M unifiées par langage.

Le service mesh déplace des fonctions telles que le contrôle du trafic, l'observabilité et les communications sécurisées vers les composants de base ; ainsi, les développeurs n'ont pas à se soucier des implémentations concrètes de la couche de communication et de la gestion des services. Les développeurs peuvent laisser tout le travail lié à la communication au service mesh et se concentrer sur le développement des services. Sur la base de ces caractéristiques, le service mesh peut nous aider à résoudre les problèmes mentionnés précédemment.

Comment fonctionne le service mesh ?

Le service mesh n'ajoute pas de nouvelles fonctions à l'environnement d'exécution de l'application, donc toutes les applications au sein d'un framework ont encore besoin de règles correspondantes pour spécifier comment envoyer des requêtes de A à B. La différence est que le service mesh extrait les communications interservices de la gestion des logiques et les abstrait ensuite en une couche d'infrastructure.

Actuellement, la plupart des service meshes utilisent l'architecture plan de données + plan de contrôle, comme illustré ci-dessous :

Le plan de contrôle

Le plan de contrôle gère et configure le plan de données et applique des stratégies pendant l'exécution du service. Toutes les instances à l'intérieur du plan de contrôle avec un seul service mesh partagent les mêmes ressources de configuration.

Le plan de contrôle se concentre davantage sur la livraison et les stratégies comme la sécurité, l'observabilité et le contrôle du trafic. Il collecte également les données de télémétrie du plan de données afin que les DevOps puissent les utiliser.

Le plan de données

Le plan de données fonctionne généralement comme un proxy et est composé de nombreux proxies sidecar. Le sidecar fonctionne en parallèle avec les instances de service et contrôle le trafic de l'application de service en interceptant le flux de données du service.

Comme mentionné précédemment, le service mesh est réalisé en implémentant un modèle sidecar dans Kubernetes et en l'encapsulant dans un conteneur. Le sidecar suggère d'utiliser un conteneur supplémentaire pour étendre et renforcer le conteneur principal, et ce conteneur supplémentaire est appelé conteneur sidecar, qui est alloué dans le même pod que le conteneur de service. D'autre part, le service mesh est un réseau maillé composé de ces proxies sidecar.

Applications du service mesh

Dans l'architecture de microservices, les ingénieurs chiffrent généralement les services publics exposés ou limitent l'accès pour protéger le service, mais ils ignorent la sécurité des communications internes aux clusters. Jusqu'à présent, de nombreuses applications de microservices manquent encore de chiffrement des communications interservices, et le trafic interne du cluster est même transféré au format de données brutes. Par conséquent, le trafic interne est très susceptible de subir des attaques d'écoute et des attaques MITM (Man-in-the-middle attack).

Pour éviter les attaques contre le trafic interne du cluster, nous utilisons le mTLS pour chiffrer les données de trafic. Le mTLS peut sécuriser la sécurité des communications entre les microservices au sein du service mesh. Il utilise la technologie de chiffrement pour authentifier chaque microservice et chiffrer mutuellement le trafic interservices.

Même si nous pouvons directement définir la stratégie de sécurité des communications à l'intérieur du microservice et implémenter l'authentification d'identité et le chiffrement, il est encore très inefficace d'implémenter la même fonction individuellement dans chaque microservice. L'ajout d'une nouvelle fonction nécessite de modifier les codes du service et d'envahir la logique du service. De plus, même si nous pouvons implémenter la nouvelle fonction, les itérations, mises à niveau et tests ultérieurs nécessiteront encore que les développeurs passent plus de temps à maintenir. Ainsi, les développeurs ne peuvent pas se concentrer sur le développement des fonctions de service.

Au lieu de cela, si nous utilisons le service mesh, nous pouvons fournir une communication mTLS sans que le service d'origine n'en soit conscient. Par conséquent, dans le service mesh, nous déplaçons toutes les fonctions liées à la communication vers les proxies sidecar.

Lorsque deux microservices doivent communiquer, le proxy sidecar établit d'abord une connexion mTLS, et il envoie le trafic chiffré via cette connexion mTLS. Le sidecar échange des certificats et s'authentifie mutuellement par l'autorité de certification. Avant de se connecter, le sidecar examine la stratégie d'authentification envoyée par le plan de contrôle pour déterminer s'il permet au microservice de communiquer. Si la communication est autorisée, le sidecar utilise la clé de communication générée pour établir des connexions sécurisées et chiffrer les données de communication entre les microservices. Pendant tout le processus, les applications de service ne sont pas affectées, réduisant ainsi les tracas des développeurs.

À partir de ce scénario, tout le monde peut comprendre pourquoi le service mesh peut étendre les fonctions actuelles sans affecter le service actuel. Mais, bien sûr, en plus de réaliser la fonction de configuration de la sécurité du trafic interne, qui est similaire au mTLS, le service mesh peut également étendre rapidement des fonctions comme le contrôle du trafic, l'observabilité et le protocole de codec en modifiant la configuration du plan de contrôle.

Conclusion

Cet article présente brièvement les concepts de base du service mesh, son principe de fonctionnement et les avantages qu'il nous apporte. Le service mesh révolutionne l'architecture des microservices et aide les développeurs à se débarrasser de l'environnement d'exécution complexe des microservices pour se concentrer sur le développement des fonctions de service.

Même si le service mesh résout de nombreux points douloureux dans l'architecture des microservices, il a encore des limites. La complexité du développement logiciel est éternelle, et elle est simplement transférée d'une partie à une autre. Lorsque nous abstraisons la gestion des services dans une couche séparée, nous devons faire face à des difficultés supplémentaires d'O&M et à des augmentations des liens de trafic. De plus, le service mesh doit être utilisé dans un environnement cloud-native, ce qui impose une barre plus élevée aux compétences professionnelles et à l'expérience de travail des DevOps. C'est pourquoi nous disons que la technologie est juste un outil pour résoudre des problèmes, mais nous devons peser les avantages que le service mesh apporte selon son application pratique.

Avec le développement explosif du cloud-native et l'optimisation du service mesh, le service mesh remplacera probablement entièrement l'architecture des microservices à l'avenir et deviendra le premier choix de chaque entreprise pour la reconstruction des microservices et de l'architecture cloud-native.

Si vous souhaitez en savoir plus sur la gestion des API, contactez-nous à tout moment : https://api7.ai/contact.