Когда монолит распадается на десятки микросервисов, сетевое взаимодействие между ними становится главным источником боли. Запросы ходят по внутренней сети, сервисы переживают перезапуски и переезды между узлами Kubernetes, а команда хочет понимать, кто кого вызывает и почему растёт задержка. Писать логику повторных попыток, таймаутов, шифрования и трассировки в каждом сервисе – путь к дублированию кода и расхождениям между командами. Service mesh решает эту задачу инфраструктурно: выносит управление трафиком из приложения в отдельный сетевой слой.

Что такое service mesh и где здесь Istio

Service mesh – это слой инфраструктуры, который перехватывает весь трафик между сервисами через прокси-сайдкары. Рядом с каждым экземпляром сервиса разворачивается прокси (в Istio это Envoy), и приложение больше не общается с сетью напрямую – оно общается с локальным прокси. Сами сервисы при этом не меняются: им не нужно знать про балансировку, mTLS или сбор метрик.

Istio, вышедший в стабильной версии 1.1 этой весной, разделяет mesh на две части. Data plane – это набор сайдкаров Envoy, которые гоняют трафик. Control plane (Pilot, Mixer, Citadel) задаёт правила маршрутизации, собирает телеметрию и управляет сертификатами. Вы описываете поведение декларативно через ресурсы Kubernetes – VirtualService и DestinationRule, – а Istio транслирует их в конфигурацию прокси.

Управление трафиком на практике

Главная ценность для бизнеса – контроль над тем, как именно запросы доходят до сервисов. Несколько сценариев, которые мы применяем у заказчиков:

  • Канареечные релизы. Направляем 5% трафика на новую версию, следим за ошибками и задержкой, затем плавно повышаем долю. Откат – это изменение одной цифры в правиле, а не повторный деплой.
  • A/B-маршрутизация по заголовкам. Запросы с определённым заголовком или из конкретного сегмента идут на отдельную версию сервиса. Удобно для пилотов в госсекторе, где новую функцию сначала проверяют на ограниченном круге пользователей.
  • Устойчивость к сбоям. Таймауты, повторы, circuit breaking и инъекция отказов настраиваются централизованно. Команда тестирует поведение системы при деградации зависимостей, не трогая код.

Отдельно стоит безопасность. Istio включает взаимный TLS между сервисами, и трафик внутри кластера шифруется автоматически. Это снимает часть вопросов при обработке персональных данных – тема, которую мы разбирали в материале про 152-ФЗ и эхо GDPR. Для систем, попадающих в реестр объектов КИИ, прозрачная политика доступа между компонентами и журналирование вызовов упрощают аттестацию.

Когда mesh оправдан, а когда избыточен

Service mesh – не бесплатный. Сайдкары добавляют задержку и потребляют память, а control plane требует сопровождения. На трёх-четырёх сервисах овчинка не стоит выделки: проще обойтись библиотекой и API-шлюзом. Mesh окупается, когда сервисов десятки, над ними работает несколько команд, а требования к наблюдаемости и безопасности высокие.

Не стоит и подменять mesh-ом инструменты разработки. Для быстрой сборки внутренних приложений эффективнее low-code-платформы – а service mesh берёт на себя эксплуатацию того, что уже работает в продакшене под нагрузкой.

Вывод

Istio переносит управление трафиком, безопасностью и наблюдаемостью с уровня приложения на уровень инфраструктуры. Это даёт командам единые правила, безопасные релизы и понятную картину сетевых вызовов – ценой дополнительной сложности эксплуатации. Внедрять mesh стоит осознанно, под реальный масштаб, проектируя сетевой слой вместе с остальной инфраструктурой ещё до выхода в продакшен.