Dark Launch в Istio: секретные службы

    «Опасность – мое второе имя», – говаривал Остин Пауэрс, человек-загадка международного масштаба. Но то, что в почете у суперагентов и спецслужб, совсем не годится для служб компьютерных, где скукотища гораздо лучше опасностей.



    И Istio вместе OpenShift и Kubernetes превращают развертывание микросервисов в дело по-настоящему скучное и предсказуемое – и это прекрасно. Об этом и о многом другом поговорим в четвертом и последнем посте из серии про Istio.

    Когда скукотища – это правильно


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

    При развертывании новой версии вашего софта стоит рассмотреть все варианты минимизации рисков. Работа в параллельном режиме – это очень мощный и проверенный способ тестирования, и Istio позволяет задействовать для этого «секретную службу» (скрытую от посторонних глаз версию вашего микросервиса) без вмешательства в работу продакшн-системы. Для этого есть даже специальный термин – «Тайный запуск» (Dark Launch), который в свою очередь активируется функцией с не менее шпионским названием «зеркалирование трафика».

    Обратите внимание, что в первом предложении предыдущего абзаца используется термин «развертывание» (deploy), а не «запуск» (release). Вы действительно должны иметь возможность развертывать – и, разумеется, использовать – свой микросервис так часто, как пожелаете. Этот сервис должен быть способен принимать и обрабатывать трафик, выдавать результаты, а также писать в логи и мониториться. Но при этом сам этот сервис вовсе необязательно выпускать в продакшн. Развертывание и выпуск ПО – это не всегда одно и то же. Развертывание вы можете выполнять всегда, когда захотите, а вот выпуск – только тогда, когда будете окончательно готовы.

    Организация скуки – это интересно


    Взгляните на следующее правило маршрутизации Istio, которое направляет все HTTP-запросы на микросервис recommendation v1 (все примеры взяты из Istio Tutorial GitHub repo), одновременно зеркалируя их на микросервис recommendation v2:


    Обратите внимание на метку mirror: внизу скрина – именно она задает зеркалирование трафика. Да, вот так просто!

    Результатом работы этого правила станет то, что ваша продакшн-система (v1) будет по-прежнему обрабатывать поступающие запросы, но сами запросы при этом будут асинхронно зеркалиться на v2, то есть туда будут уходить их полные дубликаты. Таким образом, вы сможете протестировать работу v2 в реальных условиях – на настоящих данных и трафике, – никак не вмешиваясь в работу продакшн-системы. Превращает ли это организацию тестирования в скукотищу? Да, безусловно. Но делается это интересно.

    Добавим драмы


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

    Повторим важный момент


    Тайный запуск с зеркалированием трафика (Dark Launch/Request Mirroring) можно выполнять, никак не затрагивая код.

    Пища для размышления


    А что, если место зеркалирования запросов отправлять часть из них не на v1, а на v2? Например, один процент от всех запросов или только запросы от определенной группы пользователей. И потом, уже глядя на то, как работает v2, постепенно переводить на новую версию все запросы. Или наоборот вернуть всё на v1, если с v2 что-то пойдет не так. Кажется, это называется Canary Deployment («канареечное развертывание» – термин восходит к горному делу, и будь у него русское происхождение, он вероятно содержал бы отсылку к кошкам), и сейчас мы это рассмотрим подробнее.

    Canary Deployment в Istio: упрощаем ввод в строй


    Осторожно и постепенно


    Суть модели развертывания Canary Deployment предельно проста: при запуске новой версии своего софта (в нашем случае – микросервиса) вы сначала даете к ней доступ небольшой группе пользователей. Если всё идет нормально, вы медленно увеличиваете эту группу до тех пор, пока новая версия не начинает барахлить, или – если этого так и не происходит – в итоге переводите на нее всех пользователей. Продуманно и постепенно вводя в строй новую версию и контролируемо переключая на нее пользователей, можно снизить риски и максимизировать обратную связь.

    Разумеется, Istio упрощает Canary Deployment, предлагая сразу несколько хороших вариантов для интеллектуальной маршрутизации запросов. И да, все это можно сделать, никак не трогая ваш исходный код.

    Фильтруем браузер


    Один из самых простых критериев маршрутизации – это перенаправление в зависимости от браузера. Допустим, вы хотите, чтобы на v2 уходили только запросы из браузеров Safari. Вот как это делается:


    Применим это правило маршрутизации и затем командой curl будем в цикле имитировать реальные запросы к микросервису. Как видно на скриншоте, все они уходят на v1:


    А где же трафик на v2? Поскольку в нашем примере все запросы шли только из нашей же командной строки, то его попросту нет. Но обратите внимание на нижние строчки на скрине выше: это реакция на то, что мы выполнили запрос из браузера Safari, который в свою очередь выдал вот что:


    Неограниченная власть


    Мы уже писали, что регулярные выражения дают очень мощные возможности для маршрутизации запросов. Взгляните на следующий пример (думаем, вы и сами поймете, что он делает):


    Теперь вы, вероятно, уже представляете, на что способны регулярные выражения.

    Действуйте умно


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

    Заинтересовались?


    Загорелись желанием поэкспериментировать с Istio, Kubernetes и OpenShift на своем компьютере? Команда Red Hat Developer Team подготовила отличный учебник по этой теме и выложила в общий доступ все сопутствующие файлы. Так что вперед, и ни в чем себе не отказывайте.

    Istio Egress: выход через сувенирную лавку


    Применяя Istio вместе с Red Hat OpenShift и Kubernetes, можно значительно облегчить себе жизнь с микросервисами. Сервисная сетка Istio упрятана внутрь Kubernetes’овских pod’ов, а ваш код выполняется (в основном) изолированно. Производительность, простота изменения, трассировка и прочее – все это легко использовать именно за счет применения sidecar-контейнеров. Но что делать, если ваш микросервис должен общаться с другим сервисами, которые расположены за пределами вашей системы OpenShift-Kubernetes?

    Здесь на помощь приходит Istio Egress. Если в двух словах, то он просто позволяет получить доступ к ресурсам (читай: «сервисам»), которые не входят в вашу систему Kubernetes’овских pod’ов. Если не выполнять дополнительную настройку, то в среде Istio Egress трафик маршрутизируется только внутри кластера pod’ов и между такими кластерами исходя из внутренних IP-таблиц. И такое закукливание прекрасно работает до тех пор, пока вам не нужен доступ к сервисам снаружи.

    Egress позволяет обойти вышеупомянутые IP-таблицы, либо на основе правил Egress, либо для диапазона IP-адресов.

    Допустим, у нас есть Java-программа, которая выполняет GET-запрос к httpbin.org/headers.

    (httpbin.org – это просто удобный ресурс для тестирования исходящих сервис-запросов.)

    Если ввести в командной строке curl http://httpbin.org/headers, мы увидим следующее:


    Или можно открыть этот же адрес в браузере:


    Как видим, расположенный там сервис просто возвращает переданные ему заголовки.

    Импортозамещаем в лоб


    Теперь возьмем Java-код этого внешнего по отношению к нашей системе сервиса и запустим его у себя, где, напомним, стоит Istio. (Вы можете сделать это самостоятельно, обратившись к нашему учебнику по Istio.) Выполнив сборку соответствующего образа и запустив его на платформе OpenShift, мы вызовем этот сервис командой curl egresshttpbin-istioegress.$(minishift ip).nip.io, после чего увидим на экране вот что:


    Опа, а что произошло? Всё же только что работало. Что значит Not Found? Мы же только что сделали для него curl.

    Расширяем IP-таблицы на весь интернет


    Винить (или благодарить) за это надо Istio. Ведь Istio – это просто sidecar- контейнеры, который отвечают за обнаружение и маршрутизацию (ну и за массу других вещей, о которых мы рассказывали ранее). По этой причине IP-таблицы знают только о том, что находится внутри вашей системы кластеров. А httpbin.org расположен снаружи и, следовательно, недоступен. И вот тут на помощь приходит Istio Egress – без малейших изменений в вашем исходном коде.

    Приведенное ниже Egress-правило заставляет Istio искать (если надо, то и во всем всемирном интернете) нужный сервис, в данном случае, httpbin.org. Как видно из этого файла (egress_httpbin.yml), функциональность здесь довольно простая:


    Осталось только применить это правило:

    istioctl create -f egress_httpbin.yml -n istioegress
    

    Просмотреть правила Egress можно командой istioctl get egressrules:


    И наконец, опять запускаем команду curl – и видим, что все работает:


    Мыслим открыто


    Как видите, Istio позволяет организовать взаимодействие и с внешним миром. Иными словами, вы можете всё так же создавать сервисы OpenShift и рулить ими через Kubernetes, держа всё в pod’ах, которые масштабируются вверх-вниз по мере надобности. И при этом вы спокойно можете обращаться к внешним по отношению к вашей среде сервисам. И да, еще раз повторимся, что все это можно делать, никак не трогая ваш код.

    Это был последний пост из серии по Istio. Оставайтесь с нами – впереди много интересного!
    Red Hat
    Программные решения с открытым исходным кодом

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

      0
      при зеркалировании трафика, куда деваются ответы от приложений на которые зеракалировали трафик?
      например, на get запрос приложение должно отдать 10МБ данных, и при нагрузке 10 запросов в секунду, приложение генерит 100МБ трафика. Так вот, эти 100МБ гасятся самим istio или этот момент надо отдельно обработать правилами?
        0

        Ответы тонут в пучинах /dev/null, отдельная конфигурация для этого не нужна


        Also, it is important to note that these requests are mirrored as “fire and forget”, which means that the responses are discarded.

        https://istio.io/docs/tasks/traffic-management/mirroring/

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

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