Мы используем envoy как front edge proxy, который перенаправляет входящий трафик в несколько кластеров kubernetes (для новых сервисов) и в бэкенды legacy-архитектуры исторического наследия. Т.е. там сочетаются функции как обычного балансировщика и ssl termination point, так и api gateway.

До envoy у нас там был nginx, как и у многих. Классный софт, мне нравится. Вся история с envoy началась в тот момент, когда начались микросервисы в большом количестве и даже шаблоны ansible не спасали от увеличивающегося времени на управление nginx-конфигом. Долго выкатывалось, плюс админы приунывали от однообразных заявок вида «заведите мне домен для нового сервиса». Явно была нужна более лучшая™ автоматизация. В идеале, чтобы тот, кому нужно что-то завести, мог сам это сделать и желательно в том же месте, где настраивал прочие параметры своего сервиса. Вдобавок хотелось побольше прозрачности в том, что происходит внутри front proxy и на отрезке между ним и апстримами, и больше нативных возможностей для балансировки (переповторы запросов разных типов, исключение нездоровых хостов по определённым условиям, хелсчеки). И привлекла edge-технология, конечно же.

Long story short, вот перевод статьи о переходе Dropbox на envoy, там много деталей про его сравнение с nginx. Я же расскажу больше про личные впечатления от результатов перехода.

Самый главный и очевидный факт для любого, кто сталкивался с использованием масштабируемого ПО: будьте готовы за него заплатить. Повышенной сложностью сетапа (data plane + control plane), а если есть апстримы не только в kubernetes, то, возможно, даже написанием своего control plane. Также в случае конкретно с envoy — за относительную молодость софта и отсюда — отсутствием некоторых, обычных для nginx, фич + повышенной частотой обновлений, если эти фичи в них добавляются. Например, может оказаться, что в штатных опциях нет какого-нибудь умолчального для nginx объединения слешей в :path, отбрасывания порта из заголовка Host или, прости господи, rewrite по регекспу. На сегодня всё из этого списка уже добавили, но наверняка найдёте что-то ещё.

Положительные вещи

Ужасная документация! А положительное здесь то, что команда envoy в конце прошлого года наконец-то наняла технического писателя и всё стало значительно дружелюбнее. По крайней мере, больше не нужно изучать путь обработки запроса по исходникам и находить описание работы некоторых опций исключительно в ответах в твоём issue. А для нахождения самих опций — быть мастером гугления 80-го уровня. Теперь многое из этого в прошлом, хотя авторы всё ещё не утруждают себя отметкой, в какой версии envoy появилась та или иная опция, или ссылками на issue в release notes, но хотя бы начали выделять список ломающих изменений в релизах в выделенную секцию, видно, что есть прогресс.

Расширенная телеметрия

Здесь все надежды оправдались, теперь наш grafana-дашборд по envoy убивает браузеры всех неподготовленных количеством графиков. А если серьёзно, то теперь можно удобно следить за тем, что происходит с трафиком на всех этапах его прохождения, особенно хорошо это помогает в увлекательных детективных историях — расследованиях после происшествий. И, конечно же, определение аномалий.


Аномалия: «Привет». Фрагмент из того самого envoy grafana-дашборда.

Про control plane

Ну и самое главное, ради чего всё затевалось, — решили задачу автоматического управления роутами. Два слова про подход, если кто не в теме: control plane работает контроллером данных, управляет их хранением и создаёт конфиг, который потом отдаёт в envoy (stateless data plane).

Если в качестве бэкенда у вас только один kubernetes, то можно брать готовый control plane типа ambassador. Но нам нужно было управлять и старой инфрой тоже, плюс кластеров было несколько. Так что пришлось взять одну из предлагаемых проектом envoy реализаций data plane api и навернуть все нужные нам особенности, связав эту часть инфраструктуры с автоматикой в kubernetes, но это уже тема отдельной интересной истории.

Впечатления от процесса перехода на envoy — «почему-то не было особых проблем, очень подозрительно».

Вкратце, с чего начать и к чему быть сразу готовым. После медитации над документацией envoy и принятием тщетности сущего берём два виртуальных хоста со старого front proxy (самый простой и типичный, и самый развесистый), заводим их в envoy, разбираясь в опциях по ходу дела.

Здесь главное иметь в виду, что подходы к написанию конфигов между nginx и envoy очень различаются, т.е. надо быть готовым к крутым поворотам вида: вместо двух простых записей allow/deny пишем 26 строчек дерева RBAC-правил. В общем, принять, что немного взрывающаяся голова здесь — это нормально, так как конфиг envoy сделан c приоритетом на удобство автоматизации, а не на human readability.

Возможно, придётся составить шпаргалку маппинга опций и убедиться, что они действительно делают то, что вы думаете. Так мы однажды наступили на то, что механизм объединения слешей в URL (даже тогда, когда он уже был добавлен в envoy) работает по-разному: в nginx он не изменял :path, который отправлялся в upstream, а в envoy происходила полноценная перезапись, и всё бы ничего, но при этой перезаписи вылезал баг, который менял :path совсем на дичь, ну в общем, после нашего issue это тоже починили, но будьте осторожны.

Кстати, об issues — не могу не сказать про ещё одно положительное впечатление.

Доброжелательное сообщество и разработчики

Так как envoy — CNCF-hosted open source, то можно традиционно просто прийти в GitHub проекта и предложить своё улучшение или задать вопрос. Issues дикое количество, рук у разработчиков явно не хватает, но при этом самое плохое, что может случиться с вашим вопросом, — его проигнорируют. Хотя чаще всего хоть что-то, но отвечают, даже если это что-то краткое в духе «извини, это делать не планируем». Никакой токсичности, даже если вопросы от новичков, очень доброжелательная атмосфера.


Атмосферные топики, особенно corgis. Скрин публичного репозитория envoy на github.com

Ну и как обычно — pull requests are welcome. В них помогают даже тем, кто не особо шарит в C++. Также есть ряд issues, помеченных тегом beginner, на случай, если кто-то хочет внести свой вклад и не знает, с чего начать.

Кроме GitHub есть ещё email-рассылки и slack, но в последнем чаще каша. :)

Из мероприятий проводят EnvoyCon, который сейчас, правда, онлайн, но всё равно рекомендую.

Итог

В общем, вам не нужен envoy только потому, что он модный-молодёжный, «все переходят» и у фаундера забавная причёска. Оставайтесь на чём были, пока не прижмёт. Если у вас стартап или просто маленький проект — однозначно лучше оставить nginx, потому что он простой и милый. Там главное запустить.

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

Удачи и, может быть, до встречи на EnvoyCon!