Envoy est un proxy haute performance et extensible conçu pour les applications cloud-native. Il opère à la fois aux couches 3/4 et 7, et gère la répartition de charge, la découverte de services, les retries, le circuit breaking et l’observabilité du trafic qui le traverse. C’est le proxy de plan de données sous-jacent à la plupart des service meshes et API gateways modernes.

Comment ça marche

Envoy est typiquement déployé comme sidecar aux côtés de chaque instance applicative, ou comme proxy edge autonome. Il est configuré dynamiquement par un ensemble d’API de découverte (collectivement « xDS ») : un plan de contrôle pousse la configuration des listeners, des routes, des clusters et des endpoints, et Envoy l’applique sans redémarrer. Cette séparation entre un plan de données rapide et généraliste et un plan de contrôle modulable est ce qui permet à des outils comme Istio de construire un service mesh complet au-dessus d’Envoy.

Concepts clés

• Listener : un emplacement réseau nommé (une IP et un port) sur lequel Envoy accepte des connexions.
• Route : une configuration qui fait correspondre les requêtes entrantes et décide quel cluster upstream les traite.
• Cluster : un groupe d’endpoints upstream sur lesquels Envoy peut répartir le trafic, avec les paramètres de health checking et de pool de connexions associés.
• API xDS : la famille de protocoles de découverte (LDS, RDS, CDS, EDS et d’autres) qu’un plan de contrôle utilise pour pousser dynamiquement la configuration vers Envoy.

Pourquoi les équipes adoptent Envoy

• Riches fonctionnalités de couche 7. Prise en charge native de HTTP/2, gRPC, des retries, des timeouts, du circuit breaking et du partage fin de trafic.
• Observabilité approfondie. Métriques détaillées, journalisation et traçage distribué sont intégrés, et non greffés après coup.
• Configuration dynamique. Les changements de routage et d’endpoints s’appliquent sans redémarrer ni interrompre les connexions.
• Le socle commun. Il sous-tend Istio, plusieurs API gateways et de nombreux ingress controllers managés, si bien que les compétences se transposent d’un outil à l’autre.

Pour commencer

Envoy est rarement exécuté seul dans un contexte Kubernetes : la plupart des équipes le rencontrent comme proxy sidecar dans un service mesh comme Istio, ou comme moteur derrière un ingress controller ou une API gateway. Les guides ci-dessous couvrent la configuration d’Envoy dans ces contextes courants.