Envoy
| Fiche express | |
|---|---|
| Type | Proxy L4/L7 — brique bas niveau, pas un produit autonome |
| Origine | Lyft, projet CNCF gradué |
| API de configuration | xDS (Discovery Service) |
| Utilisé par | Istio · Contour · Emissary-Ambassador · Envoy Gateway · Gloo |
| Voir aussi | Istio · Ingress et Gateway API · Service mesh et mTLS |
Envoy est un proxy L4/L7 haute performance écrit en C++, créé chez Lyft et open-sourcé en 2016, aujourd'hui projet CNCF gradué (à vérifier pour la date exacte). Il est rarement utilisé « nu » par l'utilisateur final : c'est la brique bas niveau qui sert de data plane à Istio et de moteur à de nombreux Ingress controllers et API gateways. Cette page couvre Envoy en tant que tel ; pour l'usage en mesh, voir Istio et Service mesh et mTLS.
Pourquoi Envoy
Contrairement à un proxy classique reconfiguré par rechargement de fichier, Envoy a été conçu dès le départ pour être piloté dynamiquement par une API :
- Filtres composables — chaînes de filtres réseau (L4) et HTTP (L7) assemblables (TLS, routage, retries, rate limiting, autorisation externe...).
- Observabilité native — statistiques, journaux d'accès, traçage distribué intégrés sans code applicatif.
- Robustesse en production — circuit breaking, outlier detection, health checking actif des upstreams.
xDS : configuration dynamique
LxDS API (x Discovery Service) est l'ensemble des protocoles par lesquels un control plane pousse sa configuration à Envoy, sans redémarrage :
| API | Rôle |
|---|---|
| LDS (Listener) | Ports d'écoute, chaînes de filtres |
| RDS (Route) | Règles de routage HTTP |
| CDS (Cluster) | Groupes d'upstreams (services backend) |
| EDS (Endpoint) | Adresses IP concrètes des upstreams |
| SDS (Secret) | Certificats et clés TLS |
<mermaid> flowchart LR
CP[Control plane
ex. istiod, Contour, Gloo] -->|xDS: LDS/RDS/CDS/EDS/SDS| E[Envoy] C[Client] --> E E --> U1[Upstream A] E --> U2[Upstream B]
</mermaid>
C'est cette API qui fait la valeur d'Envoy pour des projets tiers : plutôt que réinventer un proxy, ils écrivent un control plane qui parle xDS et laissent Envoy exécuter le trafic.
Où on le retrouve
| Contexte | Rôle d'Envoy |
|---|---|
| Istio | Data plane : sidecar par Pod, ou ztunnel/waypoint en mode ambient |
| Ingress controllers (Contour, Emissary-Ambassador) | Moteur de proxy derrière les objets Ingress |
| Envoy Gateway | Implémentation de la Gateway API directement au-dessus d'Envoy |
| API gateways (Gloo Edge, etc.) | Moteur de proxy derrière les fonctions API gateway (auth, transformation, rate limiting) |
Positionnement : une brique, pas un produit
Un Envoy seul, sans control plane, nécessite une configuration statique (fichier de bootstrap) qu'il faut maintenir à la main — viable pour un cas simple, pas pour un parc de services qui change en continu. C'est pourquoi, en pratique, l'utilisateur final interagit rarement avec Envoy directement : il configure la couche au-dessus (VirtualService Istio, HTTPRoute Gateway API, HTTPProxy Contour...) et c'est le control plane concerné qui traduit vers xDS.
Exemple minimal de structure d'un fichier de bootstrap statique (à but illustratif — en production, cette configuration est presque toujours générée par un control plane plutôt qu'écrite à la main) :
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 10000 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
route_config:
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { cluster: service_backend }
clusters:
- name: service_backend
type: STRICT_DNS
load_assignment:
cluster_name: service_backend
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address: { address: backend.svc, port_value: 8080 }
Observabilité
- Interface admin (port 9901 par défaut) — état des clusters, statistiques en temps réel, hot restart.
- Statistiques — export Prometheus natif (latences, codes de retour, ouverture de circuit breaker...).
- Traçage distribué — intégration Zipkin, Jaeger, OpenTelemetry (nécessite la propagation des en-têtes de bout en bout par les applications).
- Journaux d'accès — format configurable, utile pour l'audit du trafic est-ouest ou nord-sud.