Что такое Envoy

высокопроизводительный прокси-сервер с открытым исходным кодом, созданный для работы в облачных и микросервисных архитектурах. Изначально разработан в Lyft, сейчас развивается как проект CNCF.

Envoy написан на C++ и работает на уровнях L3/L4/L7. Его часто запускают как sidecar-контейнер рядом с каждым сервисом в Kubernetes — приложение думает, что обращается к localhost, а дальше Envoy сам решает, куда отправить запрос, какую политику применить и какие метрики собрать. Так строится Service Mesh: Envoy становится единым data plane для всей сети сервисов.

Помимо sidecar-режима, Envoy используют как edge-прокси (входная точка для внешнего трафика) и как основу для API-шлюзов.

Возможности Envoy

• Балансировка нагрузки. Распределяет трафик между backend-сервисами, поддерживает round-robin, least-request и другие алгоритмы.
• Service discovery. Получает информацию о доступных сервисах через DNS, Kubernetes, Consul или xDS API.
• Health checks. Проверяет, жив ли backend, перед тем как направить на него запрос.
• Маршрутизация трафика. Роутит по заголовкам, путям, SNI и другим гибким правилам.
• TLS и mTLS. Может завершать TLS-соединение (TLS termination) и работать с mTLS — взаимной аутентификацией, при которой сертификат предъявляют обе стороны соединения, а не только сервер.
• Rate limiting, retry policy и circuit breaking. Ограничивает нагрузку, повторяет запросы при сбоях и размыкает соединение с бэкендом, если тот постоянно отдает ошибки — это защищает остальную систему от каскадных отказов.
• Observability. Экспортирует метрики (Prometheus, statsd), поддерживает трассировку (Jaeger, Zipkin) и логирование.

Динамическая конфигурация через xDS

Отдельная сильная сторона Envoy — xDS API (discovery services). Это набор gRPC/REST-протоколов, через которые Envoy получает конфигурацию от внешнего control plane: маршруты, кластеры, слушатели, сертификаты. Обновление происходит на лету, без перезапуска процесса и без разрыва соединений.

У xDS есть несколько подвидов под конкретные типы ресурсов: LDS отвечает за слушатели, RDS — за маршруты, CDS — за кластеры, EDS — за адреса бэкендов, SDS — за сертификаты для mTLS. Именно на xDS построены Istio и другие service mesh поверх Envoy: control plane переводит высокоуровневые правила в конфигурацию Envoy и раздает ее по всем прокси в кластере.

Расширение через WebAssembly

Envoy поддерживает фильтры на WebAssembly (Wasm) — это позволяет писать собственную логику обработки трафика на разных языках (Rust, C++, Go) и подключать ее без пересборки самого Envoy. Приём востребован там, где встроенных фильтров не хватает — например, для кастомной авторизации или трансформации запросов.

Envoy Gateway

Envoy Gateway — отдельный проект, построенный поверх Envoy Proxy. Он реализует Kubernetes Gateway API — современную замену стандартного Ingress. Пользователь описывает Gateway и маршруты через стандартные Kubernetes-ресурсы, а Envoy Gateway сам переводит их в конфигурацию для Envoy и раздает через xDS. По сути, это управляемая обертка над Envoy: она снимает часть сложности ручной настройки и добавляет готовую поддержку TLS, аутентификации и политик трафика.

Envoy в сравнении с NGINX

Envoy часто сравнивают с NGINX, так как оба решают задачи прокси и балансировки:

• Изначально проектировался под динамическую конфигурацию через xDS, тогда как NGINX традиционно ближе к статическим конфигурационным файлам.
• Дает более подробную встроенную observability — метрики и трассировку из коробки.
• Требует больше времени на освоение конфигурации, которая генерируется из proto-файлов и менее интуитивна для новичка.

Лицензия и ограничения

Envoy распространяется под лицензией Apache 2.0. Проект поддерживается сообществом и CNCF, а не одной компанией — это касается и самого Envoy, и Envoy Gateway.