Le modèle de configuration d’Envoy ne change pas selon l’endroit où vous le déployez, mais cet endroit change le problème qu’il résout. Ce guide présente les modèles de déploiement courants et explique pourquoi une propriété d’Envoy, être assez peu coûteux pour tourner à raison d’une instance par application, est ce qui rend possible le plus intéressant d’entre eux.

Proxy edge : la porte d’entrée de votre réseau

Déployé en périphérie, Envoy se place entre le monde extérieur et vos services internes : il accepte le trafic entrant des clients externes et, dans l’autre sens, gère le trafic sortant que vos propres services envoient vers l’extérieur. C’est la position classique d’API gateway ou de répartiteur de charge : une instance d’Envoy (ou un petit ensemble redondant) qui assure la terminaison TLS, le routage et la limitation de débit pour tout ce qui traverse la frontière du réseau, dans un sens comme dans l’autre.

Front proxy : un répartiteur de charge interne partagé

Un modèle interne plus simple : un seul Envoy (ou un petit cluster d’Envoy) auquel chaque service interne envoie ses requêtes, et qui les distribue ensuite au bon backend. Cela ressemble à un répartiteur de charge interne classique, et fonctionnellement c’en est un, simplement implémenté avec le routage et le health checking d’Envoy plutôt qu’avec une appliance de répartition dédiée.

Sidecar : un Envoy par instance de service

C’est le modèle qui distingue Envoy de la plupart des autres proxys : plutôt qu’une instance partagée traitant le trafic de nombreux services, une instance d’Envoy s’exécute aux côtés de chaque instance de chaque service, en termes Kubernetes, comme second conteneur dans le même Pod. Le trafic entrant et sortant de chaque service passe par sa propre instance de proxy dédiée plutôt que par une instance partagée.

Deux choses découlent directement de cette proximité :

• L’application n’a plus besoin de connaître le réseau. Les retries, les timeouts, le TLS et la logique de répartition de charge sortent du code applicatif pour passer dans le proxy situé juste à côté, ce qui est exactement la séparation des préoccupations que la conception d’Envoy visait.
• Le dépannage devient plus rapide. Quand Envoy est un composant partagé ailleurs sur le réseau, un problème peut se trouver dans l’application, dans le proxy ou dans le chemin réseau qui les sépare. Quand Envoy tourne juste à côté de l’unique instance applicative qu’il dessert, cette ambiguïté disparaît en grande partie : si le sidecar signale une connexion saine vers l’application mais que la requête échoue quand même, l’espace de recherche vient de se réduire considérablement.

Faire tourner un Envoy par instance n’est possible que parce qu’Envoy est volontairement léger ; un proxy à l’empreinte lourde par instance ne pourrait pas être déployé à cette densité sans devenir le coût en ressources d’une seconde exécution de l’application.

Service mesh : des sidecars coordonnés

Un service mesh est le modèle sidecar appliqué de façon cohérente à toute une application : chaque instance de service reçoit son propre Envoy, et tous ces proxys sont configurés et observés comme un seul système coordonné plutôt que comme des instances indépendantes gérées individuellement. C’est là que les fonctionnalités de gestion du trafic d’Envoy (retries, circuit breaking, TLS mutuel, routage fin) s’appliquent uniformément à chaque service du mesh, sans que le code d’aucun service n’ait à les implémenter.

Configurer à la main des centaines d’instances d’Envoy n’est pas envisageable, ce qui explique pourquoi les service meshes existent comme couche à part entière au-dessus d’Envoy plutôt que d’être « simplement Envoy, déployé en grand nombre ». Istio en est l’exemple le plus connu : son plan de données est précisément Envoy, avec le propre plan de contrôle d’Istio, istiod, qui génère et pousse automatiquement la configuration de chaque sidecar à mesure que les services et les politiques changent. Si vous faites un kubectl exec dans un Pod où Istio a injecté un sidecar et que vous regardez ses logs, ce qui tourne réellement est un vrai processus Envoy, configuré par Istio plutôt qu’à la main.

Les modèles mixtes sont normaux

Les topologies de production combinent généralement plusieurs de ces modèles : Envoy en périphérie pour gérer l’entrée et la sortie de tout le cluster, et des sidecars Envoy pour le trafic de service à service à l’intérieur. Rien dans Envoy n’impose un modèle unique ; choisir l’un d’eux, ou une combinaison, dépend du type de contrôle dont chaque trafic a besoin, et non d’une limitation du proxy lui-même.