Envoy Proxy

Envoy Proxy — це високопродуктивний периферійний та сервісний проксі з відкритим вихідним кодом, розроблений для хмарних додатків, що діє як універсальна площина даних для мікросервісних архітектур. Він абстрагує мережеві складності, надаючи розширені можливості керування трафіком, спостережуваності та безпеки, необхідні для розподілених систем.

Envoy функціонує як прозорий проксі для всього мережевого трафіку між сервісами, дозволяючи розробникам та операторам зосереджуватися на логіці додатків, а не на мережевих проблемах. Його архітектура створена для сучасних розгортань мікросервісів, пропонуючи функції, яких традиційні проксі часто не мають або реалізують менш ефективно.

Основні архітектурні принципи

Дизайн Envoy пріоритезує продуктивність, розширюваність та динамічну конфігурацію. Він працює як однопроцесний, багатопотоковий сервер, використовуючи подієво-орієнтований ввід/вивід для ефективної обробки великого обсягу одночасних з'єднань та запитів.

Архітектура фільтрів L3/L4

Envoy використовує архітектуру ланцюжка фільтрів, що підключаються, як на мережевому (L3/L4), так і на прикладному (L7) рівнях. Це дозволяє високоналаштовувану обробку мережевого трафіку.
* Мережеві фільтри: Працюють з необробленими потоками байтів. Приклади включають TCP-проксі, термінацію TLS та обмеження швидкості на рівні з'єднання.
* HTTP-фільтри: Працюють з HTTP-запитами та відповідями. Приклади включають Gzip-стиснення, впровадження ідентифікатора запиту, JWT-автентифікацію та розширену маршрутизацію.

Ця модульність дозволяє застосовувати складні політики та маніпулювати трафіком на різних етапах життєвого циклу запиту.

Ключові функції для мікросервісів

Підтримка HTTP/2 та gRPC

Envoy забезпечує першокласну підтримку HTTP/2 та gRPC, основних протоколів у сучасних мікросервісах. Він може з'єднувати клієнтів HTTP/1.1 із сервісами HTTP/2, завершувати з'єднання HTTP/2 та полегшувати gRPC-проксіювання, включаючи розширені функції, такі як gRPC-орієнтоване балансування навантаження та маршрутизація.

Розширене балансування навантаження

Envoy пропонує набір складних алгоритмів балансування навантаження, що виходять за рамки простого циклічного:
* Найменша кількість запитів (Least Request): Маршрутизує до бекенду з найменшою кількістю активних запитів.
* Кільцевий хеш (Ring Hash): Послідовне хешування для кращого використання кешу та "липких" сесій.
* Maglev (Power of Two Choices): Вибирає двох випадкових хостів і вибирає той, що має менше активних запитів, балансуючи простоту з майже оптимальним розподілом.
* Випадковий (Random): Для простого, неупередженого розподілу.
* Оригінальне призначення (Original Destination): Маршрутизує до передбачуваної IP-адреси призначення без виявлення сервісу.

Він також підтримує автоматичні повторні спроби, розрив ланцюга, виявлення аномалій та перевірку стану, щоб гарантувати, що трафік надсилається лише до здорових екземплярів, покращуючи стійкість.

Динамічна конфігурація (xDS API)

Наріжним каменем хмарного дизайну Envoy є його можливості динамічної конфігурації через xDS (Discovery Service) API. Замість статичних файлів конфігурації, Envoy може динамічно отримувати оновлення для різних ресурсів:
* Listener Discovery Service (LDS): Слухачі (порти, до яких прив'язується Envoy).
* Route Discovery Service (RDS): Правила HTTP-маршрутизації.
* Cluster Discovery Service (CDS): Вихідні кластери (групи бекенд-сервісів).
* Endpoint Discovery Service (EDS): Кінцеві точки (окремі екземпляри) у кластерах.
* Secret Discovery Service (SDS): TLS-сертифікати та приватні ключі.
* Runtime Discovery Service (RTDS): Динамічні значення конфігурації часу виконання.

Це дозволяє змінювати конфігурацію без простоїв, забезпечуючи безперервне розгортання та інтеграцію з площинами керування сервісних сіток (наприклад, Istio, App Mesh), які керують цими конфігураціями.

Спостережуваність

Envoy розроблений з спостережуваністю як першокласним громадянином, надаючи глибокі відомості про мережевий трафік:
* Детальна статистика: Видає велику кількість статистики (понад 100 на вихідний кластер), що охоплює з'єднання, запити, помилки, затримки та багато іншого, які можуть бути зібрані Prometheus або подібними системами.
* Розподілене трасування: Підтримує популярні системи трасування, такі як Jaeger, Zipkin та AWS X-Ray, поширюючи контексти трасування (наприклад, B3, W3C Trace Context) та генеруючи проміжки для кожного стрибка.
* Журналювання доступу: Комплексні, настроювані журнали доступу, що деталізують кожен запит, включаючи заголовки, коди відповідей та інформацію про час.

Ці функції є вирішальними для налагодження, аналізу продуктивності та моніторингу розподілених мікросервісів.

Функції безпеки

Envoy надає надійні функції безпеки, часто знімаючи ці проблеми з коду програми:
* Термінація та ініціація TLS: Обробляє шифрування/дешифрування TLS, дозволяючи сервісам спілкуватися через звичайний текст внутрішньо, зберігаючи безпечний зовнішній зв'язок.
* Взаємний TLS (mTLS): Сприяє безпечному, автентифікованому зв'язку між сервісами в межах сітки шляхом перевірки клієнтських сертифікатів.
* Обмеження швидкості (Rate Limiting): Застосовує обмеження швидкості запитів для захисту сервісів від перевантаження або зловживань.
* Автентифікація та авторизація: Інтегрується із зовнішніми службами авторизації (наприклад, OPA) через свій фільтр External Authorization, забезпечуючи детальний контроль доступу.

Роль Envoy в архітектурах мікросервісів

Sidecar Proxy

Найпоширеніший шаблон розгортання Envoy у мікросервісному середовищі — це sidecar-проксі. У цій моделі кожен екземпляр сервісу запускає проксі Envoy поруч із собою, зазвичай у тому ж поді в Kubernetes. Весь вхідний та вихідний мережевий трафік для сервісу прозоро перехоплюється та керується sidecar.

Цей підхід пропонує кілька переваг:
* Абстракція мережі: Розробники додатків пишуть сервіси, які спілкуються з localhost, а sidecar Envoy обробляє маршрутизацію, повторні спроби та інші мережеві проблеми.
* Підтримка поліглотів: Забезпечує послідовні мережеві політики та функції для сервісів, написаних різними мовами та фреймворками.
* Ізоляція: Мережеві проблеми ізольовані від бізнес-логіки, що спрощує розробку та розгортання.

Площина даних сервісної сітки

Envoy служить де-факто площиною даних для багатьох популярних реалізацій сервісних сіток (наприклад, Istio, Linkerd, AWS App Mesh). У сервісній сітці площина керування керує та конфігурує парк проксі Envoy (площина даних). Площина керування використовує xDS API для динамічного оновлення конфігурації всіх Envoy у сітці, застосовуючи політики трафіку, безпеку та спостережуваність у всій екосистемі мікросервісів.

Периферійний проксі / API-шлюз

Envoy також може бути розгорнутий на краю мережі як API-шлюз або зворотний проксі. У цій ролі він обробляє вхідний трафік, виконує автентифікацію, обмеження швидкості, термінацію TLS та маршрутизує запити до відповідних бекенд-сервісів в архітектурі мікросервісів. Його розширені можливості маршрутизації L7 роблять його придатним для складних вимог периферійної маршрутизації.

Приклад конфігурації

Базова конфігурація Envoy визначає слухачів, ланцюжки фільтрів та кластери. Цей приклад показує слухача на порту 10000, який проксіює HTTP-запити до вихідного кластера сервісів під назвою web_service.

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 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
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: web_service
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: web_service
    connect_timeout: 0.25s
    type: LOGICAL_DNS
    # Comment out the following line to test on v6.
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: web_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: webserver.example.com # Replace with your actual service hostname/IP
                port_value: 80

Порівняння з іншими проксі

Практичні міркування

Налаштування продуктивності

Envoy є високопродуктивним "з коробки", але конкретні розгортання можуть виграти від налаштування. Ключові області включають:
* Конфігурація потоків: Налаштування кількості робочих потоків відповідно до ядер ЦП.
* Керування буферами: Оптимізація розмірів буферів читання/запису.
* Розмір пулу з'єднань: Налаштування максимальної кількості з'єднань та запитів на з'єднання до вихідних кластерів.

Споживання ресурсів

Хоча Envoy ефективний, запуск sidecar Envoy для кожного екземпляра сервісу збільшує загальне споживання ресурсів (ЦП, пам'ять). Цей компроміс часто є прийнятним для операційних переваг, які надає сервісна сітка. Ретельний моніторинг використання ресурсів є критично важливим у великих розгортаннях.

Налагодження

Envoy надає адміністративний інтерфейс (зазвичай на порту 15000), який пропонує цінні кінцеві точки для налагодження:
* /stats: Поточна статистика.
* /config_dump: Вивантажує поточну активну конфігурацію.
* /clusters: Статус вихідних кластерів.
* /hot_restart: Ініціює плавний "гарячий" перезапуск.

Ці кінцеві точки є інструментальними для усунення проблем з конфігурацією, моніторингу стану та розуміння потоку трафіку.