Компьютерные сети
Service Mesh
Netflix имеет 1000+ микросервисов. Как обеспечить mTLS, retry, circuit breaker между всеми? Переписать код каждого сервиса? Service Mesh делает это за тебя - одной настройкой на уровне инфраструктуры.
- **Google** - пионер Service Mesh, внутренний аналог до Istio
- **Lyft** - создатели Envoy proxy, 10000+ RPS через mesh
- **Airbnb** - mTLS между всеми сервисами без изменения кода
Предварительные знания
Service Mesh
**Service Mesh** - это выделенный инфраструктурный слой для управления коммуникацией между микросервисами. Вместо того чтобы каждый сервис сам реализовывал retry, timeout, circuit breaker, mTLS - эту логику выносят в отдельный слой.
Представь: у тебя 50 микросервисов на разных языках (Go, Python, Java, Node.js). Нужно добавить взаимную аутентификацию между всеми сервисами. Без Service Mesh - переписывать код каждого сервиса. С Service Mesh - одна настройка на уровне инфраструктуры.
**Главная идея:** Сетевая логика (security, observability, traffic management) выносится из кода приложений в инфраструктуру. Приложения знают только о бизнес-логике.
**Что даёт Service Mesh:** • **Traffic Management** - canary deployments, A/B testing, traffic splitting • **Security** - mTLS между всеми сервисами, политики доступа • **Observability** - метрики, трейсы, логи без изменения кода • **Resilience** - retry, timeout, circuit breaker на уровне инфраструктуры
Какую проблему решает Service Mesh?
Sidecar Proxy
**Sidecar Proxy** - это прокси-контейнер, который запускается рядом с каждым сервисом в поде. Весь входящий и исходящий трафик проходит через этот прокси. Самый популярный sidecar - **Envoy Proxy**, созданный в Lyft.
Название "sidecar" (коляска мотоцикла) отражает архитектуру: прокси едет рядом с основным контейнером, разделяя с ним сетевой namespace, но будучи отдельным процессом.
**Как перехватывается трафик?** При инъекции sidecar в под добавляются iptables правила. Весь трафик на порты приложения перенаправляется через Envoy. Приложение не знает о прокси - для него всё прозрачно.
**Преимущества Envoy:** • **L7 awareness** - понимает HTTP/2, gRPC, WebSocket • **Hot reload** - конфигурация обновляется без перезапуска • **xDS API** - динамическое обнаружение endpoints, routes, clusters • **Расширяемость** - Lua, WASM filters
Как sidecar proxy перехватывает трафик приложения?
Istio
**Istio** - самый популярный Service Mesh, разработанный Google, IBM и Lyft. Состоит из **Control Plane** (управление) и **Data Plane** (Envoy sidecar'ы).
**istiod** - единый бинарник Control Plane (с версии 1.5). Раньше Pilot, Citadel, Galley были отдельными компонентами. Унификация упростила деплой и отладку.
**Альтернативы Istio:** • **Linkerd** - проще, легче, написан на Rust (прокси) + Go • **Consul Connect** - от HashiCorp, интеграция с Consul • **Cilium** - eBPF-based, без sidecar (в Kubernetes 1.29+)
Какой компонент Istio отвечает за распространение конфигурации в Envoy sidecar'ы?
mTLS
**mTLS (mutual TLS)** - взаимная аутентификация, где обе стороны (клиент и сервер) предъявляют сертификаты. В обычном TLS (HTTPS) только сервер показывает сертификат. В mTLS клиент тоже доказывает свою идентичность.
**Zero Trust + mTLS:** В Service Mesh каждый сервис имеет уникальную идентичность (SPIFFE ID). Даже если злоумышленник проник в кластер, он не сможет выдать себя за другой сервис без валидного сертификата.
**SPIFFE (Secure Production Identity Framework For Everyone):** • Стандарт идентификации workloads • Формат: `spiffe://trust-domain/path` • Пример: `spiffe://cluster.local/ns/prod/sa/frontend` • Istio Citadel выдаёт SVID (SPIFFE Verifiable Identity Document) каждому поду
Чем mTLS отличается от обычного TLS?
Observability
**Observability** в Service Mesh - это автоматический сбор метрик, трейсов и логов без изменения кода приложений. Envoy sidecar видит весь трафик и может собирать богатую телеметрию.
**Три столпа Observability:** • **Metrics** - количественные измерения (latency, RPS, error rate) • **Traces** - путь запроса через все сервисы • **Logs** - детальные события
**Context Propagation:** Для связывания spans в единый trace используются заголовки: `x-request-id`, `x-b3-traceid`, `traceparent` (W3C). Envoy автоматически пробрасывает эти заголовки.
**Инструменты observability в Service Mesh:** • **Kiali** - визуализация топологии mesh, health status • **Jaeger/Zipkin** - distributed tracing • **Prometheus + Grafana** - метрики и dashboards • **Envoy Access Logs** - детальные логи каждого запроса
Service Mesh нужен всем микросервисным приложениям
Service Mesh добавляет значительный overhead (latency, ресурсы). Для простых систем достаточно Kubernetes Services
Каждый запрос проходит через два Envoy (источник и назначение) - это +2-5ms latency. Оправдано при 50+ сервисах, сложных требованиях к безопасности или observability. Для 5-10 сервисов - часто избыточно
Как Service Mesh собирает distributed traces без изменения кода приложений?
Итоги
- **Service Mesh** выносит сетевую логику (retry, mTLS, observability) из приложений в инфраструктуру
- **Sidecar Proxy (Envoy)** перехватывает весь трафик через iptables прозрачно для приложения
- **Istio** = Control Plane (istiod) + Data Plane (Envoy sidecars)
- **mTLS** обеспечивает взаимную аутентификацию сервисов с SPIFFE идентичностью
- **Observability** - метрики, трейсы, логи собираются автоматически без изменения кода
Связанные темы
Service Mesh строится поверх Kubernetes networking и реализует Zero Trust:
- Kubernetes Networking — Service Mesh работает поверх CNI и Services
- Zero Trust — mTLS и AuthorizationPolicy реализуют Zero Trust принципы
Вопросы для размышления
- При каком количестве микросервисов Service Mesh начинает оправдывать свой overhead?
- Как бы ты организовал постепенную миграцию на mTLS в production кластере?
- Какие метрики из Service Mesh были бы наиболее полезны для твоей команды?