Что вам нужно знать, если вы поменяете nginx на envoy: впечатления спустя два года



    Мы используем 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!
    Туту.ру
    Tutu.ru — сервис путешествий №1 в России.

    Похожие публикации

    Комментарии 9

      0
      HAProxy не рассматривали?
        0
        Рассматривали. На этапе аналитики haproxy был одним из вариантов data plane, но смутило что он развивается гораздо медленнее чем envoy, далеко не так богат по observability и абсолютно нечеловеческие настройки log format :) Также, разработчики envoy предоставляют несколько реализаций для data plane api, которые можно использовать в control plane, а для haproxy пришлось бы это делать с нуля.
        0
        Очень интересно, но хотелось бы поподробнее сравнить envoy с другими решениями.
        У Nginx есть Nginx Unit, у которого вроде как тоже stateless config.
        И как влияет наличие kubernetes?
        (не, я конечно пойду и почитаю доки сам)
          +1
          Nginx Unit по функционалу больше рассчитан на сетап формата service mesh, где в качестве ingress/front proxy всё равно выступает обычный Nginx/Nginx Plus. Т.е. сравнивать envoy с ним в контексте service mesh можно, но в нашем случае мы не используем service mesh, так что не могу ничего сказать по этому поводу :)

          Наличие kubernetes обычно означает, что в компании возникла необходимость быстро и удобно для разработчиков создавать много микросервисов, что влечёт за собой потребность в автоматизации всей прилегающей инфраструктуры, и envoy здесь хорошо подошёл.
            0
            Понял, спасибо, будем смотреть значит
          0

          Все кастомные хотелки легко закрываются встроенным lua фильтром:)

            0
            Ага, но там вон Dropbox пишет, что задолбались сопровождать свой развесистый lua, понимаю их :)
            0

            Хм, мы вообще сейчас в проектах используем nginx-proxy (у нас нет огромных кластеров), но вообще рассматривали traefik. Кажется трафик выполняет функцию схожую той, что тут описана.


            Вы не рассматривали его?

              0
              Не особо рассматривали, на быстрый взгляд там нужно всё равно делать свой аналог control plane с нуля, в случае если нужно управлять конфигурацией вне куба. Плюс, вот здесь ребята в своих тестах на throughtput получили интересные результаты (не в пользу traefik). Но если попробуете, то расскажите как там оно :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое