Что такое service mesh: Istio, Linkerd и когда он действительно нужен

Что такое service mesh

В микросервисной системе сервисы постоянно вызывают друг друга. Каждому вызову нужны шифрование, таймауты, ретраи, метрики и правила доступа. Без mesh каждая команда реализует это в своём коде и библиотеках, на каждом языке по-своему.

Service mesh выносит эту логику в инфраструктуру. Он состоит из двух частей:

• Data plane — прокси, которые стоят на пути каждого запроса между сервисами и применяют правила.
• Control plane — компонент, который настраивает все эти прокси, выпускает сертификаты и превращает вашу конфигурацию в их настройки.

Приложение делает обычный HTTP- или gRPC-вызов. Как этот вызов защитить, куда направить и как измерить — решает mesh.

Sidecar и sidecarless

Модель sidecar. Рядом с каждым контейнером приложения в том же поде Kubernetes работает контейнер-прокси. Весь входящий и исходящий трафик пода идёт через него.

[Pod A: app | proxy] ---mTLS---> [Pod B: proxy | app]

• Плюсы: точный контроль для каждого сервиса, зрелая и понятная модель.
• Минусы: лишний контейнер в каждом поде, больше памяти и CPU в сумме, обновление часто требует перезапуска подов.

Модель sidecarless. Вместо прокси в каждом поде общий компонент на ноде обеспечивает базовый зашифрованный транспорт, а более тяжёлые прокси для продвинутых HTTP-функций подключаются только там, где нужны. Так устроен ambient mode в Istio; некоторые mesh также используют eBPF в ядре.

• Плюсы: меньше накладных расходов, не нужно перезапускать поды при подключении.
• Минусы: подход новее, меньше опыта в продакшене, другая модель изоляции и отказов.

Что даёт mesh

• mTLS между сервисами: каждое соединение зашифровано, обе стороны подтверждают свою личность сертификатами, которые mesh выпускает и ротирует сам.
• Политики авторизации: «только orders может вызывать payments» — по идентичности сервиса, а не по IP.
• Ретраи и таймауты: настраиваются централизованно и одинаково для всех.
• Разделение трафика: часть запросов — на новую версию для canary-релиза или зеркалирование трафика для тестов.
• Circuit breaking и outlier detection: перестать слать запросы в сбоящие экземпляры.
• Телеметрия: частота запросов, ошибки и задержки для каждой пары сервисов и поддержка распределённой трассировки — базовые метрики без инструментирования кода.

Важно: для трассировки сервисы всё равно должны пробрасывать trace-заголовки. Связать входящий и исходящий вызов внутри вашего процесса mesh сам не может.

Istio и Linkerd

Оба проекта входят в CNCF и используются в продакшене. Перед выбором проверьте актуальные условия лицензирования и выпуска релизов — они могут меняться.

Честные критерии: нужен ли он вам

Mesh — это полноценная инфраструктура, которую кто-то должен обновлять, отлаживать и понимать в три часа ночи. Скорее всего, стоит обойтись без него, если:

• У вас несколько сервисов, и ими владеет одна команда.
• Вы не на Kubernetes или некому его уверенно сопровождать.
• Требование звучит как «просто HTTPS внутри кластера» — хватит решения попроще.
• У вас ещё нет базовых метрик, логов и алертов. Начните с них.

Mesh имеет смысл, когда:

• Много сервисов на разных языках требуют единых правил безопасности и надёжности.
• Комплаенс требует шифрования и идентификации всего внутреннего трафика.
• Вы делаете частые canary-релизы и нужен точный контроль трафика.
• Есть платформенная команда, которая будет им владеть.

Альтернативы для небольших команд: API gateway на входе, ретраи и таймауты в общей клиентской библиотеке, network policies в Kubernetes.

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

• Ставить mesh «чтобы было современно», когда нет конкретной проблемы.
• Двойные ретраи: ретраи и в приложении, и в mesh умножают нагрузку во время инцидента.
• Включать строгий mTLS одним шагом и ломать сервисы, которые ещё не в mesh. Сначала используйте permissive-режим.
• Не задавать лимиты ресурсов прокси и удивляться счёту за кластер.