# Service mesh

> Инфраструктурный слой для связи микросервисов — шифрование mTLS, маршрутизация, повторы, метрики и трассировка без изменения кода; примеры — Istio, Linkerd, Cilium.

Источник: https://llmdocs.ru/wiki/service-mesh/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Назначение**: управление трафиком между сервисами
- **Архитектура**: data plane (прокси) + control plane
- **Прокси**: Envoy, linkerd2-proxy (Rust), eBPF
- **Реализации**: Istio, Linkerd, Cilium Service Mesh, Consul, Kuma
- **Режимы**: sidecar, sidecarless (ambient, eBPF)
- **Стандарты**: Gateway API (GAMMA), SPIFFE
**Service mesh** (сервисная сетка) — отдельный инфраструктурный слой, через который проходит весь сетевой трафик между сервисами приложения. Сетка берёт на себя то, что иначе пришлось бы реализовать в каждом сервисе: взаимное шифрование и аутентификацию ([mTLS](https://llmdocs.ru/wiki/tls.md)), повторы и тайм-ауты, [балансировку](https://llmdocs.ru/wiki/load-balancing.md), постепенный перевод трафика на новую версию, метрики и распределённую трассировку. Код приложения при этом не меняется. Чаще всего service mesh разворачивают поверх [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md).

## Зачем

В монолите вызов другого модуля — вызов функции. В микросервисной архитектуре это сетевой запрос, который может потеряться, зависнуть или прийти от злоумышленника. Компании вроде Twitter и Netflix в 2010-х решали это библиотеками (Finagle, Hystrix), но библиотеки привязаны к языку и требуют обновления всех сервисов. Service mesh выносит эти функции из процесса в прокси рядом с ним — так подход стал независимым от языка.[1]

## Архитектура

| Плоскость | Что делает | Примеры |
|---|---|---|
| **Data plane** | прокси, через которые идёт трафик: шифрование, маршрутизация, сбор метрик | Envoy, linkerd2-proxy, ztunnel |
| **Control plane** | раздаёт прокси конфигурацию и сертификаты, следит за сервисами | istiod, Linkerd control plane |

Классическая схема — **сайдкар**: в каждый [Pod](https://llmdocs.ru/wiki/pod.md) автоматически добавляется контейнер-прокси, а правила iptables перенаправляют через него весь входящий и исходящий трафик. Прокси двух сервисов устанавливают между собой mTLS-соединение, проверяя криптографическую идентичность друг друга — обычно в формате SPIFFE (`spiffe://cluster.local/ns/shop/sa/payments`).[6]

Сайдкары расходуют память и процессор на каждом поде и усложняют обновления, поэтому появились **режимы без сайдкаров**: Istio ambient mode использует общий L4-прокси на узле (ztunnel) и необязательные L7-прокси на пространство имён,[2] а Cilium реализует часть функций в ядре через eBPF (см. [Сетевые плагины (CNI)](https://llmdocs.ru/wiki/cni.md)).

## Возможности

- **Безопасность.** Автоматический mTLS между всеми сервисами без ручного управления сертификатами; политики авторизации «сервис A может вызывать `GET /orders` у сервиса B». Это основа модели нулевого доверия (zero trust).
- **Управление трафиком.** Канареечные релизы (5% трафика на новую версию), маршрутизация по заголовкам, зеркалирование трафика, внесение задержек и ошибок для тестирования устойчивости.
- **Надёжность.** Тайм-ауты, повторы с ограничением, автоматический выключатель (circuit breaker), исключение неисправных экземпляров.
- **Наблюдаемость.** «Золотые сигналы» — частота запросов, ошибки, задержки — для каждой пары сервисов без изменения кода; экспорт в [Prometheus](https://llmdocs.ru/wiki/prometheus.md) и трассировку через [OpenTelemetry](https://llmdocs.ru/wiki/opentelemetry.md).

## Реализации

- **Istio** — самая функциональная сетка (Google, IBM, Lyft), прокси Envoy, режимы sidecar и ambient. Выпускник CNCF.
- **Linkerd** — упор на простоту и производительность: собственный лёгкий прокси на Rust, mTLS включён по умолчанию.[3]
- **Cilium Service Mesh** — на базе eBPF и Envoy, совмещён с CNI.
- **Consul** (HashiCorp) и **Kuma** — работают также вне Kubernetes, на виртуальных машинах.

Прокси **Envoy**, созданный в Lyft, стал фактическим стандартом data plane и используется также в API-шлюзах и ingress-контроллерах.[4]

## Пример: канареечный релиз в Istio

```yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
    - route:
        - destination: {host: reviews, subset: v1}
          weight: 90
        - destination: {host: reviews, subset: v2}
          weight: 10
```

Инициатива **GAMMA** переносит такие правила на стандартные ресурсы Gateway API (`HTTPRoute`), чтобы конфигурация не зависела от конкретной сетки.[5] Gateway API — развитие [Ingress](https://llmdocs.ru/wiki/service-ingress.md).

## Когда нужен

Service mesh добавляет движущиеся части: control plane, прокси, сертификаты, новый слой для отладки. Он оправдан, когда сервисов десятки, требуется обязательный mTLS (регуляторика, zero trust) или нужны единые метрики и канареечные релизы для всех команд. Для нескольких сервисов обычно достаточно ingress-контроллера, сетевых политик CNI и библиотек трассировки в коде. Начинать разумно с минимального набора — mTLS и метрики — и включать сложную маршрутизацию по мере необходимости.

## См. также

- [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md)
- [Service и Ingress](https://llmdocs.ru/wiki/service-ingress.md)
- [Сетевые плагины (CNI)](https://llmdocs.ru/wiki/cni.md)
- [Мониторинг и алертинг](https://llmdocs.ru/wiki/monitoring-alerting.md)

## Источники

1. [Istio — What is a service mesh](https://istio.io/latest/about/service-mesh/)
2. [Istio — Ambient mode overview](https://istio.io/latest/docs/ambient/overview/)
3. [Linkerd — Documentation](https://linkerd.io/2/overview/)
4. [Envoy proxy — What is Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy)
5. [Kubernetes Gateway API — GAMMA initiative](https://gateway-api.sigs.k8s.io/mesh/gamma/)
6. [SPIFFE — Secure Production Identity Framework for Everyone](https://spiffe.io/docs/latest/spiffe-about/overview/)