Diagramme d'architecture service mesh : data plane, control plane et mTLS

Dès qu'un système compte des dizaines de services, le même code réseau apparaît dans chacun d'eux : retries, timeouts, TLS entre services, métriques par appel, répartition du trafic pour les mises en production. Un service mesh sort ce code des services et le place dans le chemin réseau, où une seule équipe peut le configurer pour tout le monde.

Cet article explique comment un mesh est construit, ce que font respectivement le control plane et le data plane, comment fonctionne le mTLS automatique, et les coûts qui font d'un mesh le mauvais choix pour beaucoup d'équipes. Le diagramme montre l'architecture sidecar classique.

Data plane et control plane

Le data plane est un ensemble de proxys placés sur le chemin de chaque requête entre services. Dans le modèle sidecar, chaque pod reçoit son propre conteneur proxy. L'application parle en HTTP simple à son proxy local ; le proxy gère tout ce qui passe sur le réseau : chiffrement, retries, load balancing, métriques. Istio utilise Envoy comme sidecar ; Linkerd utilise son propre proxy, conçu pour cet usage et écrit en Rust.

Le control plane ne touche jamais au trafic des requêtes. Il surveille les services et les endpoints du cluster, transforme vos politiques en configuration de proxy, pousse cette configuration vers chaque proxy et émet les certificats avec lesquels les proxys s'identifient. Dans Istio, c'est istiod ; voir la page d'architecture d'Istio. La référence d'architecture de Linkerd décrit les éléments équivalents.

mTLS automatique et identité des workloads

Le TLS mutuel entre chaque paire de services est la fonctionnalité qui convainc la plupart des équipes. Chaque proxy reçoit du control plane un certificat de courte durée qui nomme le workload, en général sous la forme d'un ID SPIFFE dérivé du namespace et du service account Kubernetes, comme spiffe://cluster.local/ns/shop/sa/orders. Quand deux proxys se connectent, tous deux présentent leur certificat, tous deux le vérifient, et la connexion est chiffrée.

Deux conséquences comptent :

• L'identité remplace l'emplacement réseau. Une politique peut dire « payments n'accepte que les appels du service account orders », ce qui est plus fort que « depuis ce sous-réseau ».
• La rotation est automatique. Les certificats vivent quelques heures, et personne n'ouvre de ticket pour les renouveler.

Activez le mode strict une fois que tout est dans le mesh, pour que les connexions en clair soient refusées au lieu d'être acceptées en silence.

Une requête à travers le mesh

Suivez un appel d'orders vers payments :

1. L'application orders envoie une requête HTTP simple au nom du service payments. La redirection du trafic l'envoie au sidecar local au lieu du réseau.
2. Le sidecar d'orders cherche des endpoints payments sains dans la configuration poussée par le control plane, en choisit un avec son algorithme de load balancing et applique le timeout de cette route.
3. Il ouvre, ou réutilise, une connexion mTLS vers le sidecar de payments, en présentant le certificat d'orders.
4. Le sidecar de payments vérifie le certificat, contrôle la politique d'autorisation (orders a-t-il le droit d'appeler payments ?) et transmet la requête à l'application payments via localhost.
5. Les deux sidecars enregistrent la requête, son statut et sa latence. Si l'appel échoue avec un statut réessayable, le sidecar d'orders peut réessayer dans la limite de son budget.

Aucune des deux applications ne sait que tout cela s'est produit : c'est tout l'intérêt, et aussi le risque. Un comportement invisible dans le code doit être visible ailleurs, par exemple sur le diagramme.

Déployer un mesh

Adoptez-le par étapes. Installez le control plane, ajoutez les services un namespace à la fois en mode permissif pour que le trafic en clair fonctionne encore, surveillez les métriques, puis passez chaque namespace en mTLS strict. Ajoutez les politiques d'autorisation en dernier, en commençant par les services qui détiennent des données sensibles.

Politiques de trafic

Comme chaque appel passe par un proxy, le mesh peut appliquer les mêmes règles partout :

• Timeouts et retries, avec des budgets pour que les retries ne se multiplient pas pendant une panne.
• Circuit breaking et détection des valeurs aberrantes : cesser d'envoyer du trafic aux instances qui échouent sans cesse.
• Répartition du trafic par poids ou par en-tête : c'est ainsi que les déploiements canary sont implémentés dans un mesh.
• Injection de fautes pour les tests : ajouter des délais ou des erreurs à un pourcentage des appels.

Attention aux retries à deux endroits. Si l'application réessaie et que le sidecar réessaie aussi, un appel en échec en devient plusieurs. Choisissez un seul responsable des retries, et écrivez-le.

L'observabilité (presque) gratuite

Les proxys remontent le nombre de requêtes, les taux d'erreur et la latence par source et par destination, sans modifier les applications. Ils peuvent aussi démarrer et propager des spans de trace, mais l'application doit toujours transmettre les en-têtes de trace des requêtes entrantes vers les requêtes sortantes, sinon les traces se cassent à chaque service.

Sidecars ou mode ambient

Les sidecars ont des coûts réels : un proxy dans chaque pod consomme du CPU et de la mémoire, ajoute de la latence à chaque saut et complique le démarrage des pods et les mises à jour. Le mode ambient d'Istio supprime le sidecar par pod. Un proxy par nœud appelé ztunnel gère le mTLS et les politiques de couche 4, et des proxys waypoint optionnels gèrent les fonctions de couche 7 seulement pour les services qui en ont besoin. La contrepartie : un modèle d'exploitation différent et moins d'années d'historique en production que les sidecars.

Le diagramme d'architecture

Comment le lire :

• À gauche : l'ingress gateway reçoit le trafic externe et ouvre une connexion mTLS vers le sidecar du pod orders.
• Au milieu : dans chaque pod, le sidecar transmet à l'application via localhost. Le sidecar d'orders appelle en mTLS les sidecars de payments et d'inventory ; les applications ne manipulent jamais de certificats.
• En bas : le control plane pousse configuration et certificats vers les proxys (arêtes en tirets). Il n'est pas sur le chemin des requêtes.
• À droite : les sidecars remontent métriques et traces (en pointillés). Le bloc Markdown montre une politique pour payments : qui peut l'appeler, timeouts et retries, éjection des valeurs aberrantes et mTLS strict.

Quand ne pas utiliser de mesh

• Une poignée de services, ou un monolithe avec quelques satellites. Une bibliothèque ou une API gateway couvre les besoins pour une fraction du coût.
• Aucune équipe pour le prendre en charge. Un mesh est une infrastructure qui demande des mises à jour, des compétences de débogage et des connaissances d'astreinte.
• Quand le but principal est uniquement le chiffrement. Beaucoup de clouds et de plugins CNI savent chiffrer le trafic entre pods sans mesh complet.

Ce qu'il faut mettre sur un diagramme de mesh

• Les deux plans, clairement séparés, avec le control plane hors du chemin des requêtes.
• Où le TLS commence et se termine : de proxy à proxy, et HTTP simple sur localhost.
• Les identités, au moins pour les services soumis à des politiques d'accès.
• Les politiques qui changent le comportement : timeouts, retries, circuit breaking.

Le diagramme d'architecture Kubernetes montre le cluster dans lequel tourne le mesh, le diagramme d'architecture zero trust explique pourquoi les politiques fondées sur l'identité comptent, et le diagramme d'architecture microservices couvre les services eux-mêmes.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Conteneur du pack Modèle C4 pour l'ingress gateway.
3. Pour chaque pod, ajoutez un Cadre du pack Base avec, à l'intérieur, un Composant pour le sidecar et un Conteneur pour l'application.
4. Ajoutez un Conteneur pour le control plane et des Métriques du pack DevOps.
5. Tracez des arêtes mTLS entre les sidecars, des arêtes en tirets depuis le control plane et des arêtes de télémétrie en pointillés, puis ajoutez un bloc Markdown du pack Base avec la politique d'un service.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre un service mesh et une API gateway ? Une API gateway gère le trafic qui entre dans le système depuis l'extérieur. Un service mesh gère le trafic entre les services à l'intérieur. Beaucoup de systèmes utilisent les deux.

Un service mesh ajoute-t-il de la latence ? Oui, chaque saut par un proxy en ajoute un peu, en général bien moins de quelques millisecondes par saut, plus le CPU et la mémoire des proxys. Mesurez-le pour votre trafic.

Dois-je modifier le code de mon application pour un mesh ? En général non. L'exception est le tracing : les applications doivent transmettre les en-têtes de trace pour que les traces se relient d'un service à l'autre.

Qu'est-ce que le mode ambient ? Un data plane Istio sans sidecars : un proxy par nœud gère le mTLS et la couche 4, et des proxys waypoint optionnels gèrent les fonctions de couche 7 là où c'est nécessaire.

Qui doit être responsable du mesh ? Une équipe plateforme. Les équipes de services utilisent ses fonctionnalités via des politiques, mais quelqu'un doit le mettre à jour, le surveiller et le déboguer.

Commencez gratuitement — un siège, sans carte bancaire.