Envoy Proxy : le proxy cloud-native de référence en 2026

Depuis la montée en puissance de Kubernetes et des architectures microservices, les besoins en matière de proxy réseau ont radicalement changé. Les entreprises ne cherchent plus seulement un reverse proxy statique : elles ont besoin d'une solution capable de s'adapter dynamiquement, de gérer les métriques réseau en temps réel, et de supporter les service meshes modernes.

C'est ce que fait Envoy Proxy, le projet CNCF Graduated créé par Lyft et adopté par 54 % des entreprises utilisant le cloud-native (selon les stats CNCF 2025). Google l'utilise comme sidecar dans Istio, AWS l'intègre dans App Mesh, et Docker le supporte nativement.

On détaille ici l'architecture d'Envoy, son modèle de configuration dynamique, et comment l'utiliser en production.

1. Architecture d'Envoy : L4/L7, listeners, clusters et routes
2. L'API xDS : la configuration dynamique
3. Comparaison avec Nginx et HAProxy
4. Cas d'usage concrets
5. Déployer Envoy avec Docker
6. Sources et perspectives

Envoy fonctionne selon une architecture event-driven et filter-based. Contrairement à Nginx qui repose sur des workers synchrones, Envoy utilise un modèle asynchrone non-bloquant hérité des pratiques de Lyft.

Les éléments clés :

• Listeners : points d'entrée réseau (ports, protocoles)
• Routes : règles de routage basées sur le hostname, le path, ou les headers
• Clusters : ensembles de backends (instances de service)
• Filters : pipeline de traitement (compression, authentication, logging)
• xDS API : contrôle-plan pour la configuration dynamique

Exemple de configuration simple

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_number: 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
                stat_prefix: ingress_http
                http_filters:
                  - name: envoy.filters.http.router
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ['example.com']
                      routes:
                        - match:
                            prefix: '/api'
                          route:
                            cluster: api_backend
  clusters:
    - name: api_backend
      connect_timeout: 5s
      type: STRICT_DNS
      load_assignment:
        cluster_name: api_backend
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: api.example.com
                      port_number: 8080

L'apport majeur d'Envoy tient à son API xDS (x Discovery Service). Elle met à jour la configuration en temps réel sans redémarrer le processus Envoy.

Les 4 principaux services xDS :

Cette approche est centrale dans les service meshes : quand une instance Kubernetes se crée ou se termine, le control-plane envoie immédiatement les nouveaux endpoints à Envoy via EDS.

{
	"version_info": "0",
	"resources": [
		{
			"@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
			"name": "api_backend",
			"connect_timeout": "5s",
			"type": "EDS",
			"eds_cluster_config": {
				"eds_config": {
					"resource_api_version": "V3",
					"api_config_source": {
						"api_type": "GRPC",
						"grpc_services": [
							{
								"envoy_grpc": {
									"cluster_name": "xds_cluster"
								}
							}
						]
					}
				}
			}
		}
	]
}

Verdict : Envoy domine clairement dans les architectures Kubernetes modernes. Nginx reste imbattable pour les serveurs web statiques. HAProxy brille dans les contextes legacy avec la meilleure performance brute en L4.

1. Sidecar dans un service mesh (Istio)

Envoy est le sidecar proxy par défaut dans Istio. Il intercepte tout le trafic applicatif, applique les politiques de sécurité (mTLS), et collecte les métriques.

# Istio injecte automatiquement un sidecar Envoy
kubectl apply -f deployment.yaml
# → Istio mutating webhook ajoute un conteneur envoy
# → Configuration via xDS depuis le control-plane Istio

2. API Gateway

Envoy peut servir de gateway d'entrée pour router le trafic vers plusieurs services :

virtual_hosts:
  - name: api_gateway
    domains: ['api.example.com']
    routes:
      - match: { prefix: '/users' }
        route: { cluster: users_service }
      - match: { prefix: '/orders' }
        route: { cluster: orders_service }
      - match: { prefix: '/payments' }
        route: { cluster: payments_service }

3. Edge proxy

Léger et reconfigurable à chaud, Envoy tient le rôle d'edge proxy près des utilisateurs, ce qui réduit la latence.

Configuration Envoy minimale

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_number: 8080
      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
                stat_prefix: ingress_http
                http_filters:
                  - name: envoy.filters.http.router
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: backend
                      domains: ['*']
                      routes:
                        - match: { prefix: '/' }
                          route: { cluster: web_backend }
  clusters:
    - name: web_backend
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
      connect_timeout: 5s
      load_assignment:
        cluster_name: web_backend
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: backend
                      port_number: 3000
admin:
  address:
    socket_address:
      address: 127.0.0.1
      port_number: 9901

Docker Compose

version: '3.8'
services:
  envoy:
    image: envoyproxy/envoy:v1.29-latest
    ports:
      - '8080:8080'
      - '9901:9901'
    volumes:
      - ./envoy.yaml:/etc/envoy/envoy.yaml:ro
    command: /usr/local/bin/envoy -c /etc/envoy/envoy.yaml

  backend:
    image: nginx:latest
    ports:
      - '3000:80'

Lancer :

docker-compose up -d
curl http://localhost:8080

Pour aller plus loin avec Envoy :

• Istio et le canary deployment : gérer les déploiements progressifs avec Envoy
• Traefik v2 : routing dynamique : alternative légère pour Kubernetes
• Consul Service Mesh : approche HashiCorp de la maille de services

• CNCF Projects : Envoy, Statut Graduated (2018)
• Blog Envoy Proxy, Envoy graduates : CNCF Graduated project
• Envoy Documentation, Configuration complète et API xDS
• Istio & Envoy, Service mesh utilisant Envoy comme sidecar
• AWS App Mesh, Service mesh managé, utilise Envoy

Envoy Proxy est devenu le standard de fait des architectures cloud-native en 2025-2026. Son modèle de configuration dynamique (xDS), son architecture event-driven et son intégration native aux service meshes en font le choix de référence pour les entreprises modernes.

Que vous construisiez une infrastructure Kubernetes qui passe à l'échelle, un API gateway ou un service mesh sécurisé, Envoy donne une base déjà éprouvée en production. Son adoption par Google, AWS et Microsoft et sa gouvernance CNCF assurent sa pérennité.

Côté modernisation infrastructure, Envoy ouvre la voie à des systèmes plus observables et plus résilients, ce que cherchent les organisations qui misent sur le cloud-native pour rester dans la course.