Что такое service mesh и какую проблему он решает
Service mesh - это инфраструктурный слой, который перехватывает весь сетевой трафик между твоими сервисами и берёт на себя то, что иначе пришлось бы зашивать в каждое приложение: шифрование, ретраи, таймауты, балансировку, сбор метрик и трассировку. Ключевая идея - вынести сетевую логику ИЗ кода приложения в отдельный прокси, который живёт рядом с подом и о котором приложение даже не знает.
Меш делится на два слоя. Data plane (плоскость данных) - это армия прокси, через которые реально течёт трафик. Control plane (плоскость управления) - мозг, который раздаёт прокси конфигурацию: куда маршрутизировать, какие сертификаты использовать, какие политики применять. Прокси не знают друг про друга напрямую - они получают актуальную картину мира от control plane. Поменял ты правило маршрутизации через CRD - control plane пересчитал конфиг и разослал его всем прокси за секунды, без рестарта приложений.
Классическая реализация data plane - это sidecar: в каждый под рядом с твоим контейнером инжектится контейнер-прокси (обычно Envoy). Через iptables или eBPF весь входящий и исходящий трафик пода заворачивается в этот прокси. Приложение думает, что коннектится к localhost, а на деле прокси устанавливает mTLS-туннель до прокси соседнего пода. Отсюда волшебство: шифрование и метрики появляются "бесплатно", без единой строки в коде.
mTLS, трафик-менеджмент и наблюдаемость - три кита
Разберём, ЧТО конкретно даёт меш, потому что без понимания ценности невозможно решить, нужен ли он.
1. mTLS между сервисами. Mutual TLS - это взаимная аутентификация: не только клиент проверяет сервер, но и сервер проверяет клиента по сертификату. В обычном кластере трафик между подами идёт открытым текстом по приватной сети - кто пролез внутрь, читает всё. Меш выдаёт каждому сервису криптографическую identity (по стандарту SPIFFE, вида spiffe://cluster.local/ns/prod/sa/payments) и автоматически ротирует короткоживущие сертификаты. Так mtls kubernetes из мучительного ручного управления PKI превращается в дефолт. Это базовый кирпич zero-trust: сервис A может звонить сервису B не потому, что они в одной сети, а потому что предъявил валидный сертификат с нужной identity.
2. Трафик-менеджмент. Тут меш раскрывается на полную:
- Canary / weighted routing - льёшь 5 процентов трафика на v2, 95 на v1, смотришь метрики, плавно сдвигаешь вес. Откат - смена одной цифры в конфиге.
- Retries - прокси сам повторяет неудавшийся запрос (например, на другой инстанс), приложение об этом не знает.
- Timeouts - жёсткий потолок ожидания, чтобы один тормозящий сервис не подвесил всю цепочку.
- Circuit breaking - если инстанс сыпет ошибками, прокси временно выкидывает его из пула, давая отлежаться. Это спасает от каскадных отказов.
- Fault injection - можно искусственно вносить задержки и ошибки, чтобы проверить устойчивость (chaos-инженерия без отдельных тулов).
Sidecar против ambient: тренд 2026 на sidecarless
Классический sidecar платит дорого. На каждый под - отдельный контейнер Envoy, а это память (десятки-сотни мегабайт на под), CPU, лишний сетевой хоп туда-обратно и, главное, операционная боль: обновил версию меша - надо передёрнуть (рестартнуть) ВСЕ поды, чтобы подтянулся новый прокси. На тысяче подов это тяжело.
Ответ индустрии в 2025-2026 - ambient mesh (sidecarless), который в Istio дошёл до GA. Идея: убрать прокси из подов и разнести функции по двум уровням.
- ztunnel (zero-trust tunnel) - лёгкий прокси на Rust, запущенный как DaemonSet, один на ноду. Он берёт на себя L4: mTLS, SPIFFE-identity, шифрование и базовые L4-политики для всех подов ноды. Это дёшево и включается на весь кластер без трогания приложений.
- Waypoint - опциональный L7-прокси (Envoy), который поднимается на namespace или сервис ТОЛЬКО когда нужны умные L7-функции: HTTP-роутинг, ретраи, canary, L7-авторизация. Не нужен L7 - не платишь за него.
istio против linkerd: мощь против простотыПравило большого пальца на 2026: если ставишь меш с нуля - сразу смотри в сторону ambient/sidecarless, а не классических sidecar. Меньше оверхеда, проще эксплуатация, легче апгрейды.
Два самых известных меша воплощают две философии.
istio - швейцарский нож. Data plane на Envoy, богатейший трафик-менеджмент, мульти-кластер и мульти-сеть, самая зрелая модель авторизации (важно для SOC 2, PCI-DSS, HIPAA), VM-воркоады вне кластера, ambient-режим. За мощь платишь сложностью: десятки CRD, кривая обучения крутая, неаккуратная конфигурация легко стреляет в ногу. istio - выбор, когда у тебя реально сложные требования и есть кому его эксплуатировать.
linkerd - меш-минималист, выпускник CNCF. Свой собственный микропрокси на Rust (не Envoy), за счёт чего он очень лёгкий и быстрый. mTLS включён по умолчанию из коробки, конфигурация минимальна, дашборд чистый и про золотые сигналы, а не про тонну ручек. linkerd сознательно отказывается от части тяжёлых фич ради того, чтобы его можно было поставить и забыть. Это выбор, когда тебе нужны mTLS, наблюдаемость и базовая надёжность без операционного ада.
Грубая развилка: нужен максимум контроля над трафиком, мульти-кластер, строгий compliance - istio. Нужны mTLS и метрики с минимальным оверхедом и без отдельного инженера на поддержку - linkerd. Нужна максимальная производительность и ты уже на eBPF-CNI - смотри Cilium.
Практика: ставим linkerd и включаем mTLS
Покажу на linkerd - он быстрее всего доводится до рабочего состояния. Сначала ставим CLI и проверяем готовность кластера:
Код: Выделить всё
curl -sL https://run.linkerd.io/install | sh
linkerd check --pre
Код: Выделить всё
kubernetes-api
--------------
v can initialize the client
v can query the Kubernetes API
pre-kubernetes-setup
--------------------
v can create Namespaces
v can create ClusterRoles
...
Status check results are v
Код: Выделить всё
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check
linkerd viz install | kubectl apply -f -
Код: Выделить всё
kubectl annotate namespace prod linkerd.io/inject=enabled
kubectl rollout restart deployment -n prod
Код: Выделить всё
kubectl get pod -n prod
NAME READY STATUS RESTARTS AGE
payments-7c9f8b6d4-2xk9p 2/2 Running 0 40s
Код: Выделить всё
linkerd viz edges deployment -n prod
SRC DST SRC_NS DST_NS SECURED
catalog payments prod prod v
checkout catalog prod prod v
Типичные грабли и антипаттерны
- Меш ради меша. Главный антипаттерн. На пять микросервисов ставить istio - значит получить больше движущихся частей, чем самих сервисов. Сложность инфраструктуры превысит сложность бизнес-логики.
- Забыл аннотацию инжекции. Поставил меш, а поды как были 1/1, так и остались. Меш не магия - без аннотации и рестарта прокси не появится, трафик идёт открытым текстом, а ты думаешь, что под защитой.
- Жёсткий таймаут без ретраев и наоборот. Поставил агрессивные ретраи на не-идемпотентный POST - словил дубли платежей. Ретраи безопасны только для идемпотентных операций, это надо проектировать осознанно.
- Игнор оверхеда. Каждый sidecar - это +хоп и +память на под. На больших масштабах считай ресурсы заранее или сразу бери ambient/sidecarless.
- Mesh-only Ingress на границе. Меш отвечает за восток-запад трафик (между сервисами). На входе с улицы (север-юг) всё равно нужен Gateway API или Ingress. Меш их не заменяет.
- Апгрейд sidecar-меша без плана. Новая версия требует рестарта всех подов с прокси. На большом кластере это надо катить волнами, а не одним rollout на всё.
Service mesh оправдан, когда: сервисов МНОГО (десятки и больше), есть жёсткое требование mTLS/zero-trust по всему трафику, нужен тонкий трафик-менеджмент (canary, circuit breaking) для многих сервисов, нужна сквозная наблюдаемость графа сервисов, и - критично - у тебя есть команда, готовая это эксплуатировать.
Меш - оверинжиниринг, когда сервисов мало, трафик простой, а compliance не требует mTLS. В этом случае альтернативы дешевле и достаточны:
- Gateway API - современный преемник Ingress, закрывает маршрутизацию и TLS-терминацию на входе. Часть задач "управления трафиком" решается им без меша.
- Библиотеки и фреймворки - ретраи, таймауты, circuit breaking можно взять из библиотек (resilience-паттерны в самом приложении). Минус - надо тащить на каждом языке и править код, плюс - ноль инфраструктурного оверхеда.
- NetworkPolicy + WireGuard на уровне CNI - шифрование нода-нода и сегментация сети без полноценного меша.
- Cilium как CNI - даёт часть mesh-функций (L7-политики, наблюдаемость через Hubble) почти бесплатно, если он уже твой сетевой плагин.
Мини-лаба: пощупай меш руками
- Подними локальный кластер (k3d, kind или Yandex Managed Kubernetes / VK Cloud для облака).
- Установи linkerd: linkerd install --crds | kubectl apply -f -, затем control plane и viz.
- Задеплой demo-приложение из двух-трёх сервисов, навесь на namespace аннотацию linkerd.io/inject=enabled и сделай rollout restart.
- Проверь, что поды стали 2/2, а linkerd viz edges deployment показывает SECURED с галочкой.
- Открой linkerd viz dashboard и найди граф сервисов, RPS и долю успешных ответов.
- Бонус: разверни istio в ambient-режиме (istioctl install --set profile=ambient), пометь namespace меткой ambient и убедись, что mTLS поднялся БЕЗ единого sidecar в подах.
- Чем data plane отличается от control plane и что из них реально пропускает через себя трафик?
- Что даёт mTLS в меше и почему его сложно сделать руками без меша?
- В чём принципиальная разница между sidecar и ambient (ztunnel + waypoint) по ресурсам и эксплуатации?
- Назови две ситуации, где меш - оверинжиниринг, и чем его заменить.
Service mesh - это инфраструктурный слой из прокси (data plane) и мозга (control plane), который даёт mTLS, трафик-менеджмент и наблюдаемость без правки кода приложений. istio - мощный и сложный, linkerd - простой и лёгкий, а тренд 2026 - sidecarless: ambient в Istio (ztunnel + waypoint) и eBPF в Cilium режут оверхед и боль апгрейдов. Меш оправдан на десятках сервисов с требованиями к безопасности и трафику, но на маленькой системе это оверинжиниринг - там хватит Gateway API и библиотек. Главное правило: вводи меш не потому, что модно, а когда боль стала системной.
