НОВОСТИ Envoy для самых маленьких

BDFpromo · 26.03.2020

Всем привет!

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

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

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

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

На Хабре есть

You must be registered for see links

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

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

You must be registered for see links

на Go. Удобнее всего развернуть

You must be registered for see links

, назначив каждому свой порт. Я поднял три инстанса: на 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:

You must be registered for see links

, 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:

You must be registered for see links

}

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

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

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

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

You must be registered for see links

есть уже готовые реализации на Go и Java. Динамический подход будет крайне полезен в случае сложной конфигурации вашей системы и необходимости реагировать на ее изменения в рантайме.

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

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

Конфигурация кластера с тремя инстансами 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 необходимо задекларировать роуты наших апстрим-сервисов. Согласно официальной документации, есть

You must be registered for see links

сделать это. Например, можно отправлять все запросы с префиксом "/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 (перебор по круговому циклу), который закрывает потребности большинства современных систем.

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

Гистограмма распределения 500 запросов GET '/echo' по round-robin

Однако Envoy поддерживает и

You must be registered for see links

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

Балансировка на основе
You must be registered for see links

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

Добавим 'lb_policy: RING_HASH' в конфигурацию нашего кластера

clusters:
- name: echo_cluster
lb_policy: RING_HASH

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

You must be registered for see links

. Например, можно поместить идентификатор в хедер запроса.

Используем id_key в качестве ключа

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

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

Есть

You must be registered for see links

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

You must be registered for see links

. С его помощью можно встраиваться в обработку как запроса, так и ответа, расширять ее с помощью скрипта на языке Lua.
Просто распарсим путь запроса с помощью регулярного выражения и вручную добавим хедер 'id_key'.

Lua скрипт

- 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("

ath")
key = path:match(hasIdKey)

if key ~= nil then
request:headers():add("id_key", key)
end
end

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

Распределение 500 вызовов GET '/echo/key/2570e384-5fc0-11ea-bc55-0242ac130003'

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

You must be registered for see links
-балансировка

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

Заполняем lb_subset_config, где указываем разделение по instance_id

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

Заполняем 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-фильтром

You must be registered for see links

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

Lua скрипт для использования 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("

ath")
key = path:match(hasInstanceId)

if key ~= nil then
request:headers():add("instance-id", key)
end
end

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

Распределение 500 вызовов GET '/echo/instance/a29f0fba3451'

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

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

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

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

You must be registered for see links

НОВОСТИ Envoy для самых маленьких

BDFpromo