Service Mesh

«Поставим service mesh, и mTLS / retry / трассировка будут из коробки» — позиция, после которой я регулярно вижу команды, для которых mesh становится новой single point of failure: control plane унаследовал недоступность, sidecar в каждом pod’е добавил 200 мс к startup, а инцидент диагностируется через два слоя логов (приложение + Envoy). Service mesh — мощный инструмент, но это инфраструктурный слой, который нужно эксплуатировать с тем же уровнем зрелости, что и Kubernetes (см. Containerization & Orchestration). Этот лист — про то, когда mesh оправдан, как он устроен, и какие компромиссы реальны на production.

Граница: Networking — про сетевой стек как медиум (TCP, TLS, HTTP); этот лист — про L7-overlay поверх pod-to-pod трафика. Resilience Patterns — про сами паттерны (retry, circuit breaker, timeout); mesh — одна из инфра-реализаций. Workload Identity — пересечение через mTLS как замену shared secrets.

Что должен уметь

Главный навык на уровне L5 — честно отвечать на вопрос «нужен ли нам mesh». По моим наблюдениям, в большинстве команд (до сотни сервисов, один регион, нет жёстких compliance-требований на mTLS) ответ «нет, пока». Mesh выигрывает, когда: (1) нужен mTLS между всеми сервисами как compliance baseline; (2) много языков/фреймворков, и стандартизировать retries/timeouts/tracing в коде дороже, чем поднять sidecar; (3) сложные сценарии traffic shifting (canary, A/B, mirror) — а не один-два, которые покрываются ingress controller’ом. Команда, которая сначала задаёт эти вопросы и потом ставит mesh, эксплуатирует его осознанно; команда, которая ставит «потому что Istio в каждом докладе» — добавляет операционный долг.

Понимает архитектуру mesh: data plane (sidecar proxy, обычно Envoy) + control plane (Istio / Linkerd / Consul Connect). Знает, что sidecar инжектится через mutating admission webhook и перехватывает трафик через iptables.
Различает три core-функции mesh: mTLS (взаимная аутентификация сервисов), traffic management (routing, retry, timeout), observability (RED-метрики, distributed tracing, access logs). Понимает, что эти три можно получать раздельно (cert-manager + retries в коде + OpenTelemetry SDK) — mesh упаковывает их в один пакет.
Дебажит mesh-инцидент: istioctl proxy-status / istioctl proxy-config, Envoy admin endpoint (localhost:15000/clusters, /listeners, /stats), логи sidecar через kubectl logs -c istio-proxy. Знает, что 503 от mesh ≠ 503 от приложения.

Оценивает overhead: latency (+1–5 мс на hop через sidecar), CPU/memory footprint sidecar (50–200 МБ memory на pod при дефолтах), startup time. Делает осознанный выбор «mesh за это платит».
Различает Istio vs Linkerd vs eBPF-based решения (Cilium Service Mesh, Ambient Mesh): trade-offs по сложности control plane, footprint, feature-set. По моим наблюдениям, Linkerd чаще выбирают за «делает три вещи хорошо», Istio — за богатство фич, ambient/eBPF — за «без sidecar в каждом pod».
Управляет mesh upgrade strategy: canary control plane, ревизии Istio (istio-injection=disabled + istio.io/rev), параллельное существование двух версий control plane.
Понимает security model: mTLS cert rotation cadence, root-of-trust (внешний CA vs Istio’s built-in), AuthorizationPolicy / PeerAuthentication как RBAC-эквивалент на L7.

L6+

Решает «mesh или нет» для конкретной системы: формулирует критерии «когда оправдан» в ADR, готов аргументировать «пока без него» так же убедительно, как «давайте поставим».
Готов к incident’ам уровня «mesh лёг»: rollback control plane, disable injection через namespace label, fallback на direct pod-to-pod трафик. Имеет runbook на «mesh control plane unhealthy».

Материалы

Книги

Lee Calcote, Nic Jackson — Istio: Up and Running (O’Reilly, 2019). Немного устарела по конкретным API, но архитектурный фундамент Istio описан правильно. Главы про data plane / Envoy — best part.
William Morgan et al. — The Linkerd Book (Buoyant, online, 2024+). Бесплатно. Концептуально чище Istio’шной документации; читается за выходные.

Статьи и доклады

William Morgan (Buoyant CEO) — The Service Mesh: What Every Software Engineer Needs to Know About the World’s Most Over-Hyped Technology. По моим наблюдениям, лучший публичный текст про то, что такое mesh и что НЕ такое. Manifesto-style, читается за полчаса.
Istio — What is a service mesh?. Каноническое определение «изнутри проекта». Полезно для базовых терминов, но смотреть критически — Istio объяснит, почему mesh всегда полезен.
Matt Klein (Envoy author) — Service Mesh Data Plane vs. Control Plane. Короткая статья от автора Envoy про разделение data/control plane — концепт, без которого mesh-дискуссия превращается в магию.
Cindy Sridharan — The Mythical Service Mesh. Контраргумент к «mesh решает всё»; полезно читать до выбора mesh.
Buoyant — Performance Benchmarks: Linkerd vs Istio. Старо, но методология честная — измерять latency overhead под realistic load, а не на «hello world».
Lyft Envoy origin story (Matt Klein, KubeCon 2018) — публичный case study, как родился Envoy — см. ниже.

Инструменты

Envoy — индустриальный стандарт data plane. По моим наблюдениям, в 2026 ~80% mesh-инсталляций используют Envoy так или иначе (через Istio, Consul Connect, кастомные сборки).
Istio — самый feature-rich control plane. Подходит, когда нужно «всё»: mTLS + traffic management + multi-cluster + extensible policy. Цена — сложность операций.
Linkerd — alternative с фокусом «делает три вещи хорошо». Свой data plane (linkerd2-proxy на Rust), меньше footprint, проще операции. По моим наблюдениям, чаще выбирают, когда команда хочет mesh без штатного «mesh-engineer».
Cilium Service Mesh / Istio Ambient Mesh — sidecar-less подход (eBPF / per-node proxy). На 2026 — emerging, ещё не «boring choice». Перспективно, но смотреть на production-readiness в context’е конкретной задачи.
Consul Connect — mesh от HashiCorp, integrated с Consul service discovery. Выбор, когда уже есть Consul-стек.
Kiali — UI для Istio: service graph, traffic flow, configuration validation. По моим наблюдениям, единственный mesh-debugger, который не открывает Envoy admin вручную.
istioctl analyze / linkerd check — sanity-check tools от самих проектов. Запускать перед каждым upgrade.

Best practices

Хороший публичный кейс «откуда взялся mesh» — Lyft Envoy origin story (2015–2016). Команда столкнулась с polyglot-микросервисной средой: Python, Go, Java, Node.js — каждый со своим HTTP-клиентом, своими retries/timeouts/circuit breakers, своими метриками. Любое изменение в network policy требовало релизов всех сервисов. Решение — выделить network logic в out-of-process proxy (Envoy), который sidecar’ом запускается рядом с каждым приложением. Это и есть data plane современного mesh; всё, что сверху (Istio, Linkerd, Consul Connect), — control plane’ы для оркестрации этого слоя. Я регулярно ссылаюсь на этот контекст для команд, которые думают про mesh: если у вас три сервиса на одном языке — Envoy/mesh решает проблему, которой у вас нет. Если у вас 50 сервисов на пяти языках и retries реализованы по-разному в каждом — стоит считать ROI mesh всерьёз.

Короткие правила:

Mesh не отменяет retries/timeouts в коде, он их дублирует. «У нас mesh, ретраи он сделает» — антипаттерн. Mesh ретраит на сетевом уровне (HTTP-метод + status code), приложение ретраит на бизнес-уровне (idempotency, dedup, eventual consistency). Двойные ретраи без согласования — retry storm. Правильно: одно место принимает решение «retry или нет», второе — passes through. Чаще mesh делает только timeout + circuit break, а retry остаётся в коде (где знают бизнес-семантику).
mTLS — это не «free security», это новый failure mode. Cert rotation, key compromise, trust chain misconfiguration — каждое из этого может положить mesh-трафик за секунды. Иметь runbook «mTLS broken across mesh» — обязательно. Видимость состояния сертификатов через alerting (TTL countdown, rotation failures) — на том же уровне, что мониторинг TLS-сертов на ingress’е.
Sidecar resource overhead — это network tax, который платит каждый pod. 200 МБ memory на sidecar × 100 pod = 20 ГБ только под mesh. На малых нагрузках незаметно, на больших — половина capacity planning. Перед production rollout — измерять footprint на realistic workload, не «hello world».

Подробнее:

«Pilot для mesh» — отдельный класс инцидентов. Я регулярно вижу команды, у которых mesh control plane unhealthy не покрыт alerting’ом — потому что «mesh же абстракция, она работает». Когда istiod падает, sidecar’ы продолжают работать на cached config какое-то время, потом начинают отказывать в неочевидных местах. Healthy ops-model: mesh control plane мониторится так же тщательно, как kube-apiserver — uptime, latency push’ей конфигурации, версии конфига на data plane. Без этого инциденты mesh диагностируются по принципу «странно работает всё одновременно».

Один mesh на кластер — не три «потому что разные команды». «Безопасность хочет Istio, observability хочет Linkerd, у нас обоих» — путь к incompatible sidecar injection и невоспроизводимым багам. По моим наблюдениям, healthy approach: один mesh на кластер, выбранный после ADR. Если разные команды хотят разное — это разговор «давайте обсудим критерии», а не «давайте поставим оба».

Traffic shifting через mesh ≠ progressive delivery. Часто слышу «у нас canary через Istio»: 90% трафика на v1, 10% на v2, mesh сделает routing. Это traffic shifting — не progressive delivery. Progressive delivery (см. Progressive Delivery) включает автоматический rollback по SLI-нарушению, не только routing. Mesh даёт mechanism (routing rules); policy (когда катить дальше, когда откатывать) — отдельный слой. Flagger / Argo Rollouts соединяют эти два.

Ambient/sidecar-less mesh — на 2026 это «watching, not adopting» для большинства. Cilium Service Mesh, Istio Ambient — направления, в которых индустрия движется (избавиться от sidecar в каждом pod в пользу per-node proxy через eBPF). Концептуально привлекательно: меньше footprint, проще upgrade, нет sidecar startup-tax. Реально на 2026 — feature-parity с sidecar-mode не везде, production case studies ограниченные. По моим наблюдениям, для большинства команд healthy позиция — sidecar-based mesh сейчас, ambient через 12–18 месяцев когда созреют tooling и documentation.

Связанные листья

Networking — mesh работает поверх TCP/HTTP/gRPC; беглость в networking — пре-условие для дебага mesh-инцидентов.
Containerization & Orchestration — mesh живёт внутри Kubernetes; sidecar injection, admission webhooks, NetworkPolicy — пересечение с k8s-операциями.
Resilience Patterns — retry / circuit breaker / timeout — паттерны, mesh — одна из реализаций; lib в коде — альтернатива.
Progressive Delivery — traffic shifting через mesh — mechanism для canary/blue-green; policy и SLI-driven rollback — отдельный слой.
Workload Identity — mTLS через mesh заменяет shared secrets как метод service-to-service аутентификации.
Secrets Management — root-of-trust для mTLS-сертификатов; cert rotation как первоклассная операция.
SLI-based Alerting — mesh даёт RED-метрики из коробки, но alerting должен быть symptom-based на бизнес-сервисах, не на mesh-internals.
Architecture Decision Records — выбор mesh / отказ от mesh — классический ADR-кандидат.

Открытые вопросы

Когда eBPF-based mesh (Cilium, Ambient) становится «boring choice» — мой прогноз 12–18 месяцев на 2026-2027, но это observation, не measured prediction. Если у вас уже production Cilium Service Mesh — расскажите через PR.
Multi-cluster mesh (Istio multi-primary, Linkerd multicluster) — отдельный класс сложности; в одном кластере я применял, в multi — нет.
Я не уверен, оправдан ли mesh для команд до 20 сервисов, даже если polyglot. Cost/benefit на этом размере выглядит сомнительно — но возможно, я не вижу случаев, где это оправдано. Если у вас есть успешный case на маленьком масштабе — расскажите через PR.