Partie 2 : Gérer des flux internes d’une application avec les Services Mesh

Le but de cette série d’articles est de comprendre ce qu’est une architecture orientée microservices, quels en sont ses avantages, quels en sont ses limites/défis et comment les concepts de Service Mesh et API-Gateway font partie de leur écosystème.

Cette série d’articles est définie comme suit :

• Partie 1 : Comprendre ce qu’est une architecture orientée microservices
• Partie 2 : Gérer des flux internes d’une application avec les Services Mesh
• Partie 3 : Istio, un Service Mesh utilisé dans un de nos projets (article technique) (bientôt disponible)
• Partie 4 : Gérer les flux externes d’une application avec les API-Gateway (bientôt disponible)
• Partie 5 : Synthèse (bientôt disponible)

Gérer des flux internes d’une application avec les Services Mesh

Cet article se base sur les concepts décrits dans la Partie 1 : Comprendre ce qu’est une architecture microservice

Un Service Mesh est un système distribué qui cohabite avec l’application et qui permet d’assembler des microservices en interceptant leurs trafics (flux internes). Cette interception de trafic se fait en définissant des règles spécifiant comment un microservice doit communiquer avec un autre.

Le Service Mesh opère donc d’une manière transversale en spécifiant des règles non-fonctionnelles s’appliquant aux flux entre microservices et à des instances de microservices [1]. Le Service Mesh permet donc de modifier et d’optimiser les flux internes d’une application. Par exemple : définir une règle de routage/load balancing, définir une règle de sécurité ou encore récupérer des données d’observabilité.

Le Service Mesh aidera également à intégrer les outils nécessaires à la gestion de microservices (voir partie 1 : Avantage et défis), il s’agira notamment de la gestion de l’observabilité, de la sécurité ou encore des pipelines de déploiement continu.

Comment fonctionne un Service Mesh

Le Service Mesh est basé sur le patron de conception proxy.

Pour intercepter les flux internes de données, le Service Mesh déploie un proxy [2] devant chaque microservice. L’ensemble de tous ces proxies forment ce qu’on appelle le Data Plane du Service Mesh. Chaque proxy intercepte tous les flux entrants ou sortants d’un microservice. Il peut également appliquer des règles ou des politiques sur les flux (par exemple, des politiques de sécurité). Les politiques sont gérées globalement par le Control Plane. L’utilisateur définit donc des politiques dans le Control Plane et celui-ci se charge d’envoyer les configurations au Data Plane (ici proxies). Le Data Plane remonte également des métriques vers le Control Plane dans un but d’observabilité.

Les fonctionnalités d’un Service Mesh

Actuellement, les Services Mesh sont en pleine expansion. Beaucoup de projets voient le jour, certains ne sont pas encore matures, d’autres ne proposent qu’un nombre réduit de fonctionnalités.

Les fonctionnalités principales des Services Mesh peuvent être exposées comme suit :

1. La définition de règles/politiques de routage et de load balancing [3] : il s’agit de répondre aux problématiques de résilience, de robustesse ou encore de scalabilité [4]. Exemples : définir une règle de routage permettant d’orienter une requête vers une version spécifique de l’application, définir un algorithme à utiliser pour le load balancing, définir un nombre maximum de requêtes entrantes, gérer une politique d’éviction d’instances de microservice [5].
2. La définition des règles/politiques de sécurité : il s’agit de répondre aux problématiques relatives aux chiffrements des connexions, à l’authentification des requêtes, et parfois, aux politiques d’autorisation. Exemples : mise en place d’une authentification mutuelle (mTLS [6]) entre 2 microservices, gérer les liens avec un service de gestion des identités et des accès (IAM [7])
3. Les intégrations avec des outils améliorant l’observabilité de l’application : il s’agit de répondre aux problématiques relatives à l’obtention d’une vue globale de l’observabilité de l’application. Exemple : visualisation de la topologie de l’application, traçage des requêtes, agrégation des logs, état de santé des services.
4. La création de règles/politiques en relation avec les fédérations de cluster (multi-sites)  : il s’agit de répondre aux problématiques de gestion de plusieurs Services Mesh sur différents sites. Ces outils, appelés MultiMesh, permettent de configurer des Services Mesh via un Meta Control Plane. Les MultiMesh se connectent aux Services Mesh via des interfaces. Ils permettent, entre autres, de définir des politiques de résilience/routing multisites.

Comme mentionné précédemment, il existe de nombreuses implémentations de Services Mesh. Durant la conférence KubeCon2021, 3 implémentations de Services Mesh ont été souvent citées :

1. Istio est actuellement un des Service Mesh les plus abouti en termes de fonctionnalités. On y retrouvera les fonctionnalités de routing et load balancing, les fonctionnalités liées à la sécurité, et un panel d’outils intégrés pour gérer l’observabilité. Un de nos use-cases a été développé avec Istio. (voir article SamobiGrow).
2. Kuma peut être considéré comme un des Service Mesh les plus flexibles via notamment sa facilité à intégrer K8s et des VMs ensemble. Il intègre nativement les fonctionnalités liées au routing, à la sécurité, l’observabilité et le MultiMesh.
3. Linkerd est considéré comme le Service Mesh le plus léger. Il est orienté performance mais, fonctionnellement, il est moins complet qu’Istio. Les fonctionnalités les plus développées sont la sécurité et l’observabilité.

Pour aller plus loin

Les articles suivants permettent d’en savoir plus sur les Services Mesh :

• Spécifications des interfaces des ServiceMesh, utilisées pour créer des MultiMesh (SMI)Service Mesh Interface
• Comparaison de différentes implémentation de Services Mesh : INNOQ
  Pourquoi est il nécessaire de spécifier un algorithme de LoadBalancing : Ram Lakshmanan.
• Impact de l’utilisation d’un Service Mesh (Istio) sur une application : Paul Klinker

Suite suggérée : Partie 3 : Istio, un Service Mesh utilisé dans un de nos projets (article technique) (bientôt disponible)

Contact

Pour plus d’information veuillez contacter : Fabian Steels ou Valéry Ramon

Keywords : ServiceMesh, Microservice, architecture, Routing, load balancing, multimesh, mTLS, sécurité, SSO, observabilité