🥇Серия постов по Istio Service Mesh

Мы начинаем серию постов, в которой продемонстрируем некоторые из множества возможностей сервисной сетки Istio Service Mesh в сочетании с Red Hat OpenShift и Kubernetes.

Часть первая, сегодняшняя:

Объясним концепцию sidecar-контейнеров Kubernetes и сформулируем лейтмотив этой серии постов: «вам не надо ничего менять в своем коде».
Представим основополагающую вещь Istio – правила маршрутизации. На них строятся все остальные возможности Istio, поскольку именно правила позволяют направлять трафик к микросервисам, используя для этого внешние по отношению к коду сервисов файлы YAML. Также рассматриваем схему развертывания Canary Deployment. Новогодний бонус – 10 интерактивных занятий по Istio

Часть вторая, которая скоро выйдет, расскажет вам:

Как Istio реализует Pool Ejection в сочетании с Circuit Breaker и продемонстрирует, как Istio позволяет убрать из схемы балансировки неработающий или плохо работающий pod.
А еще мы рассмотрим тему Circuit Breaker из первого поста на предмет того, как здесь можно задействовать Istio. Покажем, как без малейших изменений в коде сервисов маршрутизировать трафик и обрабатывать сетевые ошибки с помощью конфигурационных файлов YAML и команд терминала.

Часть третья:

Рассказ о трассировке и мониторинге, которые уже встроены или легко добавляются в Istio. Покажем, как использовать такие инструменты, как Prometheus, Jaeger и Grafana в сочетании с масштабированием OpenShift, чтобы без лишних усилий управлять микросервисной архитектурой.
Переходим от мониторинга и обработки ошибок к тому, чтобы вносить их в систему намеренно. Иначе говоря, учимся делать fault injection без изменения исходного кода, что очень важно с точки зрения тестирования — поскольку если изменять для этого сам код, то есть риск внести дополнительные ошибки.

Наконец, в финальном посте по Istio Service Mesh:

Перейдем на Темную Сторону. Точнее, будем учиться использовать схему Dark Launch, когда код развертывается и тестируется прямо на продакшн-данных, но никак не затрагивает работу системы. Здесь очень кстати приходится умение Istio разделять трафик. А возможность выполнять тестирование на живых продакшн-данных, никак не влияя на работу боевой системы, – это самый убедительный способ проверки.
Отталкиваясь от Dark Launch, покажем, как использовать модель Canary Deployment, чтобы сократить риски и упростить ввод в строй нового кода. Сама по себе Canary Deployment – далеко не новость, но Istio позволяет реализовать эту схему всего лишь с помощью несложных YAML- файлов.
В заключение покажем, как с помощью Istio Egress дать доступ к сервисам тем, кто находится вне ваших кластеров, чтобы задействовать возможности Istio при работе с интернетом.

Итак, понеслась…

Инструментарий мониторинга и управления Istio – все необходимое для координации микросервисов в сервисной сетке service mesh.

Что такое сервисная сетка Istio

Сервисная сетка реализует для группы сервисов такие функции, как мониторинг трафика, контроль доступа, обнаружение, безопасность, отказоустойчивость и другие полезные вещи. Istio позволяет сделать все это без малейших изменений в коде самих сервисов. В чем секрет волшебства? Istio цепляет к каждому сервису свой прокси в виде sidecar-контейнера (sidecar – мотоциклетная коляска), после чего весь трафик к этому сервису идет через прокси, который, руководствуясь заданными политиками, решает как, когда и должен ли вообще этот трафик дойти до сервиса. Istio также дает возможность реализовать продвинутые техники DevOps, такие как canary deployments, circuit breakers, fault injection и многие другие.

Как Istio работает с контейнерами и Kubernetes

Сервисная сетка Istio – это sidecar’ная реализация всего того, что требуется для создания и управления микросервисами: мониторинг, трассировка, circuit breakers, маршрутизация, балансировка нагрузки, fault injection, повторы, тайм-ауты, зеркалирование, контроль доступа, ограничение скорости и многое другое. И хотя сегодня есть масса библиотек, чтобы реализовать эти функции непосредственно в коде, с Istio вы можете получить все то же самое, ничего не меняя в своем коде.

Согласно sidecar’ной модели, Istio выполняется в Linux-контейнере, который располагается в одном Kubernetes-pod’е с контролируемым сервисом и внедряет (inject) и извлекает (extract) функциональность и информацию согласно заданной конфигурации. Подчеркнем, это ваша собственная конфигурация, и она живет вне вашего кода. Поэтому код становится гораздое проще и короче.

Что еще важно, операционная составляющая микросервисов при этом оказывается никак не связана с самим кодом, а значит их эксплуатацию можно спокойно передать ИТ-специалистам. В самом деле, почему разработчик должен отвечать за circuit breaker’ы и fault injection? Реагировать – да, но обрабатывать их и создавать? Если убрать всё этого из кода, программисты смогут полностью сосредоточиться на прикладном функционале. Да и сам код станет короче и проще.

Сервисная сетка

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

Как Istio работает с микросервисами

Вот как выглядит работа sidecar-контейенров с связке с Kubernetes и Minishift с высоты птичьего полета: запускаете экземпляр Minishift, создаете проект для Istio (назовем его «istio-system»), устанавливаете и запускаете все связанные с Istio компоненты. Затем, по мере создания проектов и pod’ов, добавляете конфигурационные сведения в свои deployment’’ы, и ваши pod’ы начинают использовать Istio. Упрощенно диаграмма выглядит так:

Теперь можно изменять настройки Istio, чтобы, например, организовать fault injection, поддержку Canary Deployment или другие возможности Istio – и все это совершенно не трогая код самих приложений. Допустим, вы хотите перенаправить весь веб-трафик от пользователей своего крупнейшего клиента (Foo Corporation) на новую версию сайта. Для этого достаточно создать правило маршрутизации Istio, которое будет искать @foocorporation.com в идентификаторе пользователя и выполнять соответствующее перенаправление. Для всех остальных пользователей ничего не изменится. А вы тем временем будете спокойно тестировать новую версию сайта. И заметьте, для этого совершенно не надо привлекать разработчиков.

И дорого за это придется заплатить?

Отнюдь. Istio работает довольно быстро, он написан на Go и создает совсем небольшой оверхед. Кроме того, возможный проигрыш в онлайн-производительности компенсируется приростом производительности труда разработчиков. По крайней мере, в теории: не забывайте, что время разработчиков стоит дорого. Что касается затрат на ПО, то Istio – это софт с открытым кодом, поэтому получить и использовать его можно бесплатно.

Освойте сами

Команда Red Hat Developer Experience Team разработала углубленное практическое руководство по Istio (на английском). Оно работает на Linux, MacOS и Windows, а код представлен в вариантах на Java и Node.js.

10 интерактивных занятий по Istio

Блок 1 — Для начинающих

Введение в Istio
30 минут
Знакомимся с Service Mesh, учимся устанавливать Istio в Kubernetes кластере OpenShift.
Начать

Развертывание микросервисов в Istio
30 минут
Используем Istio, чтобы развернуть три микросервиса с Spring Boot и Vert.x.
Начать

Блок 2 – средний уровень

Мониторинг и трассировка в Istio
60 минут
Изучаем встроенные средства мониторинга Istio, настраиваемые метрики, а также OpenTracing через Prometheus и Grafana.
Начать

Простая маршрутизация в Istio
60 минут
Учимся управлять маршрутизацией в Istio с помощью простых правил.
Начать

Расширенные правила маршрутизации
60 минут
Знакомимся с умной маршрутизацией в Istio, управлением доступом, балансировкой нагрузки и ограничением скорости.
Начать

Блок 3 – опытный пользователь

Fault Injection в Istio
60 минут
Изучаем сценарии обработки отказов в распределенных приложений, создавая ошибки HTTP и сетевые задержки, учимся применять хаос-инжиниринга для восстановления среды.
Начать

Circuit Breaker в Istio
30 минут
Устанавливаем Siege для стресс-тестирования сайтов и учимся обеспечить отказоустойчивость бэкенда с помощью повторов, circuit breaker и pool ejection.
Начать

Egress и Istio
10 минут
Используем маршруты Egress для создания правил взаимодействия внутренних сервисов с внешними API и сервисами.
Начать

Istio и Kiali
15 минут
Учимся использовать Kiali для получения общей картины сервисной сетки и изучения потоков запросов и данных.
Начать

Mutual TLS в Istio
15 минут
Создаем Istio Gateway и VirtualService, затем подробно изучаем mutual TLS (mTLS) и его настройки.
Начать

Блок 3.1 — Глубокое погружение: Istio Service Mesh для микросервисов

Про что книга:

Что такое сервисная сетка service mesh.
Система Istio и ее роль в микросервисной архитектуре.
Использование Istio при решении следующих задач:
- Отказоустойчивость;
- Маршрутизация;
- Хаос-тестирование;
- Безопасность;
- Сбор телеметрии средствами трассировки, метрик и Grafana.

Скачать книгу

Серия статей по сервисным сеткам и Istio

Попробуйте сами

Эта серия постов не ставит целью обеспечить глубокое погружение в мир Istio. Мы просто хотим познакомить вас с самой концепцией и, может быть, вдохновить самостоятельно попробовать Istio. Это можно сделать совершенно бесплатно, и Red Hat предоставляет все необходимые инструменты, чтобы начать осваивать OpenShift, Kubernetes, Linux-контейнеры и Istio, а именно: Red Hat Developer OpenShift Container Platform, наше руководство по Istio и другие ресурсы на нашем микро-сайте по Service Mesh. Не стоит откладывать, начните прямо сегодня!

Правила маршрутизации Istio: направляем сервис-запросы туда, куда нужно

OpenShift и Kubernetes прекрасно справляются с тем, чтобы обращения к микросервисам маршрутизировались к нужным pod’ам. В этом и есть одна из целей существования Kubernetes – маршрутизация и балансировка нагрузки. А что, если вам нужна более тонкая и изощренная маршрутизация? Например, чтобы одновременно использовать две версии микросервиса. Как здесь помогут правила маршрутизации Istio Route Rules?

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

Kubernetes умолчанию: тривиальное «50 на 50»

В нашем примере мы покажем, как одновременно использовать в OpenShift две версии микросервиса, назовем их v1 и v2. Каждая версия запускается в собственном pod’е Kubernetes, и по умолчанию здесь работает равномерно сбалансированная циклическая маршрутизация (evenly balanced round robin routing). Каждый pod получает свою долю запросов по числу его экземпляров микросервиса, иначе говоря, реплик. Istio же позволяет поменять этот баланс вручную.

Допустим, мы развернули на OpenShift две версии нашего рекомендационного сервиса, recommendation-v1 и recommendation-v2.
На рис. 1 видно, что, когда каждый сервис представлен в одном экземпляре, запросы равномерно чередуются между ними: 1-2-1-2-… Именно так маршрутизация Kubernetes работает по умолчанию:

Взвешенное распределение между версиями

На рис. 2 показано, что будет, если увеличить количество реплик сервиса v2 с одной до двух (это делается командой oc scale —replicas=2 deployment/recommendation-v2). Как видим, запросы между v1 и v2 теперь делятся в отношении «один к трем»: 1-2-2-1-2-2-…:

Игнор версии с помощью Istio

Istio позволяет легко изменить распределение запросов нужным нам образом. Например, отправлять весь трафик только на recommendation-v1 с помощью следующего yaml-файла Istio:

Здесь надо обратить внимание вот на что: pod’ы выбираются согласно меткам. В нашем примере используется метка v1. Параметр «weight: 100» означает, что 100% трафика будет маршрутизироваться на все pod’ы сервиса, у которых есть метка v1.

Директивное распределение между версиями (Canary Deployment)

Далее, используя параметр weight, можно направлять трафик к обоим pod’ам, игнорируя количество экземпляров микросервисов, запущенных в каждом из них. Например, здесь мы директивно направляем 90% трафика на v1 и 10% – на v2:

Отдельная маршрутизация мобильных пользователей

В заключение покажем, как принудительно маршрутизировать трафик мобильных пользователей на сервис v2, а всех остальных – на v1. Для этого мы помощью регулярных выражений анализируем значение user-agent в заголовке запроса:

Теперь ваша очередь

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

И помните, что Ops, а не Dev

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

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

Включите воображение

Только представьте, какие перспективы открывает анализ заголовков с помощью регулярных выражений. Хотите перенаправлять вашего крупнейшего клиента на специальную версию своих микросервисов? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.

Попробуйте сами

Читать про Istio, Kubernetes и OpenShift – это одно, но почему бы не потрогать все своими руками? Команда Red Hat Developer Program подготовила подробное руководство (на английском), которое поможет вам максимально быстро освоить эти технологии. Руководство тоже 100% open source, поэтому оно размещено в открытом доступе. Файл работает на macOS, Linux и Windows, а исходный код есть в вариантах на Java и node.js (скоро будут версии и на других языках). Просто откройте в своем браузере соответствующий git-репозиторий Red Hat Developer Demo.

В следующем посте: отрабатываем проблемы красиво

Сегодня вы увидели, на что способны правила маршрутизации Istio. А теперь представьте все то же самое, но только применительно к обработке ошибок. Именно об этом мы и расскажем в следующем посте.

Источник: habr.com