Service Mesh

Le tissu réseau L7 qui rend invisibles le mTLS, les retries et l'observabilité : une fois activé, le code applicatif ignore qu'il existe.

Problème

Un hub EDI moderne compte 40 services internes : parsers EDIFACT, parsers X12, validateurs PEPPOL, brokers AS2, AS4, archive, audit, ML scoring, signatures Factur-X. Si chaque service embarque ses bibliothèques mTLS, retries, observabilité, on multiplie les versions, on rate des rollouts coordonnés, et on ne sait pas qui parle à qui. À 40 services, la matrice n × n est ingérable. Combiner Sidecar/Ambassador manuellement par Pod fonctionne mais explose à 200 Pods.

Forces

• Le nombre de services explose. À partir de 20 services internes, la complexité de la matrice réseau dépasse l'humain.
• Les patterns réseau sont identiques partout. mTLS, retries, circuit breaker — pas spécifiques au service. À factoriser.
• Les politiques évoluent vite. Une nouvelle norme crypto, un nouveau header de tracing — pousser à 40 services en même temps est risqué.
• Le mesh a un coût. CPU/mémoire par Pod (Envoy ~50 Mo), latence ajoutée (~1 ms), complexité opérationnelle du control plane.

Solution

Déployer un service mesh — Istio, Linkerd, Consul Connect, AWS App Mesh, Kuma. Un control plane central distribue la configuration (politiques mTLS, routes, retry policies) via xDS API. Chaque Pod reçoit automatiquement (sidecar injection via mutating webhook) un proxy Envoy qui intercepte tout le trafic via iptables. Le code applicatif appelle http://parser-edifact:8080 sans TLS, sans retry, sans tracing : le mesh ajoute tout cela. Politiques : gérées en YAML ou CRD Kubernetes, versionnées en git.

┌─────────────────────────────────────────────────────────┐
│  Control plane (Istiod / Linkerd controller)            │
│  ◇ politique mTLS  ◇ retries  ◇ routes canary           │
└────────┬──────────┬─────────────┬────────────────┬──────┘
         │ xDS      │ xDS         │ xDS            │ xDS
         ▼          ▼             ▼                ▼
   Pod parser   Pod broker     Pod archive    Pod portail
   ┌─────────┐  ┌─────────┐    ┌─────────┐    ┌─────────┐
   │ app     │  │ app     │    │ app     │    │ app     │
   │ + Envoy │  │ + Envoy │    │ + Envoy │    │ + Envoy │
   └─────────┘  └─────────┘    └─────────┘    └─────────┘
         ◀── mTLS / retries / observabilité automatiques ──▶

Implémentation EDI

Cas concret : hub EDI Kubernetes avec Istio. Le service parser EDIFACT appelle http://validator-peppol:8080/check. Le mesh intercepte : vérifie la PeerAuthentication (mTLS strict obligatoire), applique la DestinationRule (timeout 5s, 3 retries sur 503, circuit breaker à 50% d'erreurs), propage les headers traceparent W3C, exporte les métriques RED (rate, errors, duration) vers Prometheus. Si on déploie une v2 du validator avec une nouvelle règle, une VirtualService envoie 5% du trafic en canary — sans modifier le service appelant. mTLS rotation des certificats SPIFFE : automatique toutes les 24h, sans redéploiement.

Anti-patterns

• Mesh par défaut sur un petit système. 5 services : la complexité opérationnelle du mesh dépasse les bénéfices. Sidecar manuel ou bibliothèque applicative suffit.
• Business logic dans les filtres Envoy. Tentation de mettre du routage métier (par partnerId) en filtre WASM : échappe à la gouvernance code, indébogable.
• Mesh comme excuse pour ne pas tester. Si l'app panic, le mesh ne va pas la faire fonctionner. Le code reste responsable de la correction métier.
• Multi-mesh non coordonné. Istio sur le cluster A, Linkerd sur le cluster B : bridge inter-mesh non trivial. Si multi-cluster, choisir un mesh.

Patterns liés

• Sidecar — brique de base : chaque Pod du mesh embarque un sidecar Envoy.
• Ambassador — l'ambassadeur généralisé à l'échelle cluster.
• Circuit Breaker — implémenté par le mesh nativement.
• Bulkhead — implémenté via connectionPool dans une DestinationRule.
• Retry + backoff — politique de retry configurée au mesh.

Sources

• Istio — What is Istio? Le mesh dominant. istio.io
• Linkerd — A service mesh for Kubernetes. Le mesh cherché plus léger (Rust, proxy linkerd2-proxy). linkerd.io
• CNCF — Service Mesh Interface (SMI). Tentative de standardisation des APIs mesh, finalement intégrée dans Gateway API. gateway-api.sigs.k8s.io
• Calabro F. — The Service Mesh: What Every Software Engineer Needs to Know, O'Reilly Report, 2022. oreilly.com — Service Mesh Report
• Envoy — Architecture overview. Le data plane de tous les meshes majeurs. envoyproxy.io