> For the complete documentation index, see [llms.txt](https://utm-1.gitbook.io/utm-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://utm-1.gitbook.io/utm-docs/dokumentaciya/utm-it/resheniya/organizaciya-dostupov/spravochnaya-informaciya/envoy.md). # Envoy ## Общие данные Envoy — это высокопроизводительный прокси-сервер с открытым исходным кодом, разработанный для микросервисной архитектуры и облачных приложений. Он управляет сетевыми взаимодействиями между микросервисами, обеспечивая маршрутизацию, балансировку нагрузки, безопасность, мониторинг и трассировку запросов. Envoy часто используется как компонент Service Mesh, где он работает в качестве sidecar-прокси рядом с каждым приложением. ### Основные возможности Envoy * **Маршрутизация запросов**. Гибкая настройка правил маршрутизации по различным параметрам: загруженность, версия сервиса, тип данных и др. Например, можно разделить трафик между старой и новой версиями сервиса. * **Балансировка нагрузки**. Распределение трафика между экземплярами сервисов с поддержкой различных стратегий (round-robin, least-request, random). * **Безопасность**. Поддержка mTLS, TLS termination, шифрование данных при передаче между сервисами. * **Мониторинг и трассировка**. Экспорт метрик (Prometheus, StatsD), интеграция с системами трассировки (Jaeger, Zipkin, Datadog) и логирование. * **Динамическая конфигурация**. Управление конфигурацией в реальном времени через xDS API без перезапуска сервиса. * **Расширяемость**. Модульная архитектура, поддержка фильтров и плагинов, включая WebAssembly. * **Поддержка современных протоколов**. HTTP/2, gRPC, WebSocket, TCP. ### Развёртывание и настройка в Kubernetes В Kubernetes Envoy чаще всего применяется в рамках Service Mesh, где он работает как sidecar-контейнер рядом с каждым приложением. Для настройки требуется: 1. **Создать ConfigMap с конфигурацией Envoy**. Например, указать listeners, clusters, route\_config и другие параметры в файле YAML. 2. **Развернуть Envoy как отдельный pod**. В спецификации pod нужно указать образ Envoy и настроить порты. 3. **Настроить правила маршрутизации и балансировки нагрузки**. Это можно сделать через конфигурационные файлы или с помощью инструментов управления Service Mesh (например, Istio). 4. **Интегрировать с системой обнаружения сервисов**. Envoy поддерживает интеграцию с Kubernetes API, DNS, Consul и другими системами. Пример простой конфигурации Envoy: ```yaml yamlstatic_resources: listeners: - name: listener_0 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 route_config: name: local_route virtual_hosts: - name: backend domains: ["*"] routes: - match: { prefix: "/" } route: { cluster: backend_service } clusters: - name: backend_service connect_timeout: 0.25s type: STRICT_DNS hosts: - socket_address: address: backend-service port_value: 80 ``` ### Использование в других приложениях Envoy можно применять не только в Kubernetes, но и в других сценариях: * **API Gateway**. Envoy может служить единой точкой входа для внешних клиентов, обрабатывая маршрутизацию, аутентификацию, ограничение скорости и перевод протоколов. * **Канареечные развёртывания и A/B тестирование**. С помощью Envoy можно разделять трафик между разными версиями сервисов для безопасного тестирования обновлений. * **Интеграция с другими инструментами**. Envoy поддерживает расширение через фильтры и плагины, что позволяет интегрировать его с системами мониторинга, логирования и управления доступом. * **Работа с gRPC**. Envoy может проксировать gRPC-трафик, обеспечивая балансировку нагрузки и другие возможности. ### Примеры использования * **Istio**. Envoy используется как универсальный прокси с централизованным управлением маршрутизацией и политиками. * **Consul Connect**. Envoy может работать как sidecar или standalone-посредник между сервисами. * **Standalone Gateway**. Используется как API-шлюз или edge-proxy перед Kubernetes ingress. * **Гибридные архитектуры**. Envoy способен объединять Kubernetes, виртуальные машины и внешние API в единую mesh-структуру. Envoy — мощный инструмент для управления трафиком в распределённых системах. Его гибкость, производительность и широкая поддержка делают его популярным выбором для современных облачных приложений. Однако для эффективного использования требуется понимание его архитектуры и возможностей настройки. ## API Gateway через Envoy ### Настройка Envoy как API Gateway с OAuth и JWT Envoy может выступать в роли API Gateway с поддержкой OAuth‑авторизации и работы с JWT‑токенами. Ниже — пошаговая инструкция. #### 1. Архитектура решения Базовая схема: * **Envoy** — точка входа, проверяет JWT, маршрутизирует запросы; * **OAuth‑провайдер** (Keycloak, Auth0, Google, Okta) — выдаёт и валидирует токены; * **Backend‑сервисы** — принимают запросы с валидными JWT. #### 2. Подготовка конфигурации Envoy Создайте файл `envoy.yaml` с базовой структурой: yaml ```yaml static_resources: listeners: - name: listener_0 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.jwt_authn typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication providers: oauth_provider: issuer: "https://your-oauth-provider.com" audiences: - "your-audience" remote_jwks: http_uri: uri: "https://your-oauth-provider.com/.well-known/jwks.json" cluster: jwks_cluster timeout: 1s forward_payload_header: "x-jwt-payload" rules: - match: { prefix: "/secure" } requires: { provider_name: "oauth_provider" } - name: envoy.filters.http.router typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router clusters: - name: backend_service connect_timeout: 0.25s type: STRICT_DNS lb_policy: ROUND_ROBIN hosts: - socket_address: address: backend-service port_value: 8080 - name: jwks_cluster connect_timeout: 1s type: LOGICAL_DNS dns_lookup_family: V4_ONLY lb_policy: ROUND_ROBIN load_assignment: cluster_name: jwks_cluster endpoints: - lb_endpoints: - endpoint: address: socket_address: address: your-oauth-provider.com port_value: 443 transport_socket: name: envoy.transport_sockets.tls typed_config: "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext common_tls_context: validation_context: trusted_ca: filename: /etc/ssl/certs/ca-certificates.crt ``` #### 3. Ключевые компоненты конфигурации **Фильтр `jwt_authn`** * **issuer** — URL OAuth‑провайдера (например, `https://keycloak.example.com`); * **audiences** — список допустимых `aud` в JWT; * **remote\_jwks** — URL для загрузки публичных ключей (JWKS); * **forward\_payload\_header** — заголовок для передачи payload JWT в бэкенд. **Правила доступа (`rules`)** * **`match`** — URL‑паттерн, требующий аутентификации; * **`requires`** — провайдер JWT для проверки. **Кластер `jwks_cluster`** * Нужен для загрузки JWKS‑ключа с OAuth‑провайдера; * Использует TLS для безопасного соединения. #### 4. Развёртывание в Kubernetes 1. Создайте ConfigMap с `envoy.yaml`: bash ```bash kubectl create configmap envoy-config --from-file=envoy.yaml ``` 2. Разверните Envoy как Deployment: yaml ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: envoy-gateway spec: replicas: 2 selector: matchLabels: app: envoy-gateway template: metadata: labels: app: envoy-gateway spec: containers: - name: envoy image: envoyproxy/envoy:v1.30-latest ports: - containerPort: 8080 volumeMounts: - name: config mountPath: /etc/envoy volumes: - name: config configMap: name: envoy-config ``` 3. Создайте Service для доступа: yaml ```yaml apiVersion: v1 kind: Service metadata: name: envoy-gateway spec: selector: app: envoy-gateway ports: - protocol: TCP port: 80 targetPort: 8080 type: LoadBalancer ``` #### 5. Настройка OAuth‑провайдера 1. Зарегистрируйте приложение в OAuth‑провайдере (например, Keycloak): * Укажите **Redirect URI** (например, `http://your-gateway.com/callback`); * Получите **Client ID** и **Client Secret**. 2. Настройте области (scopes), например: * `openid` * `profile` * `email` 3. Убедитесь, что провайдер выдаёт JWT с нужными полями (`iss`, `aud`, `sub`). #### 6. Тестирование 1. Получите JWT от OAuth‑провайдера: bash ```bash curl -X POST https://your-oauth-provider.com/token \ -d "grant_type=client_credentials" \ -d "client_id=your-client-id" \ -d "client_secret=your-client-secret" \ -d "scope=openid" ``` 2. Отправьте запрос через Envoy: bash ```bash curl -H "Authorization: Bearer " http://your-gateway.com/secure/data ``` Если JWT валиден, запрос пройдёт к бэкенду. Иначе — получите `401 Unauthorized`. #### 7. Дополнительные настройки * **Кэширование JWKS**. Добавьте `cache_duration` в `remote_jwks` для снижения нагрузки. * **Пользовательские заголовки**. Используйте `from_headers` для извлечения claims из JWT. * **Логирование**. Включите `access_log` для отслеживания запросов. * **Ограничение скорости**. Добавьте фильтр `rate_limit` для защиты от DDoS. #### 8. Возможные проблемы и решения * **Ошибка TLS при загрузке JWKS**. Проверьте `trusted_ca` и доступность провайдера. * **401 без объяснения**. Включите debug‑логи Envoy (`--log-level debug`). * **Задержки при проверке JWT**. Настройте `cache_duration` (например, `300s`). #### Итог Вы настроили: * Envoy как API Gateway; * Проверку JWT от OAuth‑провайдера; * Маршрутизацию запросов к бэкендам. Для production‑использования добавьте: * Мониторинг (Prometheus/Grafana); * TLS для клиентских соединений; * Резервирование и автомасштабирование.