Service mesh : comprendre le réseau de services

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.

• 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

Glissez pour voir

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.

Pour reprendre une analogie réseau : le service mesh est au trafic inter-services ce que TCP/IP est au trafic réseau de base. TCP garantit que les octets arrivent d’un point A à un point B. Le service mesh garantit que les requêtes arrivent d’un service A à un service B, avec en plus du chiffrement, du load balancing intelligent et de la télémétrie.

Analogie concrète

Imaginez un réseau de routes dans une ville. Sans service mesh, chaque conducteur (service) doit connaître l’itinéraire, gérer les embouteillages et assurer sa propre sécurité. Avec un service mesh, chaque conducteur a un copilote dédié (le proxy sidecar) qui gère la navigation, les détours en cas de route coupée et les signalements — de façon transparente.

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, circuit breaking, retries avec backoff.
Résilience	Timeouts, retries automatiques, circuit breakers qui isolent un service défaillant pour éviter l’effet cascade.

Glissez pour voir

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), adopté par Istio, Cilium et d’autres. 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

Glissez pour voir

Pourquoi cette séparation ?

Séparer data plane et control plane permet de scaler indépendamment. Les proxies sont légers et distribués (un par pod), tandis que le control plane est centralisé. Cette architecture s’inspire de la séparation similaire dans les réseaux SDN (Software-Defined Networking) et dans Kubernetes lui-même (kubelet vs API Server).

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

1. Quand un pod est créé, le service mesh injecte automatiquement un conteneur proxy (sidecar) dans le pod
2. Des règles iptables redirigent tout le trafic réseau du pod vers le proxy
3. Le proxy intercepte chaque requête sortante — il applique mTLS, load balancing, collect les métriques
4. Le proxy intercepte chaque requête entrante — il vérifie le certificat, applique les politiques d’accès
5. 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)
• Cilium : utilise eBPF directement dans le noyau Linux pour intercepter le trafic, sans proxy séparé

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, pas de proxy userspace	Nécessite un noyau Linux récent, fonctionnalités L7 en développement

Glissez pour voir

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 :

1. Le proxy de A présente son certificat d’identité au proxy de B
2. Le proxy de B vérifie ce certificat et présente le sien en retour
3. A vérifie le certificat de B
4. Une connexion chiffrée est établie entre les deux proxies
5. 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.

Chiffrement inter-pods

Dans beaucoup de clusters Kubernetes, le trafic inter-pods n’est pas chiffré nativement de bout en bout au niveau applicatif. Un attaquant ayant accès au réseau du cluster peut alors intercepter les communications. Un service mesh permet d’ajouter du mTLS de manière centralisée et transparente, sans toucher au code.

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

Glissez pour voir

Principales implémentations

Trois projets dominent l’écosystème service mesh dans le monde Kubernetes. Les trois sont des projets CNCF.

Istio

Istio est le service mesh le plus répandu. Fondé en 2016 par Google, IBM et Lyft, c’est un projet CNCF graduated depuis 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).

Linkerd

Linkerd a été le premier service mesh (créé par Buoyant en 2016) et est un projet CNCF graduated. Sa philosophie est la simplicité : un micro-proxy Rust ultra-léger (linkerd2-proxy), une installation en quelques minutes, 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.

Cilium

Cilium est un projet CNCF graduated qui utilise eBPF pour le networking, la sécurité et l’observabilité dans le noyau Linux. Cilium réduit fortement la dépendance au modèle sidecar classique 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 les fonctionnalités L7 complètes, la réalité est plus nuancée que « pas de proxy du tout ».

Critère	Istio	Linkerd	Cilium
Proxy	Envoy	linkerd2-proxy (Rust)	Approche eBPF (modèle différent du sidecar classique)
Modèle	Sidecar + ambient	Sidecar	eBPF + proxies optionnels L7
Complexité	Élevée	Faible	Moyenne
Fonctionnalités L7	Très complètes	Essentielles	En développement
Statut CNCF	Graduated	Graduated	Graduated
Point fort	Écosystème riche, flexibilité	Simplicité, faible empreinte	Performance, intégration réseau

Glissez pour voir

Pour la KCNA

L’examen KCNA attend que vous compreniez le concept de service mesh (sidecar, data/control plane, mTLS) et que vous connaissiez l’existence des principales implémentations. Vous n’avez pas besoin de savoir configurer Istio ou Linkerd en détail — c’est du niveau CKA/CKS.

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

Commencer simple

Si vous débutez avec Kubernetes, ne déployez pas un service mesh immédiatement. Apprenez d’abord les Services Kubernetes natifs, le DNS interne et les NetworkPolicies. Le service mesh vient ensuite, quand la complexité de la communication inter-services le justifie. Le nombre de services est un indicateur utile, mais pas un seuil absolu — des exigences de compliance ou de traçabilité peuvent justifier un mesh même avec peu de services.

Ce qu'un service mesh ne remplace pas

• 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.

À 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

Prochaines étapes

Principes cloud native Les fondamentaux : microservices, immutabilité, déclaratif, observabilité.

Écosystème CNCF Comprendre la fondation, la gouvernance et les projets clés.

Networking Kubernetes Le modèle réseau de Kubernetes : pods, services, DNS, CNI.

Observabilité Kubernetes Métriques, logs et traces pour diagnostiquer vos clusters.

×

📖 Voir la documentation →