Service mesh — выделенный сетевой слой, работающий поверх Kubernetes или другой оркестрации, автоматически перехватывающий трафик между сервисами через sidecar-proxy (обычно Envoy). Даёт «бесплатно», без изменений в коде приложения: mTLS между сервисами, retry с exponential backoff, circuit-breaker, canary/traffic-splitting, distributed tracing, rate-limiting, observability.
Как это работает: рядом с каждым pod'ом (или прямо в pod'e sidecar-контейнером) запускается прокси. iptables-правило перехватывает исходящий трафик приложения и заворачивает через прокси. Прокси знает, куда слать (через service discovery в K8s), применяет политики (retry / mTLS / rate-limit), передаёт дальше. Приложение думает, что говорит `http://payments:8080` — реально общается со своим локальным Envoy.
Основные реализации: Istio — самый функциональный, но сложный (control plane тяжёлый). Linkerd — легковеснее, безопаснее по умолчанию, написан на Rust. Consul Connect — от HashiCorp, интегрируется с их стеком. Cilium (eBPF-based) — вместо sidecar использует ядро Linux через eBPF, самый эффективный.
Когда нужен: 20+ микросервисов, требования compliance (mTLS между всеми сервисами), нужен canary/blue-green без in-code переключений, нужна единая observability. Когда НЕ нужен: 3-5 сервисов, монолит + микросервис, resource-constrained окружение — mesh даёт overhead 5-15 % на латенси и 100-200 МБ RAM на sidecar.