Envoy для самых маленьких

Всем привет!

Я работаю бэкенд-разработчиком в компании Tinkoff, где участвую в разработке платформы CRM-системы для обслуживания физических и юридических лиц.

Использование edge proxy и балансировщика в частности — это почти мастхэв при построении современных систем. Сегодня на рынке представлено большое количество разнообразных решений, у каждого из которых есть преимущества и недостатки. Мы остановимся на одном из самых свежих — Envoy.

Envoy — это высокопроизводительный балансировщик, реализованный на C++. Его разработала компания Lyft — сервис заказа такси в Штатах, прямой конкурент Uber — для использования как с отдельными сервисами, так и в качестве связующего звена в сложных микросервисных системах. В том числе для реализации относительно свежего архитектурного явления — service mesh.

Формируя основной фундамент нашей платформы, он реализует cors, access-control, rate limiting, outlier detection, проверку jwt и многое другое.

На Хабре есть отличная статья, которая разбирает его основные отличия от ближайших соседей и проливает свет на внутреннее устройство. Мы же сфокусируемся больше на прикладных моментах, разберемся с запуском и настройкой, попробуем сразу несколько видов балансировки трафика. Поехали!

Для начала нам понадобится upstream-сервис-заглушка, обрабатывающий http-запросы и позволяющий в ответе идентифицировать каждый свой инстанс. Вы можете реализовать этот функционал сами либо, как и я, использовать доступный echo-server на Go. Удобнее всего развернуть несколько инстансов сразу в docker, назначив каждому свой порт. Я поднял три инстанса: на 8081, 8082, 8083 портах, запрос на каждый из которых в том числе возвращает container id.

Например, запрос:

curl -v localhost:8081

Возвращает:

Request served by a29f0fba3451  HTTP/1.1 GET /  Host: localhost:8081 User-Agent: curl/7.64.1 Accept: */*

Где a29f0fba3451 — идентификатор контейнера.

Теперь перейдем непосредственно к настройке Envoy. Он распространяется так же, как docker — образ с уже готовым примером конфигурации.

admin:   access_log_path: /tmp/admin_access.log   address:     socket_address: { address: 127.0.0.1, port_value: 9901 }  static_resources:   listeners:   - name: listener_0     address:       socket_address: { address: 0.0.0.0, port_value: 10000 }     filter_chains:     - filters:       - name: envoy.http_connection_manager         config:           stat_prefix: ingress_http           route_config:             name: local_route             virtual_hosts:             - name: local_service               domains: ["*"]               routes:               - match: { prefix: "/" }                 route: { host_rewrite: www.google.com, cluster: service_google }           http_filters:           - name: envoy.router   clusters:   - name: service_google     connect_timeout: 0.25s     type: LOGICAL_DNS     # Comment out the following line to test on v6 networks     dns_lookup_family: V4_ONLY     lb_policy: ROUND_ROBIN     hosts: [{ socket_address: { address: google.com, port_value: 443 }}]     tls_context: { sni: www.google.com }

Здесь несколько основных моментов:

1. Порт, на котором запускается listener.
2. Virtual host по имени домена.
3. Конфигурация фильтров. Главная точка расширения для нас — настройка routes, обработка входных и выходных запросов.
4. Cluster — логически объединенные upstream-инстансы с параметрами балансировщика.
5. Endpoint — непосредственно upstream-инстанс с адресом и метаданными.

Я выделил основные сущности, настраиваемые с помощью сервисов LDS, VHDS, RDS, CDS и EDS соответственно.

Стоит добавить, что кроме статической конфигурации из yaml-файла существует и динамическая. В этом случае нам необходимо реализовать control-plane-сервис и API для передачи конфигурации envoy по gRPС-протоколу. В репозитории Envoy есть уже готовые реализации на Go и Java. Динамический подход будет крайне полезен в случае сложной конфигурации вашей системы и необходимости реагировать на ее изменения в рантайме.

Вернемся к конфигу и адаптируем под наши нужды.

Для начала добавим новый кластер echo_cluster и настроим список действующих эндпоинтов (апстрим-сервисов), заполнив поле load_assignment.endpoints адресами наших инстансов echo-server.

clusters:     - name: echo_cluster       connect_timeout: 3s       type: STRICT_DNS       dns_lookup_family: V4_ONLY       load_assignment:         cluster_name: echo_cluster         endpoints:         - lb_endpoints:           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8081           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8082           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8083

Осталось настроить только матчинг входящих запросов. Для этого в фильтре envoy.http_connection_manager необходимо задекларировать роуты наших апстрим-сервисов. Согласно официальной документации, есть несколько способов сделать это. Например, можно отправлять все запросы с префиксом "/echo" на соответствующий кластер.

    - filters:       - name: envoy.http_connection_manager           typed_config:             "@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager             stat_prefix: echo             codec_type: AUTO             route_config:               name: local_route               virtual_hosts:               - name: local_service                 domains: ["*"]                 routes:                 - match: { prefix: "/echo" }                   route: { cluster: echo_cluster }             http_filters:             - name: envoy.router

Теперь положим dockerfile:

FROM envoyproxy/envoy:v1.13.0 COPY envoy.yaml /etc/envoy/envoy.yaml

рядом с этим конфигом, соберем и запустим:

docker build -t envoy:v1 . docker run -p 8080:8080 --rm envoy:v1

И это всё! Теперь все http-запросы на балансировщик с префиксом "/echo" Envoy будет распределять между тремя инстансами echo-server.

curl localhost:8080/echo

Request served by a29f0fba3451  HTTP/1.1 GET /echo  Host: localhost:8080 User-Agent: curl/7.64.1 Accept: */* X-Forwarded-Proto: http X-Request-Id: dd4b850c-9b4e-45e5-a411-4b76293b1e33 X-Envoy-Expected-Rq-Timeout-Ms: 15000 Content-Length: 0

Все остальные запросы будут возвращать 404.

В качестве алгоритма балансировки по умолчанию используется round robin (перебор по круговому циклу), который закрывает потребности большинства современных систем.

Я написал небольшой скрипт для проверки распределения запросов между апстрим-нодами. Ссылка на исходники с примерами будет в заключении.

Однако Envoy поддерживает и другие виды балансировки трафика, используя которые можно решать множество самых разнообразных задач. Следующие примеры актуальны прежде всего для stateful-систем и других случаев, когда нужно балансировать запрос на конкретный апстрим-инстанс.

Балансировка на основе consistent hashing

Например, мы хотим получать данные пользователя по его идентификатору.
На такой запрос каждый сервис ходит в одну или несколько других систем или СУБД и агрегирует всю необходимую информацию. Это тяжелый вызов, и для того, чтобы не выполнять его каждый раз, можно добавить кэш в каждый из сервисов. Теперь нам остается распределить все такие вызовы между существующими инстансами, чтобы не дублировать кэши и гарантировать попадание одних и тех же пользователей на одни и те же ноды.

  clusters:     - name: echo_cluster       lb_policy: RING_HASH

Выберем, что использовать в качестве ключа балансировки. Envoy предлагает сразу несколько вариантов. Например, можно поместить идентификатор в хедер запроса.

    - match: { prefix: "/echo" }       route: {          cluster: echo_cluster,             hash_policy: {               header: {                 header_name: id_key             }           }         }

Но что, если нам неудобно передавать ключ балансировки в хедере и мы хотим использовать переменную самого урла. Одна из возможных точек расширения функционала Envoy — использование http фильтров.

Есть неплохая документация по представленным фильтрам и их настройке. С их помощью, например, мы можем реализовать cors, внешнюю авторизацию, проверку jwt-токенов и многое другое. Нам же понадобится фильтр envoy.lua. С его помощью можно встраиваться в обработку как запроса, так и ответа, расширять ее с помощью скрипта на языке Lua.
Просто распарсим путь запроса с помощью регулярного выражения и вручную добавим хедер ‘id_key’.

    - name: envoy.lua       typed_config:         "@type": type.googleapis.com/envoy.config.filter.http.lua.v2.Lua         inline_code: |           function envoy_on_request(request)              hasIdKey = "/echo/key/(.+)/?.*"             path = request:headers():get(":path")             key = path:match(hasIdKey)              if key ~= nil then               request:headers():add("id_key", key)             end           end

Теперь запросы с одним и тем же ключом в урле будут попадать на одну и ту же ноду echo-server:

Стоит учитывать, что при использовании алгоритма RING_HASH могут возникать мисы. Это накладывает ряд ограничений на его применение.

Subset-балансировка

Иногда нам нужно разделять апстрим-инстансы внутри одного кластера. Например, мы хотим выстроить такое флоу, при котором не имеет значения, куда попадет самый первый запрос от клиента, а каждый последующий должен балансировать на тот инстанс, где обслуживался первоначальный.
Envoy представляет готовый механизм для этого, мы можем разделить исходный кластер на основе метаинформации самих инстансов.

- name: echo_cluster       lb_policy: ROUND_ROBIN       lb_subset_config:         fallback_policy: ANY_ENDPOINT         subset_selectors:         - keys:           - instance_id

endpoints:         - lb_endpoints:           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8081             metadata:               filter_metadata: { "envoy.lb" : { "instance_id": "a29f0fba3451"}}           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8082             metadata:               filter_metadata: { "envoy.lb" : { "instance_id": "d6325ed590c0"}}           - endpoint:               address:                 socket_address:                   address: docker.for.mac.localhost                   port_value: 8083             metadata:               filter_metadata: { "envoy.lb" : { "instance_id": "6e2f60a09101"}}

Чтобы Envoy матчил переданный в запросе instance_id с конкретным апстримом, нам необходимо заполнять динамическую метадату каждого запроса.

Воспользуемся еще одним http-фильтром envoy.filters.http.header_to_metadata, который будет заполнять необходимую мету при наличии хедера instance-id.
При этом, если мы все-таки хотим передавать это значение в пути запроса, нам придется повторить трюк из предыдущего пункта.

    - name: envoy.lua       typed_config:         "@type": type.googleapis.com/envoy.config.filter.http.lua.v2.Lua         inline_code: |           function envoy_on_request(request)             hasInstanceId = "/echo/instance/(.+)/?.*"              path = request:headers():get(":path")             key = path:match(hasInstanceId)              if key ~= nil then               request:headers():add("instance-id", key)             end           end

Теперь, выполнив любой запрос, мы получим instance-id (container id), передав который во все следующие вызовы, будем гарантированно попадать на необходимую ноду.

Вместо вывода

Приведенные примеры и полученные результаты, несмотря на простоту реализации, едва ли будут аргументом в пользу Envoy на вашем проде.

За год использования мы в Тинькофф встретили ряд ограничений и неприятных багов. С чем-то мы научились жить самостоятельно, а с чем-то помогли оперативные фиксы. Так или иначе широчайший функционал, высокое качество документации и большое развивающееся комьюнити делает этот продукт очень интересным как минимум для ознакомления.

Ну а в следующий раз мы поговорим о балансировке с весами и зеркалировании трафика.

Репозиторий с примерами.