DevOps

Service Mesh: Istio, Linkerd

В Lyft в 2018 году было 200+ микросервисов. Команда потратила месяцы, добавляя в каждый сервис retry-логику, TLS и трейсинг вручную. Решение - Envoy и service mesh, который они же и создали. Сегодня тысячи компаний используют Istio или Linkerd чтобы один раз написать политики сети и применить их ко всем сервисам сразу.

**Airbnb** использует Istio для канарейных деплоев: новая версия сервиса получает 1% трафика, автоматически мониторится error rate, и при превышении порога откат происходит без участия инженера
**T-Mobile** внедрил mTLS через Istio и убрал необходимость в VPN для внутренних сервисов - каждый вызов криптографически аутентифицирован, zero-trust на уровне сети
**Booking.com** применяет Kiali для анализа service dependency graph при инцидентах - вместо часов на выяснение 'кто кого вызывает' - живая карта с error rates за 30 секунд

Sidecar

Sidecar - это прокси-контейнер (Envoy в Istio, linkerd-proxy в Linkerd), который автоматически инжектируется в каждый под кластера. Весь входящий и исходящий трафик пода проходит через sidecar - прозрачно, без изменений в коде приложения. Это позволяет добавить TLS, retries, circuit breaker и трейсинг централизованно.

Istio инжектирует Envoy автоматически: достаточно добавить label `istio-injection: enabled` на namespace. Linkerd делает то же самое, но с более лёгким proxy написанным на Rust. Накладные расходы sidecar в продакшне: +2-5ms latency, +50-100MB RAM на под.

Какое главное преимущество sidecar-паттерна в service mesh?

Traffic Management

Istio предоставляет VirtualService и DestinationRule для гибкого управления трафиком. VirtualService определяет правила маршрутизации (canary, A/B тест, header-based routing). DestinationRule настраивает поведение для конкретного сервиса (load balancing, circuit breaker, connection pool).

Типичный production use case: canary deployment. Новая версия получает 5% трафика, постепенно увеличивается до 100% при хороших метриках. Это безопаснее чем rolling update K8s, потому что контроль гранулярный и откат мгновенный - просто изменить weight в VirtualService.

Чем Istio canary deployment лучше стандартного K8s rolling update?

mTLS

Mutual TLS (mTLS) - это взаимная аутентификация: не только клиент проверяет сертификат сервера, но и сервер проверяет сертификат клиента. В Istio каждый sidecar получает X.509-сертификат, подписанный Citadel (встроенный CA). Весь трафик внутри mesh шифруется и каждый вызов несёт криптографическое доказательство идентичности.

Istio поддерживает три режима: `PERMISSIVE` (принимает и HTTP и mTLS - для миграции), `STRICT` (только mTLS - production), `DISABLE` (без шифрования). PeerAuthentication задаёт политику для namespace или конкретного workload. Сертификаты ротируются автоматически каждые 24 часа по умолчанию.

В чём отличие mTLS от обычного TLS?

Observability

Service mesh даёт L7 observability бесплатно: каждый sidecar генерирует метрики, трейсы и access logs для каждого вызова. Istio интегрируется с Prometheus (метрики), Jaeger/Zipkin (трейсинг) и Kiali (визуализация графа сервисов). Это работает без единой строки кода в приложении.

Ключевые метрики из Istio: `istio_request_total` (RPS по сервисам), `istio_request_duration_milliseconds` (latency percentiles), `istio_request_bytes` (объём трафика). Kiali строит живой граф зависимостей сервисов с real-time error rates - незаменимо при расследовании инцидентов.

Service mesh заменяет необходимость в APM-инструментах типа Datadog или New Relic

Service mesh даёт инфраструктурный уровень L7 (HTTP метрики, трейсы между сервисами). APM дополнительно даёт application-level профилирование: медленные SQL-запросы, heap dumps, code-level traces

Истио видит HTTP-вызов как черный ящик - он знает latency и status code, но не знает почему запрос был медленным внутри приложения

Какой главный вклад service mesh в observability по сравнению с ручной инструментацией?

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

**Sidecar** - Envoy прокси инжектируется в каждый под и перехватывает весь трафик без изменения кода приложения
**Traffic Management** - VirtualService и DestinationRule дают гранулярный контроль: canary 5%/95%, A/B тест, header-based routing, circuit breaker
**mTLS + Observability** - взаимная аутентификация всех вызовов и автоматические метрики/трейсы L7 для каждого сервиса без инструментации

Связанные темы

Service mesh работает поверх K8s и тесно связан с мониторингом и безопасностью:

K8s: продвинутые паттерны — Istio устанавливается через Helm и Operator; injection работает на уровне namespace K8s
Distributed Tracing — Istio автоматически создаёт spans для каждого вызова и интегрируется с Jaeger/Zipkin

Вопросы для размышления

Когда service mesh оправдан, а когда он добавляет излишнюю сложность? При каком количестве сервисов стоит задуматься?
Если уже есть OpenTelemetry SDK во всех сервисах - какую дополнительную ценность даст Istio?
Как mTLS в Istio меняет модель сетевой безопасности по сравнению с традиционными firewall правилами?

Связанные уроки