Linkerd в эпоху ambient: зачем самому лёгкому mesh жить дальше, когда все ушли в sidecar-less

В 2025–2026 service mesh пережил смену парадигмы: Istio перевёл всех на ambient, Cilium врезался в трафик через eBPF, и слово «сайдкар» в архитектурных дискуссиях стало ругательным. Linkerd сайдкар не бросил — и не умер: stable-ветка 2.17 закрыла federated services, egress-метрики и rate limiting, а edge-релизы в 2026 году идут почти еженедельно. Вопрос честный: когда мегабайтовый Rust-прокси в поде всё ещё правильный ответ, а когда пора на ambient.

Почему сейчас: 2.17-stable закрыла три главные претензии к Linkerd — «мультикластер — это отдельный экстеншен», «egress — чёрная дыра», «rate limiting нет» — а Buoyant перевела проект на sustainability-модель, из-за которой его уже второй год хоронят в духе «Istio выиграл». Пока хоронят, он выпускает релизы.

Содержание

Три поколения mesh — коротко

Первое поколение — общий прокси на хост: Linkerd 1.x, тяжёлый JVM-монстр, умер первым. Второе — сайдкар в каждом поде: Istio ставил Envoy рядом с приложением, Linkerd 2 — собственный прокси, переписанный с Scala на Rust именно ради веса. Третье — «sidecar-less»: Istio ambient (ztunnel на узле + waypoint для L7, разбирали отдельно) и Cilium (eBPF в ядре + Envoy на узле, тоже разбирали).

Главное, что прояснил ambient: «sidecar-less» не значит «без прокси». Прокси просто переезжает — из пода на узел, а для L7-политик ещё и в waypoint рядом с сервисом. Спор никогда не был «прокси или нет», спор был «где платить»: RAM в каждом поде или агент на каждом узле.

Что приехало в 2.17

Не революция, а закрытие трёх старых дыр плюс новая модель релизов:

• Federated services. Сервис описывается один раз (FederatedService) и живёт в нескольких кластерах одновременно: единое имя, трафик идёт в ближайший здоровый эндпоинт, при смерти кластера — автоматический фейловер в соседний. Это эволюция multicluster-экстеншена с его зеркальными сервисами: меньше движущихся частей, манифест один.
• Egress-метрики. Исходящий трафик наружу кластера перестал быть чёрной дырой: по внешним адресатам видны метрики и тайминги, как по внутренним сервисам. Раньше это была слепая зона — «куда и сколько ходит прод», знали только логи приложения.
• Rate limiting в HTTPRoute. Локальный token bucket прямо в прокси, без внешнего rate-limit-сервиса: лимит описывается правилом маршрута и живёт в том же манифесте. API экспериментальный, но это первый нативный rate limiting за историю проекта.
• Edge vs stable. Buoyant перевела разработку на sustainability-модель: edge-релизы выходят часто (репозиторий buoyant/linkerd2-edge, в 2026 — практически еженедельно), stable — редко и с долгой поддержкой. Для прода — только stable; edge — чтобы потрогать фичи до выхода stable-ветки.

Отдельный вывод из этой модели: проект финансово устойчив через поддержку Buoyant, а не через моду. «Linkerd мёртв» — самый устойчивый миф последних двух лет.

Footprint: мегабайты Rust против агентов на узел

Три расклада data plane в 2026 году:

• Envoy-сайдкар (классический Istio): обычно 100–200 МБ RAM на каждый под плюс заметный CPU под нагрузкой.
• Linkerd-proxy (Rust): ~10–20 МБ RSS на под, добавка к p99-задержке — доли миллисекунды, образ — десятки мегабайт.
• ztunnel (ambient): десятки МБ на узел, амортизируется по всем подам узла — но это чистый L4. Для L7-политик сервису нужен waypoint, а это по сути тот же прокси, только «сайдкар сервиса» вместо «сайдкара пода».

Арифметика на узле с 30 подами: классический Istio — 30 × 150 МБ ≈ 4,5 ГБ только на сайдкары; Linkerd — ~450 МБ на те же поды; ambient — десятки МБ на узел, но каждый сервис, которому нужны L7-политики, добавляет waypoint. Вывод не «кто меньше ест», а где вы готовы платить: Linkerd — чуть больше RAM за простоту модели «под → под» и изоляцию прокси внутри пода; ambient — меньше RAM ценой дополнительного сетевого хопа, второй сущности в диагностике и waypoint-матрицы для L7.

На маленьких кластерах — десятки узлов, десятки сервисов — абсолютные цифры малы у всех, и выбор определяется не RAM, а тем, сколько сущностей вы готовы объяснять дежурному.

mTLS и политика без зоопарка

mTLS в Linkerd включён по умолчанию для всех подов в mesh: каждый под получает сертификат с идентичностью своего ServiceAccount, перевыпуск автоматический, корень доверия — один на кластер (или общий на несколько — для federated services).

Политика построена вокруг идентичности, а не IP-адресов. CRD Server описывает, что защищаем (поды + порт), ServerAuthorization — кому можно. Пока нет ни одного Server, meshed-поды ходят друг к другу по mTLS без единой строчки конфигурации; как только Server на порт повешен — весь трафик без mTLS-идентичности туда режется. Дефолт «mesh → mesh можно, извне нельзя» покрывает большинство реальных политик, и его не надо расписывать матрицей из AuthorizationPolicy на каждую пару сервисов, как это выходит в Istio.

Если нужны правила уровня HTTP — путь/метод/заголовки — есть собственный HTTPRoute из policy.linkerd.io со ссылкой на Server, а в 2.17 — и AuthorizationPolicy поверх маршрута. Но это опция, а не обязательный слой.

Сравнение в одной таблице

Развилка простая: максимальная функциональность и гетерогенные политики — ambient; если кластер уже на Cilium и CNI у вас один — его mesh почти бесплатно; минимальный вес и простота объяснения — Linkerd.

Что нужно, чтобы поднять Linkerd на тестовом кластере

Предусловия: тестовый кластер (kind/k3s), Helm 3, утилита step для генерации тестовых сертификатов идентичности (на проде — cert-manager или корпоративный PKI) и demo-приложение из Deployment + Service.

1. Сертификаты и установка. Linkerd ставится двумя helm-чартами плюс viz-экстеншен для метрик:

step certificate create root.linkerd.cluster.local ca.crt ca.key \
  --profile root-ca --no-password --insecure
step certificate create identity.linkerd.cluster.local issuer.crt issuer.key \
  --profile intermediate-ca --no-password --insecure \
  --ca ca.crt --ca-key ca.key

helm repo add linkerd https://helm.linkerd.io/stable && helm repo update
helm install linkerd-crds linkerd/linkerd-crds \
  --namespace linkerd --create-namespace --wait
helm install linkerd-control-plane linkerd/linkerd-control-plane \
  --namespace linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set-file identity.issuer.tls.crtPEM=issuer.crt \
  --set-file identity.issuer.tls.keyPEM=issuer.key
helm install linkerd-viz linkerd/linkerd-viz \
  --namespace linkerd-viz --create-namespace

2. Замер «до». Деплойте приложение обычным образом и зафиксируйте потребление:

kubectl -n demo apply -f app.yaml
kubectl -n demo top pods

3. Mesh. Инъекция — аннотация namespace и рестарт:

kubectl annotate ns demo linkerd.io/inject=enabled
kubectl -n demo rollout restart deploy/web

Рядом с каждым контейнером приложения появится linkerd-proxy. Повторите kubectl -n demo top pods — это ваш «после»: типичная дельта 10–20 МБ RSS и копейки CPU на под.

4. Политика. Server + ServerAuthorization для одного сервиса:

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: web
  namespace: demo
spec:
  podSelector:
    matchLabels: { app: web }
  port: http
---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: web
  namespace: demo
spec:
  server:
    name: web
  client:
    meshUsers:
      - demo.gateway   # namespace.serviceaccount

Всё: порт web открыт только meshed-клиентам с identity demo/gateway.

5. Rate limit (эксперимент 2.17). Лимит описывается правилом HTTPRoute к тому же Server — синтаксис экспериментальный, сверяйтесь с доками своей версии:

apiVersion: policy.linkerd.io/v1alpha1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: demo
spec:
  targetRefs:
    - { kind: Server, name: web }
  rules:
    - matches:
        - { path: { type: PathPrefix, value: / } }
      filters:
        - type: RateLimitFilter   # локальный token bucket в прокси
          rateLimit:
            type: Local
            local:
              tokenBucket: { maxTokens: 20, tokensPerFill: 10, fillInterval: 1s }

Как проверить, что оно работает

linkerd check
linkerd viz stat deploy -n demo
linkerd viz edges deploy -n demo

• check — зелёный по всем пунктам, включая data plane.
• stat показывает SUCCESS-рейт, RPS и p50/p95 для каждого сервиса — золото, ради которого обычно и ставят mesh.
• edges в колонке SECURITY — TRUE: соединение за mTLS.
• Негативный тест — под вне mesh тем же curl обязан получить отказ, потому что Server не авторизует анонимов:

kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS http://web.demo.svc.cluster.local:8080/

Если снаружи mesh по-прежнему отвечает — Server не селектит порт (проверьте port: http, имя порта в Deployment должно совпадать).

Грабли

• Не-HTTP протоколы. Прокси детектит HTTP/2 и gRPC; трафик баз данных и брокеров помечайте config.linkerd.io/opaque-ports: "5432,9092" — они пойдут как непрозрачный TCP с mTLS, без попыток парсить протокол.
• CPU у прокси. На холостом ходу почти ноль, под пиком — нужен внезапно: держите requests ~100m, а жёсткий лимит не занижайте.
• Edge на проде. Только stable: edge-релизы — это «потрогать раньше», не «эксплуатировать».
• Откат. Mesh снимается снятием аннотации и рестартом — приложение о Linkerd вообще не знало, код не менялся. Это самое недооценённое свойство подхода «прокси в поде»: включил — выключил.

Итог

Ambient не убил Linkerd — он снял с него спор о сайдкарах. Пока выбор был «Envoy по 150 МБ в каждом поде» или «ничего», sidecar-less выглядел безальтернативным; теперь выбор честный: агент на узле с ztunnel и waypoint или мегабайтовый Rust-прокси с моделью «под → под». Для небольших и средних кластеров Linkerd остаётся самым дешёвым способом получить mTLS, метрики per-service и внятную политику за один вечер, а 2.17 закрыла мультикластер и egress. Плата — сайдкар в каждом поде и ставка на менее громкий проект. Сотни узлов и жёсткие L7-политики повсюду — посмотрите на ambient или Cilium; десятки узлов — сначала посчитайте, что именно вы экономите.