2learn

Istio

Что это такое

Istio — это сервисная сетка (service mesh): набор прокси, по одному рядом с каждой рабочей нагрузкой, которые несут трафик между сервисами и применяют к нему политику. Приложения общаются друг с другом как раньше, но прокси между ними может маршрутизировать, повторять, ограничивать по времени, шифровать и измерять каждый вызов. Он забирает заботы, которые иначе были бы размазаны по коду приложений и библиотекам, и переносит их в платформу.

Почему это важно

Когда система состоит из многих сервисов, у нескольких задач пропадает хороший ответ внутри приложения: как отправить небольшую долю трафика на новую версию, как зашифровать трафик между сервисами, не меняя каждый из них, как повторить неудавшийся вызов, не повторяя платёж. Сетка отвечает на это единообразно и централизованно, причём для сервисов, написанных на разных языках. Цена — прокси на каждом пути запроса, новый управляющий слой в эксплуатации и опыт отладки, который теперь включает слой, не написанный командой приложения. Это большая цена, и платить её стоит только тогда, когда у многих сервисов одна и та же потребность.

Ключевые идеи

Трафик несёт sidecar-прокси

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

сервис A -> [прокси] --mTLS--> [прокси] -> сервис B
             настраивается централизованно: маршруты, повторы, тайм-ауты, метрики

Разделение трафика делает постепенный выпуск лёгким, а откат — тривиальным

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

Взаимный TLS появляется без правки кода

Шифрование и взаимная аутентификация вызовов между сервисами обычно означает правку каждого сервиса и раздачу сертификатов каждому. Сетка выдаёт идентичности прокси и шифрует между ними, поэтому сервис может требовать, чтобы вызывающие предъявляли действительную идентичность, даже если сам сервис ничего не знает про TLS. Жизненный цикл сертификатов — забота управляющего слоя.

Каждый переход добавляет задержку и новый режим отказа

Добавление прокси добавляет переход, а управляющий слой — зависимость: когда он недоступен, изменения конфигурации перестают применяться, и поведение сетки становится тем, что прокси знали в последний раз. Повторы, настроенные в сетке, могут ещё и усилить нагрузку, превращая борющийся сервис в перегруженный. Это обычные издержки распределённых систем, но они приходят сразу и на пути запроса.

Политика и наблюдаемость достаются бесплатно, когда прокси уже стоят

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

Внедряйте, когда потребность общая, а не ради одного сервиса

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

Практика

Разделите трафик между двумя версиями

Разверните две версии сервиса и направьте фиксированную долю запросов на каждую, затем измените долю, ничего не переразвёртывая.

Готово, когда: наблюдаемое число запросов соответствует настроенной доле и изменилось только правило маршрутизации.

Потребуйте идентичность между двумя сервисами

Настройте политику так, чтобы один сервис принимал вызовы только от названной идентичности вызывающего, и убедитесь, что вызов из другого места отклоняется.

Готово, когда: разрешённый вызов проходит, другой отклоняется, и ни одна строка кода приложения не изменена.

Частые ошибки

  • Внедрять сетку ради одного сервиса — операционная цена приходит раньше любой выгоды; исправить: используйте маршрутизацию платформы, пока потребность не разделят несколько сервисов.
  • Добавлять повторы без бюджета — повторы умножают нагрузку на сервис, который и так борется; исправить: ограничьте повторы и сочетайте их с тайм-аутами и размыканием цепи.
  • Забывать, что управляющий слой — это зависимость — при его недоступности конфигурация перестаёт меняться; исправить: следите за ним и знайте, какое поведение деградирует.
  • Отлаживать задержку, не учитывая прокси — лишний переход не виден ни в одной трассировке приложения; исправить: включите сетку в трассировку и на панели.
  • Шифровать внутри сетки и считать, что снаружи всё покрыто — трафик, покидающий сетку, — другая задача; исправить: считайте входной и исходящий трафик отдельными решениями о политике.

Что читать дальше

Разобранные примеры

Файлы cookie аналитики ставятся только с вашего согласия. До вашего выбора ничего не загружается и никуда не отправляется.