Envoy Proxy (Высокопроизводительный прокси для микросервисов)

Envoy Proxy появился как ответ на боль микросервисов: динамичная конфигурация, куча сервисов, трафик по разным протоколам, а ещё нужны метрики и нормальная наблюдаемость. Это L4/L7-прокси, который с самого начала проектировался под облака и распределённые системы, а не «сервер с парой сайтов».

Сейчас Envoy — почти дефолтный выбор в Service Mesh: его используют в качестве sidecar-прокси в Istio, Consul Connect, Kuma, AWS App Mesh и ещё куче решений. Отдельно его ставят и как edge-proxy / API-шлюз.

В Kubernetes Envoy чаще всего живёт как sidecar: каждый pod получает свой контейнер с Envoy, и он берёт на себя всё сетевое общение между сервисами. Приложение думает, что стучится на localhost, а дальше Envoy уже решает, куда и как это отправить, какую политику применить и какие метрики собрать.

Что умеет Envoy #

• Балансировка (L4/L7) — распределяет трафик между backend-сервисами, поддерживает разные алгоритмы типа round-robin, least-request, random;
• Health checks — активно проверяет, жив ли backend, прежде чем лить на него запросы;
• Service discovery — умеет брать информацию о сервисах из DNS, Kubernetes, Consul и через xDS API;
• Маршрутизация трафика — роуты по заголовкам, путям, SNI, версиям и вообще довольно гибкие правила;
• TLS / mTLS — может сам завершать TLS, работать с mTLS, управлять сертификатами через SDS;
• Rate limiting и retry — защищает backend от перегрузок, умеет умно ретраить запросы;
• Observability — отдаёт метрики (Prometheus, statsd), пишет логи, шлёт трейсы в Zipkin, Jaeger, Datadog и прочие системы;
• Динамическая конфигурация через xDS — меняет маршруты, кластеры и прочие настройки на лету без рестарта процесса.

Envoy в Kubernetes и внутри Service Mesh #

Если посмотреть на любой mainstream-меш, картина примерно такая:

• Envoy запускается как sidecar-контейнер рядом с приложением;
• приложение общается с ним по localhost, а наружу уже ходит Envoy;
• через него же крутится вся безопасность: mTLS, авторизация, политики;
• он снимает метрики/трейсы с каждого запроса и отправляет их в систему мониторинга.

Вся конфигурация при этом пролетает от control plane (тот же Istio) через xDS, так что руками YAML’ы Envoy трогать обычно не нужно — но понимать, что там под капотом, полезно.

Типичные сценарии использования #

• В Istio — Envoy выступает как универсальный прокси: через него гоняют маршрутизацию, политики, mTLS и весь трафик;
• В Consul Connect — может стоять sidecar’ом или отдельным прокси между сервисами;
• Как отдельный gateway — используется в роли API-шлюза или edge-proxy перед Kubernetes ingress или вообще без него;
• В гибридных архитектурах — склеивает в один mesh Kubernetes, виртуалки и внешние API.

Почему вокруг Envoy такой хайп #

• Производительность — C++ и событийная модель, заточенная под низкие задержки и высокий трафик;
• Архитектура — всё построено вокруг фильтров, есть поддержка WASM, можно довольно гибко расширять поведение;
• Динамичность — конфиг можно полностью крутить через xDS, без «reload и молиться»;
• Экосистема — проект под крылом CNCF, живёт в бою у крупных компаний (Lyft, Google, Stripe, eBay, Square, Airbnb и т.д.).

По сути, Envoy — это уже не просто «обратный прокси», а такой сетевой слой управления трафиком для современных распределённых систем. Он сидит между приложениями и реальным миром и позволяет рулить трафиком, не ковыряя код.

Пример: статическая конфигурация Envoy #

Файл envoy.yaml с простым сценарием проксирования HTTP на backend:

static_resources:
listeners:
- name: listener_http
address:
socket_address:
address: 0.0.0.0
port_value: 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
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { cluster: backend_service }
http_filters:
- name: envoy.filters.http.router
clusters:
- name: backend_service
connect_timeout: 0.25s
type: logical_dns
dns_lookup_family: V4_ONLY
load_assignment:
cluster_name: backend_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: backend.local
port_value: 80

Смысл такой: Envoy слушает 8080, всё, что приходит, глушит в кластер backend_service, а тот резолвится в backend.local:80. Никаких mesh’ей и control plane, просто «толстый» прокси.

Envoy с динамическим конфигом: xDS #

Когда Envoy живет в Service Mesh, его обычно никто не настраивает статикой. Он ходит к control plane по gRPC и тянет оттуда куски конфига через xDS-API:

Envoy периодически опрашивает control plane или получает стрим обновлений и на лету пересобирает свою внутреннюю конфигурацию. Процесс не рестартуется, соединения не рвутся.

Envoy vs NGINX, если смотреть как на L7-прокси / Ingress #

В итоге, если нужен простой, понятный ingress или классический API Gateway, NGINX всё ещё нормальный выбор. Если же важна динамика, тесная интеграция с mesh и обильная телеметрия, чаще смотрят в сторону Envoy.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Арендовать VPS