ingress istio что это
Обзор и сравнение контроллеров Ingress для Kubernetes
При запуске кластера Kubernetes для конкретного приложения следует понимать, какие требования представляет к этому ресурсу само приложение, бизнес и разработчики. При наличии этой информации можно приступать к принятию архитектурного решения и, в частности, к выбору конкретного Ingress-контроллера, коих на сегодняшний день уже большое количество. Чтобы составить базовое представление об имеющихся вариантах без необходимости изучать множество статей/документации и т.п., мы и подготовили этот обзор, включив в него основные (production ready) Ingress-контроллеры.
Надеемся, что он поможет коллегам в выборе архитектурного решения — по крайней мере, станет отправной точкой для получения более подробной информации и практических экспериментов. Предварительно мы изучили другие подобные материалы в сети и, как ни странно, не обнаружили ни одного более-менее полного, а главное — структурированного — обзора. Итак, заполним же этот пробел!
Критерии
Чтобы в принципе проводить сравнение и получить сколько-нибудь полезный результат, надо понимать не просто предметную область, но и иметь конкретный список критериев, которые и будут задавать вектор исследования. Не претендуя на анализ всех возможных случаев применения Ingress/Kubernetes, мы постарались выделить наиболее общие требования к контроллерам — будьте готовы, что всю свою специфику и частности в любом случае придётся изучать отдельно.
Но начну с характеристик, которые стали настолько привычными, что реализованы во всех решениях и не рассматриваются:
Поддерживаемые протоколы
Один из основополагающих критериев для выбора. Ваше ПО может работать не по стандартному HTTP или же требовать работу сразу по множеству протоколов. Если ваш случай — нестандартный, обязательно берите в расчет этот фактор, дабы не пришлось потом перенастраивать кластер. У всех контроллеров список поддерживаемых протоколов варьируется.
ПО в основе
Есть несколько вариантов приложений, на которых основан контроллер. Популярные — это nginx, traefik, haproxy, envoy. В общем случае, возможно, не слишком влияет на то, как принимается и передается трафик, однако всегда полезно знать потенциальные нюансы и особенности того, что «под капотом».
Маршрутизация трафика
На основе чего можно принимать решение о направлении трафика в тот или иной сервис? Обычно это host и path, но бывают и дополнительные возможности.
Пространство имен в рамках кластера
Пространство имён (namespace) — возможность логически разбивать ресурсы в Kubernetes (например, на stage, production и т.п.). Есть Ingress-контроллеры, которые надо ставить отдельно в каждый namespace (и тогда он может направлять трафик только в pod’ы этого пространства). А есть такие (и их явное большинство), что работают глобально на весь кластер — в них трафик направляется в любой pod кластера, независимо от пространства имён.
Пробы для upstream’ов
Каким образом обеспечивается направление трафика в здоровые экземпляры приложения, сервисов? Есть варианты с активными и пассивными проверками, повторными попытками (retries), circuit breakers (подробнее о них см., например, в статье про Istio), собственными реализациями проверок состояния (custom health checks) и т.п. Весьма важный параметр, если у вас высокие требования к доступности и своевременному выводу из балансировки отказавших сервисов.
Алгоритмы балансировки
Тут множество вариантов: от традиционных round-robin до экзотических вроде rdp-cookie, а также отдельные возможности вроде sticky sessions.
Аутентификация
Какие схемы авторизации поддерживает контроллер? Basic, digest, oauth, external-auth — думаю, что эти опции должны быть знакомы. Это важный критерий, если используется много контуров для разработчиков (и/или просто закрытых), доступ к которым осуществляется через Ingress.
Распределение трафика
Поддерживает ли контроллер такие часто применяемые механизмы для распределения трафика, как канареечные выкаты (canary), A/B-тестирование, зеркалирование трафика (mirroring/shadowing)? Это по-настоящему больная тема для приложений, которые требуют аккуратного и точного управления трафика для продуктивного тестирования, отладки продуктовых ошибок не на бою (или с минимальными потерями), анализа трафика и т.п.
Платная подписка
Есть ли платный вариант у контроллера, с расширенными функциональными возможностями и/или технической поддержкой?
Графический интерфейс (Web UI)
Имеется ли какой-либо графический интерфейс для управления конфигурацией контроллера? В основном для «сподручности» и/или для тех, кому требуется вносить какие-то изменения в конфигурацию Ingress’а, но работать с «сырыми» шаблонами неудобно. Может пригодится в случае, если разработчики хотят налету проводить какие-либо эксперименты с трафиком.
JWT-валидация
Наличие встроенной проверки JSON web-токенов для авторизации и валидации пользователя конечному приложению.
Возможности для кастомизации конфига
Расширяемость шаблонов в смысле наличия механизмов, позволяющих добавлять в стандартные шаблоны конфигурации собственные директивы, флаги и т.д.
Базовые механизмы защиты от DDOS
Простые алгоритмы rate limit или же более сложные варианты отсеивания трафика на основе адресов, белых списков, стран и т.д.
Трассировка запросов
Возможности наблюдения, отслеживания и отладки запросов от Ingress’ов к конкретным сервисам/pod’ам, а в идеале — и между сервисами/pod’ами тоже.
Контроллеры Ingress
Список контроллеров был сформирован на основе официальной документации Kubernetes и этой таблицы. Некоторые из них мы исключили из обзора ввиду специфичности или малой распространенности (ранней стадии развития). Оставшиеся же рассмотрены ниже. Начнём с общего описания решений и продолжим сводной таблицей.
Ingress от Kubernetes
Это официальный контроллер для Kubernetes, который разрабатывается сообществом. Очевидно из названия, он основан на nginx и дополнен различным набором Lua-плагинов, применяемых для реализации дополнительных возможностей. Благодаря популярности самого nginx’а и минимальных модификаций над ним при использовании в качестве контроллера, этот вариант может быть самым простым и понятным в конфигурации среднестатистическим инженером (с опытом в web).
Ingress от NGINX Inc
Официальный продукт разработчиков nginx. Имеет платную версию, основанную на NGINX Plus. Основная идея — высокий уровень стабильности, постоянная обратная совместимость, отсутствие каких-либо посторонних модулей и заявленная повышенная скорость (в сравнении с официальным контроллером), достигнутая благодаря отказу от Lua.
Бесплатная версия существенно урезана, в том числе даже при сравнении с официальным контроллером (из-за отсутствия всё тех же Lua-модулей). Платная при этом имеет достаточно широкий дополнительный функционал: метрики в реальном времени, JWT-валидация, активные health check’и и другое. Важное преимущество перед NGINX Ingress — полноценная поддержка TCP/UDP-трафика (и в community-версии тоже!). Минус — отсутствие фич по распределению трафика, что, впрочем, «имеет максимальный приоритет для разработчиков», но требует времени на реализацию.
Kong Ingress
Продукт, разрабатываемый компанией Kong Inc. в двух вариантах: коммерческий и бесплатный. Основан на nginx, возможности которого расширены большим количеством модулей на Lua.
Изначально был ориентирован на обработку и маршрутизацию запросов API, т.е. как API Gateway, однако на данный момент стал полноценным Ingress-контроллером. Основные преимущества: множество дополнительных модулей (в том числе и от сторонних разработчиков), которые легко ставить и конфигурировать и с помощью которых реализуется широкий спектр дополнительных возможностей. Впрочем, встроенные функции уже предлагают многие возможности. Конфигурация работы производится с помощью CRD-ресурсов.
Важная особенность продукта — работа в рамках одного контура (вместо cross-namespaced) является спорной темой: кому-то покажется недостатком (приходится плодить сущности для каждого контура), а для кого-то — фича (больший уровень изоляции, т.к. если сломан один контроллер, то проблема ограничена одним только контуром).
Traefik
Прокси, который изначально создавался для работы с маршрутизацией запросов для микросервисов и их динамической среды. Отсюда и многие полезные возможности: обновление конфигурации совсем без перезагрузок, поддержка большого количества методов балансировки, веб-интерфейс, проброс метрик, поддержка различных протоколов, REST API, канареечные релизы и многое другое. Приятной особенностью также является поддержка сертификатов Let’s Encrypt из коробки. Недостаток — для организации высокой доступности (HA) у контроллера потребуется устанавливать и подключать собственное KV-хранилище.
HAProxy
HAProxy давно известен в качестве прокси и балансировщика трафика. В рамках кластера Kubernetes с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе DNS, динамическая конфигурация с помощью API. Привлекательным может стать полная кастомизация шаблона конфигов с помощью замены CM’а, а также возможности использования в нём функций библиотеки Sprig. В целом же основной акцент решения делается на высокую скорость работы, его оптимизированность и эффективность в потребляемых ресурсах. Преимущество контроллера — поддержка рекордного числа различных способов балансировки.
Voyager
Основанный на HAproxy контроллер, который позиционируется как универсальное решение, поддерживающее широкие возможности на большом количестве провайдеров. Предлагается возможность для балансировки трафика на L7 и L4, а балансировку TCP L4-трафика в целом можно назвать одной из ключевых фич решения.
Contour
В основу этого решения не только лёг Envoy: оно разработано совместно с авторами этого популярного прокси. Важная особенность — возможность разделения управления ресурсами Ingress с помощью CRD-ресурсов IngressRoute. Для организаций со множеством команд разработки, использующих один кластер, это помогает максимально обезопасить работу с трафиком в соседних контурах и защитить их от ошибок при изменении ресурсов Ingress.
Также предлагается расширенный набор методов балансировки (присутствует зеркалирование запросов, автоповторы, ограничение по rate’у запросов и многое другое), детальный мониторинг потока трафика и сбоев. Возможно, для кого-то будет существенным недостатком отсутствие поддержки sticky sessions (хотя работы уже ведутся).
Istio Ingress
Комплексное service mesh-решение, которое является не только Ingress-контроллером, управляющим поступающим трафиком извне, но и контролирует весь трафик в рамках кластера. «Под капотом», в качестве sidecar-прокси для каждого сервиса, используется Envoy. В сущности это большой комбайн, который «может всё», а основная его идея — максимальная управляемость, расширяемость, безопасность и прозрачность. С его помощью вы можете в тонкостях настраивать маршрутизацию трафика, авторизацию доступа между сервисами, балансировку, мониторинг, канареечные релизы и многое другое. Подробнее об Istio читайте в серии статей «Назад к микросервисам с Istio».
Ambassador
Ещё одно решение на основе Envoy. Имеет бесплатную и коммерческую версии. Позиционируется как «полностью родное для Kubernetes», что приносит соответствующие преимущества (тесная интеграция с методами и сущностями кластера K8s).
Сравнительная таблица
Итак, кульминация статьи — эта огромная таблица:
Она кликабельна для возможности более детального просмотра, а также доступна в формате Google Sheets.
Подведём итоги
Цель статьи — предоставить более полное понимание (впрочем, совершенно не исчерпывающее!) того, какой выбор сделать в вашем конкретном случае. Как обычно бывает, каждый контроллер имеет свои достоинства и недостатки…
Классический Ingress от Kubernetes хорош своей доступностью и проверенностью, достаточно богатыми возможностями — в общем случае его должно «хватить за глаза». Однако, если есть повышенные требования к стабильности, уровню фич и разработки, стоит обратить внимание на Ingress с NGINX Plus и платной подпиской. Kong имеет богатейший набор плагинов (и, соответственно, обеспечиваемых ими возможностей), причём в платной версии их даже больше. У него широкие возможности по работе в качестве API Gateway, динамического конфигурирования на основе CRD-ресурсов, а также базовых сервисов Kubernetes.
При повышенных требованиях к балансировке и методам авторизации присмотритесь к Traefik и HAProxy. Это Open Source-проекты, проверенные годами, очень стабильные и активно развивающиеся. Contour появился уже пару лет как на свет, но выглядит всё еще слишком молодо и имеет лишь базовые возможности, добавленные поверх Envoy. Если есть требования по наличию/встраиванию WAF перед приложением, стоит обратить внимание на тот же Ingress от Kubernetes или HAProxy.
А самые богатые по функциям — это продукты, построенные на базе Envoy, в особенности Istio. Он представляется комплексным решением, который «может всё», что, впрочем, означает и значительно более высокий порог вхождения по конфигурации/запуску/администрированию, чем у других решений.
Нами в качестве стандартного контроллера был выбран и до сих пор используется Ingress от Kubernetes, который покрывает 80—90% потребностей. Он вполне надёжен, легко конфигурируется, расширяется. В общем случае, при отсутствии специфичных требований, он должен подойти большинству кластеров/приложений. Из таких же универсальных и относительно простых продуктов можно порекомендовать Traefik и HAProxy.
Ликбез по запуску Istio
Istio Service Mesh
Мы в Namely уже год как юзаем Istio. Он тогда только-только вышел. У нас здорово упала производительность в кластере Kubernetes, мы хотели распределенную трассировку и взяли Istio, чтобы запустить Jaeger и разобраться. Service mesh так здорово вписалась в нашу инфраструктуру, что мы решили вложиться в этот инструмент.
Пришлось помучиться, но мы изучили его вдоль и поперек. Это первый пост из серии, где я расскажу, как Istio интегрируется с Kubernetes и что мы узнали о его работе. Иногда будем забредать в технические дебри, но не сильно далеко. Дальше будут еще посты.
Что такое Istio?
Istio — это инструмент конфигурации service mesh. Он читает состояние кластера Kubernetes и делает обновление до прокси L7 (HTTP и gRPC), которые реализуются как sidecar-ы в подах Kubernetes. Эти sidecar-ы — контейнеры Envoy, которые читают конфигурацию из Istio Pilot API (и сервиса gRPC) и маршрутизируют по ней трафик. С мощным прокси L7 под капотом мы можем использовать метрики, трассировки, логику повтора, размыкатель цепи, балансировку нагрузки и канареечные деплои.
Начнем с начала: Kubernetes
В Kubernetes мы создаем под c помощью деплоя или StatefulSet. Или это может быть просто «ванильный» под без контроллера высокого уровня. Затем Kubernetes изо всех сил поддерживает желаемое состояние — создает поды в кластере на ноде, следит, чтобы они запускались и перезапускались. Когда под создается, Kubernetes проходит по жизненному циклу API, убеждается, что каждый шаг будет успешным, и только потом наконец создает под на кластере.
Этапы жизненного цикла API:
Спасибо Banzai Cloud за крутую картинку.
Один из этапов — модифицирующие вебхуки допуска. Это отдельная часть жизненного цикла в Kubernetes, где ресурсы кастомизируются до коммита в хранилище etcd — источнике истины для конфигурации Kubernetes. И здесь Istio творит свою магию.
Модифицирующие вебхуки допуска
Когда под создается (через kubectl или Deployment ), он проходит через этот жизненный цикл, и модифицирующие вебхуки доступа меняют его, прежде чем выпустить в большой мир.
Во время установки Istio добавляется istio-sidecar-injector как ресурс конфигурации модифицирующих вебхуков:
Sidecar-поды
Sidecar-ы — это трюки нашего фокусника Istio. Istio так ловко все проворачивает, что со стороны это прямо магия, если не знать деталей. А знать их полезно, если вдруг надо отладить сетевые запросы.
Init- и прокси-контейнеры
В Kubernetes есть временные одноразовые init-контейнеры, которые можно запускать до основных. Они объединяют ресурсы, переносят базы данных или, как в случае с Istio, настраивают правила сети.
@jimmysongio нарисовал отличную схему связи между правилами iptables и прокси Envoy:
Envoy получает весь входящий и весь исходящий трафик, поэтому весь трафик вообще перемещается внутри Envoy, как на схеме. Прокси Istio — это еще один контейнер, который добавляется во все поды, изменяемые sidecar-инжектором Istio. В этом контейнере запускается процесс Envoy, который получает весь трафик пода (за некоторым исключением, вроде трафика из вашего кластера Kubernetes).
Процесс Envoy обнаруживает все маршруты через Envoy v2 API, который реализует Istio.
Envoy и Pilot
У самого Envoy нет никакой логики, чтобы обнаруживать поды и сервисы в кластере. Это плоскость данных и ей нужна плоскость контроля, чтобы руководить. Параметр конфигурации Envoy запрашивает хост или порт сервиса, чтобы получить эту конфигурацию через gRPC API. Istio, через свой сервис Pilot, выполняет требования для gRPC API. Envoy подключается к этому API на основе sidecar-конфигурации, внедренной через модифицирующий вебхук. В API есть все правила трафика, которые нужны Envoy для обнаружения и маршрутизации для кластера. Это и есть service mesh.
Обмен данными «под Pilot»
Pilot подключается к кластеру Kubernetes, читает состояние кластера и ждет обновлений. Он следит за подами, сервисами и конечными точками в кластере Kubernetes, чтобы потом дать нужную конфигурацию всем sidecar-ам Envoy, подключенным к Pilot. Это мост между Kubernetes и Envoy.
Из Pilot в Kubernetes
Когда в Kubernetes создаются или обновляются поды, сервисы или конечные точки, Pilot узнает об этом и отправляет нужную конфигурацию всем подключенным экземплярам Envoy.
Какая конфигурация отправляется?
Какую конфигурацию получает Envoy от Istio Pilot?
По умолчанию Kubernetes решает ваши сетевые вопросы с помощью sevice (сервис), который управляет endpoint (конечные точки). Список конечных точек можно открыть командой:
Это список всех IP и портов в кластере и их адресатов (обычно это поды, созданные из деплоя). Istio важно это знать, чтобы настраивать и отправлять данные о маршрутах в Envoy.
Сервисы, прослушиватели и маршруты
Когда вы создаете сервис в кластере Kubernetes, вы включаете ярлыки, по которым будут выбраны все подходящие поды. Когда вы отправляете трафик на IP сервиса, Kubernetes выбирает под для этого трафика. Например, команда
Istio и Envoy слегка меняют эту логику. Istio настраивает Envoy на основе сервисов и конечных точек в кластере Kubernetes и использует умные функции маршрутизации и балансировки нагрузки Envoy, чтобы обойти сервис Kubernetes. Вместо проксирования по одному IP Envoy подключается прямо к IP пода. Для этого Istio сопоставляет конфигурацию Kubernetes с конфигурацией Envoy.
Термины Kubernetes, Istio и Envoy немного отличаются, и не сразу понятно, что с чем едят.
Сервисы
Все те же сервисы есть в этом пространстве имен:
Как Istio узнает, какой протокол использует сервис? Настраивает протоколы для манифестов сервисов по полю name в записи порта.
Если использовать kubectl и админскую страницу переадресации портов в Envoy, видно, что конечные точки account-grpc-public реализуются Pilot как кластер в Envoy с протоколом HTTP2. Это подтверждает наши предположения:
Порт 15000 — это админская страница Envoy, доступная в каждом sidecar.
Прослушиватели
Прослушиватели узнают конечные точки Kubernetes, чтобы пропускать трафик в поды. У сервиса проверки адреса здесь одна конечная точка:
Поэтому у пода проверки адреса один прослушиватель на порте 50051:
Маршруты
В Namely мы используем Istio Ingress-Gateway для всего внутреннего GRPC-трафика:
Если переадресовать порт пода Istio-IngressGateway и посмотреть конфигурацию Envoy, мы увидим, что делает VirtualService:
Что мы гуглили, копаясь в Istio
Возникает ошибка 503 или 404
Причины разные, но обычно такие:
Что означает NR/UH/UF в логах прокси Istio?
По поводу высокой доступности с Istio
Почему Cronjob не завершается?
Когда основная рабочая нагрузка выполнена, sidecar-контейнер продолжает работать. Чтобы обойти проблему, отключите sidecar в cronjobs, добавив аннотацию sidecar.istio.io/inject: “false” в PodSpec.
Как установить Istio?
Спасибо Bobby Tables и Michael Hamrah за помощь в написании поста.
Серия постов по Istio Service Mesh
Мы начинаем серию постов, в которой продемонстрируем некоторые из множества возможностей сервисной сетки Istio Service Mesh в сочетании с Red Hat OpenShift и Kubernetes.
Часть первая, сегодняшняя:
Инструментарий мониторинга и управления 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 для микросервисов
Серия статей по сервисным сеткам и 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 работает по умолчанию:
Взвешенное распределение между версиями
Игнор версии с помощью 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? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.