Service mesh : comprendre le réseau de services

30 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Un service mesh est une couche d'infrastructure dédiée à la communication entre services. Il intercepte tout le trafic réseau entre vos microservices grâce à des proxies, sans modifier le code applicatif. Résultat : vous obtenez du chiffrement mutuel (mTLS), de l'observabilité fine et du routage avancé de façon transparente. Ce guide vous explique les concepts fondamentaux, data plane, control plane, sidecar, et vous aide à comprendre quand un service mesh est utile et quand il ne l'est pas.

Ce que vous allez apprendre

Le service mesh fait partie des concepts cloud native utiles à connaître pour comprendre l'écosystème Kubernetes et préparer la KCNA. Ce guide reste conceptuel, vous n'avez pas besoin d'installer quoi que ce soit : la leçon pratique qui le suit, Imposer délais, reprises et autorisations entre services, applique ces règles avec Istio.

Ce qu'est un service mesh et quel problème concret il résout
L'architecture data plane / control plane
Le rôle du proxy sidecar (et les alternatives sans sidecar)
Les fonctionnalités clés : mTLS, observabilité, traffic management
Les principales implémentations : Istio, Linkerd, Cilium
Quand un service mesh est pertinent, et quand il ne l'est pas

Le problème : la communication entre microservices

Dans une application monolithique, les composants communiquent en mémoire, pas de réseau à gérer. Quand on passe aux microservices, chaque fonctionnalité devient un service indépendant qui communique avec les autres via le réseau. Une requête utilisateur peut traverser 5, 10 ou 20 services avant de produire une réponse.

Ce changement crée des défis concrets :

Défi	Conséquence sans service mesh
Pannes réseau	Un service lent bloque toute la chaîne (effet cascade)
Sécurité	Le trafic entre services circule en clair dans le cluster
Observabilité	Impossible de savoir quel service cause la latence
Routage	Pas de canary deployment ni de traffic splitting natif
Retry / timeout	Chaque équipe implémente sa propre logique dans le code

Sans service mesh, chaque équipe de développement doit gérer ces problèmes dans le code applicatif, service par service, langage par langage. C'est exactement ce que faisaient Netflix (Hystrix) et Twitter (Finagle) dans les années 2010, avec des bibliothèques spécifiques à chaque langage.

Le service mesh déplace cette complexité hors du code applicatif vers une couche d'infrastructure partagée.

Qu'est-ce qu'un service mesh ?

Un service mesh est une couche d'infrastructure dédiée qui rend la communication entre services fiable, sécurisée et observable, sans que l'application ait besoin d'en être consciente.

Le service mesh se situe une couche au-dessus de TCP/IP. TCP garantit que des octets arrivent d'un point A à un point B, sans rien connaître de leur sens. Le service mesh garantit que des requêtes arrivent d'un service A à un service B, et parce qu'il comprend le protocole applicatif, il peut y ajouter le chiffrement mutuel, une répartition de charge tenant compte des latences, des reprises sur erreur et de la télémétrie par appel.

Ce que fait un service mesh

Un service mesh fournit quatre grandes familles de fonctionnalités :

Fonctionnalité	Ce que ça fait concrètement
Sécurité (mTLS)	Chiffre tout le trafic entre services + vérifie l'identité de chaque service via des certificats. Zéro configuration dans le code.
Observabilité	Génère automatiquement des métriques (latence, taux d'erreur, débit), des traces distribuées et des logs pour chaque requête inter-services.
Traffic management	Routage avancé : canary deployments, A/B testing, traffic splitting.
Résilience	Timeouts, retries automatiques, circuit breakers qui isolent un service défaillant pour éviter l'effet cascade.

Architecture : data plane et control plane

Un service mesh se compose de deux couches distinctes :

Data plane (plan de données)

Le data plane est constitué de l'ensemble des proxies déployés à côté de chaque instance de service. Chaque proxy intercepte tout le trafic entrant et sortant de son service. C'est le data plane qui applique concrètement les règles : chiffrement mTLS, retries, load balancing, collecte de métriques.

Le proxy le plus utilisé est Envoy (projet CNCF graduated), qui sert de data plane à Istio et que Cilium mobilise pour ses fonctions L7. Linkerd utilise son propre micro-proxy écrit en Rust (linkerd2-proxy), optimisé pour une faible empreinte.

Control plane (plan de contrôle)

Le control plane est le cerveau du service mesh. Il configure les proxies du data plane : quelle politique de sécurité appliquer, comment router le trafic, quels certificats distribuer. L'opérateur interagit avec le control plane (via des CRD Kubernetes ou des API), et celui-ci propage la configuration à tous les proxies.

Composant	Rôle	Qui interagit avec
Data plane (proxies)	Intercepte le trafic, applique les règles, collecte les métriques	Le trafic réseau passe à travers
Control plane	Configure les proxies, distribue les certificats, définit les politiques	L'opérateur / administrateur

Le schéma suivant montre les deux plans côte à côte : la requête de A vers B passe par les deux proxies et traverse le réseau en mTLS, tandis que le control plane ne voit jamais le trafic et se contente de pousser la configuration aux proxies.

Source · SVG

Le proxy sidecar : le mécanisme central

Le modèle historique du service mesh repose sur le pattern sidecar : un conteneur proxy est injecté automatiquement dans chaque pod Kubernetes, à côté du conteneur applicatif.

Comment ça fonctionne

Quand un pod est créé, le service mesh injecte automatiquement un conteneur proxy (sidecar) dans le pod
Des règles iptables redirigent tout le trafic réseau du pod vers le proxy
Le proxy intercepte chaque requête sortante, il applique mTLS, load balancing, collecte les métriques
Le proxy intercepte chaque requête entrante, il vérifie le certificat, applique les politiques d'accès
L'application ne voit rien : elle envoie ses requêtes normalement sur localhost ou vers le service Kubernetes

Le résultat est que chaque paire de services communique via leurs proxies respectifs, formant un maillage (mesh) de connexions sécurisées.

L'alternative : le mode ambient (sans sidecar)

Le modèle sidecar ajoute un conteneur par pod, ce qui consomme de la mémoire et du CPU. Des approches récentes proposent des alternatives :

Istio ambient mode : remplace les sidecars par un proxy partagé au niveau du nœud (ztunnel) pour le chiffrement L4, avec des waypoint proxies optionnels pour les fonctionnalités L7 (routage, observabilité avancée). Ce mode est déclaré stable (GA) depuis Istio 1.24, publié en novembre 2024
Cilium : traite le trafic L3/L4 avec eBPF directement dans le noyau Linux, sans sidecar. Pour le L7 (routage HTTP, politiques applicatives), il s'appuie sur un proxy Envoy exécuté une fois par nœud, pas une fois par pod

Approche	Avantage	Inconvénient
Sidecar (classique)	Isolation forte, fonctionnalités L7 complètes	Consommation mémoire/CPU par pod
Ambient / node-level	Moins de ressources, déploiement simplifié	Moins d'isolation, fonctionnalités L7 optionnelles
eBPF (Cilium)	Très performant en L3/L4, pas de sidecar par pod	Nécessite un noyau Linux récent, le L7 passe par un Envoy par nœud

mTLS : le chiffrement mutuel automatique

L'une des fonctionnalités les plus recherchées d'un service mesh est le mutual TLS (mTLS). Dans un chiffrement TLS classique (HTTPS), seul le serveur prouve son identité au client. Avec mTLS, les deux parties présentent un certificat et vérifient mutuellement leur identité.

Concrètement, quand le service A appelle le service B :

Le proxy de A présente son certificat d'identité au proxy de B
Le proxy de B vérifie ce certificat et présente le sien en retour
A vérifie le certificat de B
Une connexion chiffrée est établie entre les deux proxies
Les données circulent chiffrées, même à l'intérieur du cluster

Le service mesh gère toute la mécanique : émission des certificats, rotation automatique, vérification. L'application n'a aucune modification à faire. Pour chiffrer le trafic entre Pods avec Istio ou Cilium sur un vrai cluster, le guide mTLS pod-to-pod détaille les deux voies.

Observabilité : métriques, traces et logs automatiques

Le service mesh génère de la télémétrie pour chaque requête qui traverse le data plane, sans instrumentation dans le code applicatif :

Métriques : latence (P50, P95, P99), taux de succès/erreur, débit (requêtes par seconde), par service et par route
Traces distribuées : propagation automatique des headers de traçage pour visualiser le chemin complet d'une requête à travers les services
Logs d'accès : journaux structurés de chaque requête (source, destination, code de réponse, durée)

Ces données s'intègrent avec les outils d'observabilité standards : Prometheus pour les métriques, Jaeger ou Zipkin pour les traces, Grafana pour la visualisation.

Pour un débutant, le principal bénéfice est de pouvoir répondre à la question : « quel service cause la lenteur ? » sans ajouter une seule ligne de code.

Traffic management : routage avancé

Le service mesh permet de contrôler finement comment le trafic circule entre les services :

Fonctionnalité	Description	Cas d'usage
Canary deployment	Envoyer 5% du trafic vers une nouvelle version, 95% vers l'ancienne	Déploiement progressif sans risque
A/B testing	Router selon des headers HTTP (user-agent, cookie)	Tester une fonctionnalité sur un segment d'utilisateurs
Traffic splitting	Répartir le trafic entre N versions d'un service	Blue-green, migrations progressives
Circuit breaking	Couper le trafic vers un service qui répond trop lentement	Éviter l'effet cascade
Retries avec backoff	Réessayer automatiquement les requêtes échouées	Tolérance aux pannes transitoires
Rate limiting	Limiter le nombre de requêtes par seconde vers un service	Protection contre la surcharge

Principales implémentations

Trois projets comptent parmi les plus cités dans l'écosystème service mesh du monde Kubernetes. Les trois sont des projets CNCF graduated.

Istio

Istio est le service mesh le plus répandu. Annoncé en 2017 par Google, IBM et Lyft (version 1.0 en juillet 2018), c'est un projet CNCF graduated depuis juillet 2023. Il utilise Envoy comme proxy et offre l'ensemble de fonctionnalités le plus complet : mTLS, traffic management avancé, politiques d'accès, observabilité profonde. Istio propose deux modes de déploiement : sidecar classique et ambient mode (sans sidecar, stable depuis Istio 1.24).

Linkerd

Linkerd, créé par Buoyant en 2016, est un projet CNCF graduated depuis juillet 2021 : le premier service mesh à avoir atteint ce niveau. Sa philosophie est la simplicité : un micro-proxy Rust ultra-léger (linkerd2-proxy), une installation rapide, et un focus sur les fonctionnalités essentielles (mTLS, métriques, retries). Linkerd est souvent choisi quand on veut un service mesh sans la complexité d'Istio.

Point de vigilance sur les versions : depuis Linkerd 2.15 (février 2024), le projet open source ne publie plus d'artefacts de version stable, seulement des versions edge diffusées en continu. Les versions stables sont désormais fournies par des éditeurs, par exemple Buoyant Enterprise for Linkerd. Vérifiez la page des versions du projet avant de choisir comment l'installer.

Cilium

Cilium est un projet CNCF graduated depuis octobre 2023 qui utilise eBPF pour le networking, la sécurité et l'observabilité dans le noyau Linux. Cilium supprime le sidecar grâce à eBPF, avec une approche orientée performance et intégration réseau. Il combine les fonctions de CNI (réseau) et de service mesh dans un seul outil. Pour le L7 (routage HTTP, politiques applicatives), il reste pourtant un proxy : Envoy, exécuté une fois par nœud (dans le pod de l'agent Cilium par défaut, ou dans un DaemonSet cilium-envoy dédié), pas dans chaque pod.

Critère	Istio	Linkerd	Cilium
Proxy	Envoy	linkerd2-proxy (Rust)	eBPF (L3/L4) + Envoy par nœud (L7)
Modèle	Sidecar + ambient	Sidecar	eBPF + Envoy par nœud, sans sidecar
Complexité	Élevée	Faible	Moyenne
Fonctionnalités L7	Très complètes	Essentielles	Via Envoy (un par nœud)
Statut CNCF	Graduated	Graduated	Graduated
Point fort	Écosystème riche, flexibilité	Simplicité, faible empreinte	Performance, intégration réseau

Quand utiliser un service mesh, et quand s'en passer

Un service mesh n'est pas toujours nécessaire. Voici un guide de décision :

Un service mesh est pertinent quand

La communication inter-services, la sécurité et l'observabilité deviennent difficiles à gérer uniformément
Vous avez besoin de chiffrement mTLS dans le cluster sans modifier les applications
Vous voulez de l'observabilité inter-services automatique
Vous pratiquez les déploiements progressifs (canary, A/B testing)
Plusieurs équipes développent des services dans des langages différents

Un service mesh est probablement excessif quand

Vous avez peu de services et peu de contraintes de sécurité/observabilité, la complexité ajoutée ne se justifie pas
Votre application est un monolithe ou un monolithe modulaire
Vous n'avez pas d'exigence de chiffrement intra-cluster
Votre équipe est petite et n'a pas la bande passante pour gérer un composant d'infrastructure supplémentaire

Ce qu'un service mesh ne remplace pas, en quatre points :

Il ne remplace pas les Services Kubernetes (ClusterIP, LoadBalancer), il se greffe dessus.
Il ne remplace pas les NetworkPolicies, le mesh gère l'identité applicative (L7), les NetworkPolicies filtrent au niveau réseau (L3/L4).
Il ne remplace pas une bonne instrumentation applicative, les traces distribuées sont plus riches quand l'application propage correctement les headers.
Il ne supprime pas la complexité, il la déplace et la centralise.

Le service mesh s'inscrit dans un ensemble plus large. Il prolonge les principes cloud native, dont le couplage faible et l'observabilité, et ses projets s'évaluent avec l'écosystème CNCF. Pour comprendre ce sur quoi il se greffe, le modèle réseau de Kubernetes (pods, services, DNS, CNI) est le préalable, et l'observabilité Kubernetes montre comment exploiter les métriques, logs et traces qu'il produit.

À retenir

Un service mesh est une couche d'infrastructure qui gère la communication entre microservices de façon transparente, via des proxies
L'architecture repose sur deux plans : le data plane (proxies qui interceptent le trafic) et le control plane (qui configure les proxies)
Le modèle sidecar injecte un proxy dans chaque pod ; les approches ambient et eBPF réduisent cette empreinte
Le mTLS chiffre et authentifie mutuellement tout le trafic entre services, sans modifier le code applicatif
L'observabilité automatique (métriques, traces, logs) permet de diagnostiquer les problèmes sans instrumentation
Les principales implémentations CNCF sont Istio (complet), Linkerd (simple) et Cilium (performant, eBPF)
Le service mesh devient pertinent quand la communication inter-services, la sécurité et l'observabilité deviennent difficiles à gérer uniformément, le nombre de services est un indicateur, pas un seuil absolu

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin