Scénarios d'utilisation du service mesh

Note de traduction.: cet article est écrit par Luc Perkins — développeur advocate au sein de l'organisation CNCF, qui est le foyer de projets Open Source tels que Linkerd, SMI (Service Mesh Interface) et Kuma (d'ailleurs, vous vous êtes demandé pourquoi Istio n'est pas dans cette liste ?). En essayant une fois de plus d'apporter une meilleure compréhension dans la communauté DevOps autour de la tendance actuelle appelée « service mesh », il présente 16 caractéristiques distinctes proposées par de telles solutions.

Aujourd'hui service mesh — l'un des sujets les plus chauds dans le domaine de l'ingénierie logicielle (et à juste titre !). Je trouve cette technologie incroyablement prometteuse et je rêve d'assister à sa large adoption (bien sûr, quand cela a du sens). Cependant, elle reste entourée d'un halo de mystère pour la plupart des gens. Même ceux qui sont bien familiarisés avec cela ont souvent du mal à formuler ses avantages et ce qu'elle représente vraiment (y compris votre humble serviteur). Dans cet article, je vais essayer d'éclaircir les choses en énumérant divers scénarios d'utilisation des « service meshes »*.

* Note du traducteur : ici et dans la suite de l'article, ce terme sera traduit par « service mesh » pour ce terme encore nouveau.

Mais d'abord, je voudrais faire quelques remarques :

• Je n'ai jamais travaillé avec des service meshes et ne les ai utilisés que pour des projets entrepris pour mon propre apprentissage. D'autre part, c'est moi qui ai rédigé une quantité de documentation pour le service mesh interne de l'entreprise Twitter en 2015 (à l'époque, cela ne s'appelait même pas encore « service mesh ») et qui ai participé à l'élaboration du site et de la documentation pour Linkerd, donc cela signifie quelque chose.
• Ma liste est indicative et incomplète. Il peut exister des scénarios d'utilisation inconnus pour moi, et de nouveaux cas émergeront sans aucun doute au fur et à mesure que la technologie évolue et que sa popularité grandit.
• Cependant, il ne faut pas penser que chaque implémentation existante de service mesh prend en charge tous les cas d'utilisation énumérés. Par conséquent, mes phrases comme « un service mesh peut… » doivent être lues comme « certaines, voire toutes les implémentations populaires de service mesh peuvent… ».
• L'ordre des exemples n'a pas d'importance.

Liste succincte :

• découverte de services ;
• cryptage ;
• authentification et autorisation ;
• répartition de charge ;
• circuit breaking ;
• autoscaling ;
• déploiements canari ;
• déploiements bleu-vert ;
• vérification de la santé ;
• load shedding ;
• miroir du trafic;
• isolement;
• limitation de la fréquence des requêtes, tentatives répétées et délais d'attente;
• télémetrie;
• audit;
• visualisation.

1. Détection des services

TL;DR: Connectez-vous à d'autres services sur le réseau avec des noms simples.

Les services doivent être capables de se « trouver » automatiquement les uns les autres avec des noms appropriés ― par exemple, service.api.production, pets/staging ou cassandra. Les environnements cloud se distinguent par leur élasticité, et un seul nom peut masquer de multiples instances de service. Il est évident que, dans cette situation, il est physiquement impossible de coder en dur toutes les adresses IP.

De plus, lorsqu'un service trouve un autre, il doit être en mesure d'envoyer des requêtes à ce service, sans craindre qu'elles aboutissent à une instance non fonctionnelle. En d'autres termes, la service mesh doit surveiller l'état de fonctionnement de toutes les instances de services et maintenir la liste des hôtes à jour.

Chaque service mesh implémente le mécanisme de détection des services à sa manière. Actuellement, la méthode la plus répandue consiste à déléguer à des processus externes tels que le DNS de Kubernetes. Par le passé, chez Twitter, nous utilisions pour ces objectifs un système de noms Finagle. De plus, la technologie service mesh permet l'émergence de mécanismes de nommage personnalisés (bien que je n'aie pas encore rencontré d'implémentation SM avec cette fonctionnalité).

2. Chiffrement

TL;DR: Éliminez le trafic non chiffré entre les services et laissez ce processus être automatisé et évolutif.

Il est rassurant de savoir que les intrus ne peuvent pas pénétrer votre réseau interne. Les pare-feu font cela très bien. Mais que se passe-t-il si un hacker réussit à s'introduire ? Pourra-t-il faire tout ce qu'il veut avec le trafic inter-services ? Espérons que cela ne se produise pas. Pour éviter un tel scénario, il est nécessaire de mettre en œuvre un réseau de confiance zéro (zero-trust), où tout le trafic entre les services est chiffré. La plupart des réseaux de services modernes y parviennent grâce à l'utilisation de l'authentification mutuelle TLS (mutual TLS, mTLS). Dans certains cas, le mTLS fonctionne dans des clouds et des clusters entiers (je pense que même les communications interplanétaires seront un jour organisées de la même manière).

Bien sûr, pour le mTLS, la service mesh n'est pas obligatoireChaque service peut gérer son propre TLS, mais cela signifie qu'il faudra trouver un moyen de générer des certificats, de les distribuer aux hôtes du service et d'inclure dans l'application un code qui chargera ces certificats à partir de fichiers. N'oubliez pas non plus de mettre à jour ces certificats à intervalles réguliers. Les maillages de services automatisent le mTLS avec des systèmes comme SPIFFE, qui, à leur tour, automatisent le processus d'émission et de rotation des certificats.

3. Authentification et autorisation

TL;DR: Identifiez qui est l'initiateur de la demande et déterminez ce qu'il est autorisé à faire avant que la demande n'atteigne le service.

Les services veulent souvent savoir, qui effectue la demande (authentification), et, en utilisant cette information, décident ce que ce sujet est autorisé à faire (autorisation). Dans ce cas, le pronom « qui » peut désigner :

1. D'autres services. Cela s'appelle l'« authentification peer». Par exemple, un service web veut accéder au service db. Les maillages de services résolvent généralement de tels problèmes via le mTLS : les certificats jouent alors le rôle d'identifiant nécessaire.
2. Certains utilisateurs humains. Cela s'appelle l'« authentification de la demande». Par exemple, un utilisateur haxor69 veut acheter une nouvelle lampe. Les maillages de services fournissent divers mécanismes, par exemple, JSON Web Tokens.

   Beaucoup d'entre nous ont fait cela dans le code de l'application. Une demande arrive, nous consultons la table users, trouvons l'utilisateur et comparons le mot de passe, puis vérifions la colonne permissions etc. Dans le cas du maillage de services, cela se produit avant même que la demande n'atteigne le service.

Après avoir identifié l'origine de la demande, il faut déterminer ce que ce sujet est autorisé à faire. Certains maillages de services permettent de définir des politiques de base (qui peut faire quoi) sous forme de fichiers YAML ou dans la ligne de commande, tandis que d'autres proposent une intégration avec des frameworks comme Open Policy Agent. L'objectif final est de s'assurer que vos services acceptent toutes les demandes, en supposant qu'elles proviennent d'une source fiable et cette action est autorisée.

4. Répartition de la charge

TL;DR: Distribuez la charge entre les instances de service selon un modèle précis.

Le « service » au sein d'une secte de services se compose très souvent de nombreux exemples identiques. Par exemple, aujourd'hui, le service cache se compose de 5 copies, et demain, leur nombre peut passer à 11. Les requêtes envoyées vers cachedoivent être réparties en fonction d'un objectif spécifique. Par exemple, minimiser la latence ou maximiser la probabilité d'atteindre un exemplaire fonctionnel. L'algorithme d'équilibrage de charge le plus couramment utilisé est celui du round-robin, mais il en existe de nombreux autres — comme la méthode des requêtes pondérées, (weighted) l'hachage en anneau (ring) ou la méthode du moindre nombre de requêtes (la préférence est donnée à l'exemplaire ayant le moins de requêtes).

Les équilibreurs de charge classiques ont également d'autres fonctions, telles que la mise en cache HTTP et la protection contre les DDoS, mais elles ne sont pas très pertinentes pour le trafic de type est-ouest (c'est-à-dire pour le trafic circulant au sein du centre de données – note de l'éditeur) (domaine d'application typique des service meshes). Bien sûr, il n'est pas obligatoire d'utiliser un service mesh pour l'équilibrage de charge, cependant, il permet de définir et de contrôler les politiques d'équilibrage pour chaque service à partir d'une couche de gestion centralisée, supprimant ainsi la nécessité de déployer et de configurer des équilibreurs de charge séparés dans la pile réseau.

5. Coupure de circuit

TL;DR : Arrêtez le trafic vers un service problématique et contrôlez les dommages dans les pires scénarios.

Si pour une raison quelconque le service ne peut pas gérer le trafic, le service mesh offre plusieurs options pour résoudre ce problème (d'autres seront abordées dans les sections appropriées). La coupure de circuit est l'option la plus stricte pour déconnecter un service du trafic. Cependant, cela n'a de sens que si un plan de secours est prévu. Il pourrait y avoir une contre-pression (backpressure) sur les services effectuant des requêtes (n'oubliez pas de configurer votre service mesh pour cela !), ou, par exemple, teinter la page de statut en rouge et rediriger les utilisateurs vers une autre page avec un « grand dauphin tombant » (« Twitter is down »).

Les service meshes permettent non seulement de déterminer quand la coupure aura lieu et ce que Cela sera suivi. Dans ce cas, «quand» peut inclure n'importe quelle combinaison de paramètres spécifiés : le nombre total de requêtes sur une certaine période, le nombre de connexions parallèles, les requêtes en attente, les tentatives de répétition actives, etc.

Vous ne voudriez probablement pas abuser du circuit breaking, mais c'est agréable de savoir qu'il y a un plan de secours en cas de besoin.

6. Auto-scaling

TL;DR : Augmentez ou réduisez le nombre d'instances du service en fonction des critères spécifiés.

Les service meshes ne sont pas des planificateurs, donc ils ne réalisent pas le scaling de manière autonome. Cependant, ils peuvent fournir des informations sur lesquelles les planificateurs prendront des décisions. Comme les service meshes ont accès à tout le trafic entre les services, ils disposent d'une vaste information sur ce qui se passe : quels services rencontrent des problèmes, lesquels sont sous-utilisés (les ressources qui leur sont allouées sont gaspillées), etc.

Par exemple, Kubernetes redimensionne les services en fonction de l'utilisation du CPU et de la mémoire par les pods (voir notre rapport «Auto-scaling et gestion des ressources dans Kubernetes» — note du trad.), mais si vous décidez de procéder à une mise à l'échelle en fonction de tout autre indicateur (dans notre cas - lié au trafic), une métrique spéciale sera nécessaire. Un guide comme celui-ci montre comment le faire avec Envoy, Istio et Prometheus, mais le processus est assez complexe. Nous aimerions que le service mesh le simplifie, permettant simplement de définir des conditions telles que «augmentez le nombre d'instances du service auth, si le nombre de requêtes en attente dépasse le seuil pendant une minute».

7. Déploiements canary

TL;DR : Testez de nouvelles fonctionnalités ou versions du service sur un sous-ensemble d'utilisateurs.

Disons que vous développez un produit SaaS et que vous prévoyez de lancer sa nouvelle version améliorée. Vous l'avez testée en staging, et tout s'est bien passé. Cependant, vous avez quelques inquiétudes concernant son comportement en conditions réelles. Autrement dit, il est nécessaire de tester la nouvelle version sur des cas réels, sans risquer la confiance des utilisateurs. Les déploiements canari sont parfaits pour cela. Ils permettent de montrer une nouvelle fonction à un sous-ensemble de utilisateurs. Ce sous-ensemble peut être constitué des utilisateurs les plus fidèles, de ceux qui utilisent une version gratuite du produit, ou de ceux qui se sont portés volontaires pour être des « cobayes ».

Les meshes de service mettent cela en œuvre en permettant de spécifier des critères qui déterminent qui et quelle version de l'application verra, en acheminant le trafic en conséquence. Pour les services eux-mêmes, rien ne change. La version 1.0 du service suppose que toutes les demandes proviennent d’utilisateurs qui doivent voir cette version, tandis que la version 1.1 fait de même pour ses propres utilisateurs. Pendant ce temps, vous pouvez ajuster le pourcentage de trafic entre l’ancienne et la nouvelle version, redirigeant un nombre croissant d'utilisateurs vers la nouvelle si elle fonctionne de manière stable et que vos « cobayes » donnent leur approbation.

8. Déploiements bleu-vert

TL;DR : Déployez une nouvelle fonction impressionnante, mais soyez prêt à revenir immédiatement en arrière.

Sens des déploiements bleu-vert est de déployer un nouveau service « bleu » en parallèle avec l’ancien « vert ». Si tout se passe bien et que le nouveau service fonctionne correctement, l’ancien pourra être progressivement désactivé. (Malheureusement, un jour, ce nouveau service « bleu » connaîtra le sort du « vert » et disparaîtra...) Les déploiements bleu-vert diffèrent des déploiements canari en ce sens que la nouvelle fonction couvre tous les utilisateurs (et non une partie); l'idée ici est d'avoir un « refuge » prêt en cas de problème.

Les maillages de services offrent un moyen très pratique de tester un service « bleu » et de basculer instantanément vers un « vert » opérationnel en cas de problèmes. Sans parler du fait qu'ils fournissent en parallèle une multitude d'informations (voir la section « Télémétrie » ci-dessous) sur le fonctionnement du « bleu », ce qui aide à comprendre s'il est prêt pour une exploitation complète.

Note de traduction.: Vous pouvez en savoir plus sur les différentes stratégies de déploiement dans Kubernetes (y compris les mentions canari, blue/green et d'autres) dans cet article.

9. Vérification de la santé

TL;DR : Surveillez quels instances de services sont opérationnels et réagissez à celles qui cessent de l'être.

Vérification de la santé (health check) aide à décider si les instances du service peuvent accepter et traiter le trafic. Par exemple, pour les services HTTP, la vérification de la santé peut ressembler à une requête GET vers un endpoint /health. Une réponse 200 OK signifie que l'instance est en bonne santé, toute autre réponse indique qu'elle n'est pas prête à accepter du trafic. Les maillages de services permettent de spécifier la méthode de vérification de la santé ainsi que la fréquence à laquelle cette vérification sera effectuée. Ces informations peuvent ensuite être utilisées à d'autres fins, comme par exemple pour l'équilibrage de charge et le circuit breaking.

Ainsi, la vérification de la santé ne constitue pas un scénario d'utilisation autonome, mais est généralement utilisée pour atteindre d'autres objectifs. De plus, en fonction des résultats des vérifications de santé, des actions externes (vis-à-vis des autres objectifs des maillages de services) peuvent être nécessaires : par exemple, mettre à jour la page d'état, créer une issue sur GitHub ou remplir un ticket JIRA. Et le maillage de services propose un mécanisme pratique pour automatiser tout cela.

10. Déviation de charge (load shedding)

TL;DR : Redirigez le trafic en réponse à un pic temporaire d'utilisation.

Si un service est surchargé par le trafic, vous pouvez temporairement rediriger une partie de ce trafic ailleurs (c'est-à-dire « lâcher », « déverser » (shed) vers un autre endroit). Par exemple, vers un service de secours ou un centre de données, ou vers un permanent Pulsar En conséquence, le service continuera à traiter une partie des requêtes au lieu de tomber en panne et de cesser complètement de traiter toutes les requêtes. Le rétablissement de la charge est préférable à la rupture de la chaîne, mais il est tout de même indésirable d'en abuser. Cela permet de prévenir les pannes en cascade, qui entraînent l'échec des services en aval.

11. Parallélisation/Miroitage du trafic

TL;DR : Envoyez une requête à plusieurs endroits en même temps.

Il arrive parfois qu'il soit nécessaire d'envoyer une requête (ou un certain échantillon de requêtes) à plusieurs services en même temps. Un exemple typique est d'envoyer une partie du trafic de production vers un service de staging. Le serveur web principal de la production envoie une requête au service en aval products.production et uniquement à celui-ci. Le service mesh copie intelligemment cette requête et l'envoie vers products.staging, dont le serveur web n'a même pas connaissance.

Un autre scénario d'utilisation lié au service mesh qui peut être implémenté par-dessus la parallélisation du trafic est le test de régression. Il consiste à envoyer les mêmes requêtes à différentes versions du service et à vérifier si toutes les versions se comportent de la même manière. Je n'ai pas encore rencontré d'implémentation de service mesh avec un système intégré de test de régression comme Diffy, mais l'idée elle-même semble prometteuse.

12. Isolement

TL;DR : Divisez votre service mesh en mini-réseaux.

Également connue sous le nom de segmentation, l'isolement est l'art de diviser le service mesh en segments logiquement distincts, qui ne savent rien les uns des autres. L'isolement ressemble un peu à la création de réseaux privés virtuels. La différence fondamentale est que vous pouvez toujours bénéficier de tous les avantages du service mesh (comme la découverte des services), mais avec une sécurité supplémentaire. Par exemple, si un attaquant parvient à pénétrer dans un service dans l'une des sous-réseaux, il ne pourra pas voir quels services sont en cours d'exécution dans d'autres sous-réseaux, ni intercepter leur trafic.

De plus, les avantages peuvent être organisationnels. Vous pourriez avoir envie de diviser les services en sous-réseaux en fonction de la structure de l'entreprise et de libérer les développeurs du poids cognitif causé par la nécessité de garder en tête l'ensemble du service mesh.

13. Limitation du taux de requêtes, nouvelles tentatives et délais d'attente

TL;DR : Plus besoin d'inclure dans la base de code les tâches urgentes de gestion des requêtes.

Toutes ces choses pourraient être considérées comme des cas d'utilisation distincts, mais j'ai décidé de les regrouper en raison d'une caractéristique commune : elles prennent en charge les tâches de gestion du cycle de vie des requêtes, généralement gérées par les bibliothèques d'applications. Si vous développez un serveur Web en Ruby on Rails (pas intégré avec une service mesh), qui fait des requêtes aux services backend via gRPC, l'application devra elle-même décider quoi faire si N requêtes échouent. Il faudra également déterminer quel volume de trafic ces services pourront traiter et 'hardcoder' ces paramètres à l'aide d'une bibliothèque spécifique. De plus, l'application devra décider quand il sera temps d'abandonner et de laisser expirer la requête (en cas de timeout). Et pour modifier l'un des paramètres mentionnés ci-dessus, le serveur web devra être arrêté, reconfiguré et redémarré.

Le transfert de ces tâches à la service mesh signifie non seulement que les développeurs de services n'auront plus à y penser, mais aussi qu'elles pourront être considérées de manière plus globale. Si une chaîne complexe de services est utilisée, par exemple A → B → C → D → E, il est nécessaire de prendre en compte tout le cycle de vie de la requête. Si l'objectif est d'augmenter les timeouts dans le service C, il est logique de le faire en une seule fois, et non en plusieurs étapes : en mettant à jour le code du service et en attendant que la demande de tirage soit acceptée et que le système CI déploie le service mis à jour.

14. Télémétrie

TL;DR : Collectez toutes les informations nécessaires (et pas tout à fait) des services.

La télémétrie est un terme général englobant les métriques, le traçage distribué et les logs. Les service meshes offrent des mécanismes pour collecter et traiter ces trois types de données. Ici, cela devient un peu flou, car le nombre d'options possibles est trop grand. Pour collecter des métriques, il y a Prometheus et d'autres outils, pour collecter les logs, on peut utiliser fluentd, Loki, Vector et autres. (par exemple, ClickHouse avec notre loghouse pour K8s – note du traducteur), pour le traçage distribué, il existe Jaeger et autres. Chaque service mesh peut prendre en charge certains outils et ne pas en prendre d'autres. Il sera intéressant de voir si le projet Open Telemetry peut offrir une certaine convergence.

Dans ce cas, l'avantage de la technologie service mesh est que les conteneurs sidecar peuvent, en principe, collecter toutes les données mentionnées ci-dessus à partir de leurs services. Autrement dit, vous disposez d'un système unique pour collecter la télémétrie, et le service mesh peut traiter toutes ces informations de diverses manières. Par exemple :

• suivre les logs d'un certain service dans le CLI;
• surveiller le volume des requêtes depuis le tableau de bord du service mesh;
• collecter des traces distribuées et les rediriger vers un système comme Jaeger.

Attention, jugement subjectif : En général, la télémétrie est un domaine où l'intervention forte du service mesh est indésirable. La collecte d'informations de base et le suivi en temps réel de certaines « métriques clés » comme le pourcentage de requêtes réussies et les délais sont normales, mais espérons que nous ne serons pas témoins de l'émergence de ces sortes de stacks Frankenstein qui tenteraient de remplacer des systèmes spécialisés, dont certains ont déjà fait leurs preuves et sont bien étudiés.

15. Audit

TL;DR : Celui qui oublie les leçons de l'histoire est condamné à les revivre.

L'audit est l'art d'observer des événements importants dans le système. Dans le cas du service mesh, cela peut signifier suivre qui a effectué des requêtes à des points d'extrémité spécifiques de certains services ou combien de fois, au cours du dernier mois, un événement lié à la sécurité a eu lieu.

Il est clair que l'audit est très étroitement lié à la télémétrie. La différence est que la télémétrie est généralement associée à des choses telles que la performance et l'efficacité technique, tandis que l'audit peut avoir trait à des questions juridiques et autres qui dépassent le strict domaine technique (par exemple, la conformité au RGPD — Règlement Général sur la Protection des Données de l'UE).

16. Visualisation

TL;DR : Vive React.js — source interminable d'interfaces excentriques.

Il existe peut-être un terme plus approprié, mais je ne le connais pas. Je fais simplement référence à la représentation graphique du service mesh ou de certains de ses composants. Ces visualisations peuvent inclure des indicateurs tels que les délais moyens, les informations sur la configuration des conteneurs sidecar, les résultats des vérifications de santé et des alertes.

Travailler dans un environnement orienté services entraîne une charge cognitive beaucoup plus forte par rapport à Sa Majesté le Monolithe. Par conséquent, la pression cognitive doit être réduite à tout prix. Une interface graphique banale pour une service mesh avec la possibilité de cliquer sur un bouton et d'obtenir le résultat souhaité peut avoir une importance cruciale pour la popularité croissante de cette technologie.

Non inclus dans la liste

Au départ, j'avais l'intention d'inclure quelques scénarios d'utilisation supplémentaires dans la liste, mais j'ai ensuite décidé de ne pas le faire. Voici ceux-ci avec les raisons de ma décision :

• Multi-data center. À mon avis, ce n'est pas tant un scénario d'utilisation qu'un domaine très spécifique d'application des service meshes ou d'un ensemble de fonctionnalités comme la découverte de services.
• Ingress et egress. C'est un domaine connexe, mais je me suis limité (peut-être artificiellement) au scénario d'utilisation « trafic est-ouest ». Ingress et egress méritent un article à part.

Conclusion

C'est tout pour l'instant ! Encore une fois, cette liste est assez conditionnelle et, très probablement, incomplète. Si vous pensez que j'ai omis quelque chose ou que je me suis trompé, contactez-moi sur Twitter (@lucperkins). Merci de respecter les règles de courtoisie.

P.S. de l'auteur

Pour l'illustration en tête de l'article, j'ai utilisé une image de l'article «What is a Service Mesh (and when to use one)?» (auteur : Gregory MacKinnon). Elle montre comment une partie des fonctionnalités des applications (en vert) a été transférée à la service mesh, assurant les interconnexions entre elles (en bleu).

Lisez aussi dans notre blog :

• «Service Mesh : ce que chaque Software Engineer doit savoir sur la technologie la plus tendance»;
• «Qu'est-ce qu'un service mesh et pourquoi ai-je besoin de lui [pour une application cloud avec des microservices] ?»;
• «Retour aux microservices avec Istio. Partie 1».

Source : habr.com