Service Mesh

«Поставим service mesh, и mTLS, повторы и трассировка будут из коробки». После такой позиции я регулярно вижу команды, у которых mesh стал новой точкой отказа: управляющий слой со своей недоступностью, прокси в каждом поде плюс лишние сотни миллисекунд к старту, а инцидент теперь разбирается через два слоя логов — приложение и Envoy. Инструмент мощный, спору нет. Но это инфраструктурный слой, и эксплуатировать его придётся с той же зрелостью, что и сам Kubernetes (см. Containerization & Orchestration). Этот лист — про то, когда mesh оправдан, как он устроен и чем за него платят в проде.

Граница: Networking — про сетевой стек как среду передачи (TCP, TLS, HTTP); здесь — про надстройку уровня приложения поверх трафика между подами. Resilience Patterns — про сами паттерны (повторы, circuit breaker, таймауты); mesh — одна из их инфраструктурных реализаций. Workload Identity — пересечение через mTLS как замену общим секретам.

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

Главный навык на уровне L5 — честно ответить на вопрос «нужен ли нам mesh». По моим наблюдениям, в большинстве команд — до сотни сервисов, один регион, нет жёсткого требования регулятора на mTLS — ответ «нет, пока». Mesh выигрывает в трёх случаях: mTLS между всеми сервисами нужен как обязательное требование; языков и фреймворков много, и стандартизировать повторы, таймауты и трассировку в коде дороже, чем поднять прокси рядом с каждым сервисом; сценарии перевода трафика сложные — канарейки, A/B, зеркалирование, — а не пара штук, которые закрывает контроллер ingress. Команда, которая сначала задаёт эти вопросы и потом ставит mesh, эксплуатирует его осознанно. Команда, которая ставит «потому что Istio в каждом докладе», покупает операционный долг.

Понимает архитектуру: прокси рядом с каждым сервисом (обычно Envoy) плюс управляющий слой (Istio, Linkerd, Consul Connect). Знает, что прокси подставляется через вебхук admission и перехватывает трафик через iptables.
Различает три базовые функции: mTLS (взаимная аутентификация сервисов), управление трафиком (маршрутизация, повторы, таймауты), наблюдаемость (RED-метрики, сквозная трассировка, журнал доступа). Понимает, что всё это можно получить и по отдельности — cert-manager, повторы в коде, SDK OpenTelemetry, — а mesh просто упаковывает три вещи в одну.
Разбирает инцидент внутри mesh: istioctl proxy-status и istioctl proxy-config, административная ручка Envoy (localhost:15000/clusters, /listeners, /stats), логи прокси через kubectl logs -c istio-proxy. Знает, что 503 от mesh и 503 от приложения — разные вещи.

Оценивает накладные расходы: добавка к задержке на каждом переходе через прокси, память и процессор на под, время старта. И делает осознанный вывод, что mesh этого стоит.
Различает Istio, Linkerd и решения на eBPF (Cilium Service Mesh, Istio Ambient): чем отличаются по сложности управляющего слоя, потреблению и набору возможностей. По моим наблюдениям, Linkerd чаще выбирают за «делает три вещи хорошо», Istio — за богатство возможностей, безпрокси-режимы — за то, что рядом с каждым подом ничего не висит.
Управляет обновлением mesh: канареечный управляющий слой, ревизии Istio (istio-injection=disabled плюс istio.io/rev), одновременная жизнь двух версий.
Понимает модель безопасности: как часто ротируются сертификаты, откуда растёт корень доверия (внешний удостоверяющий центр или встроенный), как политики доступа работают на уровне приложения.

L6+

Решает «mesh или нет» для конкретной системы: формулирует критерии в ADR и готов аргументировать «пока без него» так же убедительно, как «давайте поставим».
Готов к инциденту уровня «mesh лёг»: откат управляющего слоя, отключение подстановки прокси меткой на пространстве имён, возврат к прямому трафику между подами. Держит runbook на нездоровый управляющий слой.

Материалы

Книги

Lee Calcote, Nic Jackson — Istio: Up and Running (O’Reilly, 2019). Немного устарела по конкретным API, но архитектурный фундамент описан правильно. Лучшая часть — главы про прокси и Envoy.
Документация Linkerd (Buoyant). Бесплатно и концептуально чище, чем у Istio: устройство прокси, идентичность и mTLS разобраны без лишнего. Читается за выходные.

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

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

Инструменты

Envoy — индустриальный стандарт для слоя данных. По моим наблюдениям, подавляющее большинство установок mesh так или иначе стоят на нём: через Istio, Consul Connect или собственные сборки.
Istio — самый богатый по возможностям управляющий слой. Подходит, когда нужно всё сразу: mTLS, управление трафиком, несколько кластеров, расширяемые политики. Цена — сложность эксплуатации.
Linkerd — альтернатива с установкой «делаем три вещи хорошо». Свой прокси на Rust, меньше потребление, проще операции. По моим наблюдениям, его чаще выбирают команды, которым нужен mesh без отдельного инженера под mesh.
Cilium Service Mesh / Istio Ambient — подход без прокси в каждом поде: eBPF или один прокси на узел. Ambient официально стал стабильным в Istio 1.24 в ноябре 2024, то есть формально это уже не эксперимент.
Consul Connect — mesh от HashiCorp, сросшийся с обнаружением сервисов в Consul. Выбор для тех, у кого Consul уже стоит.
Kiali — интерфейс для Istio: граф сервисов, потоки трафика, проверка конфигурации. По моим наблюдениям, единственный способ разбираться в mesh, не открывая административную ручку Envoy руками.
istioctl analyze / linkerd check — проверка вменяемости конфигурации от самих проектов. Запускать перед каждым обновлением.

Best practices

Хороший публичный кейс «откуда взялся mesh» — история Envoy в Lyft (2015–2016). Команда столкнулась с разноязычной средой: Python, Go, Java, Node.js — у каждого свой HTTP-клиент, свои повторы, таймауты и предохранители, свои метрики. Любое изменение сетевых правил требовало релиза всех сервисов сразу. Решение — вынести сетевую логику в отдельный процесс (Envoy), который запускается рядом с каждым приложением. Это и есть слой данных современного mesh; всё, что сверху — Istio, Linkerd, Consul Connect, — управляющие слои над ним. На этот контекст я регулярно ссылаюсь, когда команда только думает про mesh. Три сервиса на одном языке? Тогда mesh решает проблему, которой у вас нет. Полсотни сервисов на пяти языках, и повторы в каждом сделаны по-своему? Считайте выгоду всерьёз.

Отсюда первое правило: mesh не отменяет повторы и таймауты в коде, он их дублирует. «У нас mesh, повторы он сделает» — антипаттерн. Mesh повторяет запрос на сетевом уровне, по методу и коду ответа, а приложение — на бизнес-уровне, где живут идемпотентность, дедупликация и отложенная согласованность. Два независимых слоя повторов без договорённости складываются в шторм. Решение принимает кто-то один, второй пропускает запрос как есть. Чаще всего на mesh остаются таймаут и предохранитель, а повтор живёт в коде, где известна бизнес-семантика.

mTLS — не бесплатная безопасность, а новый способ упасть. Ротация сертификатов, компрометация ключа, кривая цепочка доверия — любое из этого кладёт трафик в mesh за секунды. Runbook на «mTLS сломался по всему mesh» тут обязателен, как и алерты на состояние сертификатов: обратный отсчёт до истечения, сбои ротации. Тот же уровень внимания, что и к сертификатам на входе в кластер.

Прокси рядом с каждым подом — налог, который платит каждый под. Сотня-другая мегабайт памяти на прокси при сотне подов превращается в десятки гигабайт, потраченных только на mesh. На маленьких нагрузках это незаметно, на больших съедает заметную часть мощностей кластера. Поэтому потребление меряется до выката в прод и на реалистичной нагрузке, а не на «hello world». К задержке добавляются единицы миллисекунд на каждом переходе — обычно терпимо, но на длинной цепочке вызовов это уже видно в бюджете.

Управляющий слой — отдельный класс инцидентов. Я регулярно вижу команды, у которых его здоровье вообще не покрыто алертами. Логика простая: mesh же абстракция, она работает. Когда istiod падает, прокси какое-то время живут на закешированной конфигурации, а потом начинают отказывать в самых неочевидных местах. Здоровая модель эксплуатации: управляющий слой мониторится так же тщательно, как kube-apiserver, — доступность, время доставки конфигурации, версии конфигурации на прокси. Без этого инциденты диагностируются по принципу «странно работает всё одновременно».

Один mesh на кластер. Не два и не три, потому что «командам нужно разное». Схема «безопасность хочет Istio, наблюдаемость хочет Linkerd, поставим оба» — прямая дорога к несовместимой подстановке прокси и невоспроизводимым багам, которые потом невозможно ни объяснить внятно, ни повторить на стенде, ни закрыть без разбора обоих управляющих слоёв сразу. По моим наблюдениям, здоровый вариант один: mesh на кластер, выбранный после ADR. Если разные команды хотят разного — это разговор «давайте обсудим критерии», а не «давайте поставим оба».

Перевод трафика через mesh — ещё не постепенная выкатка. Часто слышу «у нас canary через Istio»: девяносто процентов на первую версию, десять на вторую, маршрутизацию делает mesh. Это не канарейка. Это перекладывание трафика. Канарейка — это когда десять процентов трафика едут на новую версию, за её SLI следит автоматика, и при нарушении она сама возвращает всё назад, не дожидаясь, пока кто-нибудь посмотрит на график. Mesh даёт механизм — правила маршрутизации. Политику, то есть решение «катим дальше или откатываем», задаёт отдельный слой. Flagger и Argo Rollouts как раз сшивают эти две части вместе.

Режим без прокси в каждом поде — уже не эксперимент, но и не автоматический выбор. Cilium Service Mesh и Istio Ambient переносят работу на уровень узла. Идея красивая: меньше потребление, проще обновление, нет платы за старт прокси в каждом поде. Ambient стал стабильным в Istio 1.24 в ноябре 2024, так что аргумент про бету больше не работает. Осторожность теперь в другом: публичных разборов эксплуатации на серьёзном масштабе по-прежнему мало, а отлаживается всё это не так, как привычная схема. Если mesh у вас работает и не болит — мигрировать ради миграции незачем; если ставите с нуля на свежем кластере, этот режим стоит рассматривать наравне с прокси в поде, а не «через год».

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

Networking — mesh работает поверх TCP, HTTP и gRPC; без свободного владения сетью инцидент внутри него не разобрать.
Containerization & Orchestration — mesh живёт внутри Kubernetes; подстановка прокси, вебхуки admission и сетевые политики — прямое пересечение с эксплуатацией кластера.
Resilience Patterns — повторы, circuit breaker и таймауты — это паттерны, mesh — одна из реализаций; библиотека в коде остаётся альтернативой.
Progressive Delivery — перевод трафика через mesh — механизм для канарейки и blue-green; политика и автоматический откат по SLI живут слоем выше.
Workload Identity — mTLS через mesh заменяет общие секреты как способ аутентификации между сервисами.
Secrets Management — корень доверия для сертификатов mTLS; ротация сертификатов — полноценная операция со своим runbook.
SLI-based Alerting — mesh отдаёт RED-метрики из коробки, но алерты всё равно ставятся на симптомы бизнес-сервисов, а не на внутренности самого mesh.
Architecture Decision Records — выбор mesh или отказ от него — классический кандидат в ADR.

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

Когда mesh на eBPF (Cilium, Ambient) станет скучным выбором по умолчанию, я не знаю. Мой прогноз — года полтора от 2026-го, но это ощущение, а не измерение. Если у вас Cilium Service Mesh уже крутится в проде, расскажите через PR.

Mesh между кластерами (Istio multi-primary, Linkerd multicluster) — отдельный класс сложности, и здесь я честно вне зоны своего опыта: в одном кластере применял, в нескольких — нет. И главное сомнение: оправдан ли mesh для команд до двадцати сервисов, даже разноязычных. Соотношение цены и пользы на таком размере выглядит сомнительно, но допускаю, что просто не вижу случаев, где оно сходится. Если у вас такой случай есть — расскажите через PR.