À quoi sert un service mesh
Un service mesh est une couche d'infrastructure qui prend en charge la communication réseau entre services dans un cluster Kubernetes. Dans une architecture microservices, chaque service appelle plusieurs autres services, et chaque appel doit gérer : authentification, chiffrement, retry en cas d'échec, timeout, tracing distribué, métriques de latence. Sans service mesh, chaque équipe produit duplique ce code dans chaque service, dans chaque langage utilisé.
Un service mesh externalise ces préoccupations dans des proxies sidecar (typiquement Envoy) déployés à côté de chaque pod. Le code applicatif fait des appels HTTP simples vers localhost ; le sidecar intercepte, applique la politique de sécurité, le routing, le retry, et émet les métriques. Les développeurs se concentrent sur la logique métier, l'équipe plateforme gère le réseau de services.
Les fonctionnalités principales
Sécurité de service à service. Le mTLS (mutual TLS) chiffre automatiquement tout le trafic entre pods et authentifie les services. C'est un prérequis pour les environnements multi-tenants, le secteur régulé (finance, santé) et les architectures zero-trust. Sans service mesh, mettre en place mTLS service à service demande des semaines d'effort par service.
Routing avancé. Canary releases, A/B testing, déploiements blue-green, traffic shadowing pour tester une nouvelle version sur du trafic réel sans impact utilisateur. Tout configurable via des CRD Kubernetes, sans toucher au code applicatif.
Résilience. Retry automatique sur erreur transitoire, circuit breaker quand un service amont est dégradé, rate limiting par appelant. Ces patterns deviennent déclaratifs au lieu d'être codés dans chaque service.
Observabilité automatique. Métriques RED (Rate, Errors, Duration) pour chaque communication service à service, tracing distribué sans instrumentation côté code, logs structurés des appels. La cartographie du graphe des services s'affiche en temps réel.
Les principaux service meshes
Istio (CNCF Graduated 2023). Le plus complet et le plus déployé. Forte courbe d'apprentissage : 50+ CRD, configuration verbeuse. Adapté aux organisations matures avec 30+ ingénieurs plateforme.
Linkerd (CNCF Graduated 2021). Le plus simple. Architecture minimaliste, proxy custom (pas Envoy) écrit en Rust, footprint mémoire réduit. Adapté aux équipes de taille moyenne qui veulent du mTLS sans surcoût opérationnel.
Cilium Service Mesh (CNCF Graduated 2023). Approche alternative basée sur eBPF qui supprime le sidecar Envoy. Performances accrues, mais fonctionnalités L7 encore en rattrapage par rapport à Istio.
Quand ne pas adopter un service mesh
Un service mesh ajoute une charge opérationnelle significative : déploiement, mise à jour, debug des sidecars, formation de l'équipe. Pour une architecture inférieure à 10 services, ce coût dépasse les bénéfices. Préférer une approche plus simple : Ingress + cert-manager pour le TLS edge, instrumentation OpenTelemetry pour le tracing, retry au niveau applicatif avec une bibliothèque comme Resilience4j ou Polly.
Le seuil pratique observé chez nos clients Hidora : adopter un service mesh à partir de 15 à 20 microservices ou dès qu'une exigence mTLS interne est explicite (FINMA, secteur santé).
Services Hidora associés
- Consulting : audit de pertinence service mesh, choix entre Istio, Linkerd et Cilium, conception de la stratégie de déploiement progressif.
- Managed Services : exploitation 24/7 des service meshes en production avec monitoring des sidecars et des politiques.
- Kubernetes, Cilium, Observabilité : briques techniques associées.