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 exactement ce qu'offre 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.

Cet article explore 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 inspiré par les meilleures 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'innovation majeure d'Envoy est son API xDS (x Discovery Service). Elle permet de mettre à 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

Envoy est léger et configuré dynamiquement, donc idéal pour un edge proxy près des utilisateurs, réduisant 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 scalable, un API gateway performant, ou un service mesh sécurisé, Envoy offre une fondation solide et éprouvée. Son adoption par les géants du cloud (Google, AWS, Microsoft) et sa gouvernance CNCF garantissent sa pérennité.

Dans un contexte de modernisation infrastructure, Envoy représente l'évolution naturelle vers des systèmes plus observables, plus résilients, et plus agiles, exactement ce que demandent les organisations qui investissent dans le cloud-native pour rester compétitives.