Gateway et service mesh

La gateway et le service mesh routent tous deux du trafic, appliquent des policies et produisent de la télémétrie. Ils ne traitent pas le même axe : la gateway gère le trafic entrant, entre domaines de confiance différents. Le mesh gère le trafic entre services d’un même domaine. Les opposer est une erreur de cadrage, la vraie question est de savoir si le second vaut son coût.

Consommateurs externes

Partenaires, public

Gateway

Frontière : authentification, quotas, contrats

Maillage interne

Service A

mTLS, identité, télémétrie

Service B

mTLS, identité, télémétrie

Le partage des rôles

Le mesh donne à chaque connexion interne une identité de service, du chiffrement mutuel et des policies de reprise, sans modifier le code des applications. Il ne sait rien des contrats ni des consommateurs : il ne remplace pas la plateforme d’API, il équipe le réseau qu’elle ne voit pas.

Ce que le sidecarless a changé

Le coût historique du mesh était le sidecar : un proxy par conteneur, de la mémoire et de la latence partout. Un second modèle s’est imposé à côté, sans le remplacer : un agent par nœud qui porte l’identité et le chiffrement au niveau du transport, et des proxys de niveau applicatif déployés seulement là où le routage fin est nécessaire.

Istio le propose en disponibilité générale depuis la 1.24 sous le nom de mode ambient, en annonçant explicitement que les sidecars restent pleinement supportés. Linkerd, l’autre maillage diplômé de la CNCF, conserve le modèle à sidecar. Il n’existe donc pas de modèle dominant, il existe un choix de plus.

Le gain est réel et se mesure chez vous plutôt que dans un billet : le même projet cite un retour utilisateur à 45 % de conteneurs en moins et des économies au-delà de 90 % sur certains cas d’usage, ce qui est un écart trop large pour être un argument. Le vrai changement est ailleurs : l’adoption cesse d’être un tout ou rien. Identité et chiffrement partout d’abord, routage avancé ensuite, sur les seuls périmètres qui en ont besoin.

Une précision qui évite une déception. L’agent par nœud travaille au niveau du transport et ne lit pas le HTTP : tout ce qui relève de l’en-tête, de la route ou du code de retour demande un proxy applicatif en plus, déployé par espace de noms plutôt que par service.

Dans le même mouvement, la Gateway API de Kubernetes est devenue le langage commun : les mêmes ressources de routage décrivent l’entrée du cluster et, par l’initiative GAMMA, le trafic entre services. Configurer l’entrée et l’intérieur avec le même vocabulaire réduit l’écart de compétence entre les deux mondes, et c’est devenu un critère de choix d’outillage.

Quand le mesh ne vaut pas son coût

Le mesh reste une pièce d’infrastructure, avec ses montées de version et ses modes de panne propres. Trois situations où s’en passer est le bon choix :

• peu de services, une équipe : le besoin réel est du mTLS, qui s’obtient plus simplement.
• pas de plateforme Kubernetes tenue : le mesh suppose une équipe plateforme constituée.
• le réseau porte déjà l’essentiel : les couches réseau modernes chiffrent le trafic entre nœuds et produisent une télémétrie de base sans couche supplémentaire. La réserve est qu’il s’agit d’un chiffrement de transport, pas d’une identité de charge de travail par connexion applicative, et que la couverture s’établit après la découverte d’un correspondant, pas avant.

L’inverse vaut aussi : au-delà de quelques dizaines de services, réimplémenter reprise, délais et chiffrement dans chaque application coûte plus cher que le mesh qui les mutualise.

Ce qui ne va dans aucun des deux

La logique métier, dans les deux cas, pour la raison développée dans médiation. Et l’autorisation fine : le mesh authentifie des services, la gateway authentifie des applications. Savoir si tel utilisateur peut voir tel dossier reste dans le code du service, voir accès.