Istio 1.2 vs Linkerd 2.5: гоняли оба на одном кластере, смотрели на ресурсы

После того как Istio 1.2 установили на тестовом кластере и закрыли задачу с mTLS, появился логичный вопрос: а что там с Linkerd 2.x, который всё активнее мелькает в докладах и issue-трекерах? Linkerd 2.0 вышел в сентябре прошлого года как полная переработка - не апгрейд Linkerd 1.x (который был на Scala), а новая реализация на Go и Rust с нуля. 2.5 вышел в августе этого года. Решили не откладывать и погонять оба solution-а рядом на одном кластере.

Оговоримся сразу: это не нагрузочный тест и не финальный вердикт. Мы смотрели на поведение в реалистичных условиях managed-инфраструктуры - несколько неймспейсов, микросервисный workload, мониторинг.

Как ставили

Для чистоты сравнения взяли один кластер на Kubernetes 1.15 и разделили workload по неймспейсам: часть подов шла через Istio, часть - через Linkerd. Data plane у обоих работал параллельно, не пересекаясь. Так можно было смотреть на overhead от каждого control plane и сравнивать sidecar-поведение на одинаковом приложении.

Istio 1.2 ставили через Helm с профилем default. Linkerd 2.5 - через официальный CLI (linkerd install | kubectl apply -f -). Разница в процессе установки почувствовалась сразу: Linkerd занял минут пятнадцать от нуля до рабочего состояния, Istio - значительно дольше, с итерациями по настройке Helm values. У Istio больше компонентов, каждый со своими параметрами, и первые несколько попыток обычно уходят на то, чтобы понять что именно не поднялось и почему.

Ресурсы: разница ощутимая

Первое, что бросилось в глаза - потребление ресурсов control plane. Мы не приводим точных цифр, потому что они очень зависят от размера кластера и конфигурации, но порядок такой: Istio с Pilot, Mixer, Citadel, Galley, Prometheus и Kiali потребляет ресурсов в несколько раз больше, чем весь control plane Linkerd. Причём не по чуть-чуть - речь о принципиально другом классе нагрузки.

Отдельная история с Mixer. В Istio он отвечает за policy enforcement и телеметрию, и каждый запрос синхронно ходит через него. При пиковом трафике это заметно по latency. В Linkerd архитектурного аналога Mixer нет - proxy (он называется linkerd2-proxy, написан на Rust) делает всё на data plane уровне без синхронного обращения к control plane.

Sidecar-контейнеры тоже различаются по весу. Linkerd2-proxy тонкий, написанный специально для этой задачи. Envoy у Istio - многофункциональный, мощный, и это чувствуется в RAM-профиле пода.

Настройка: где проще, где сложнее

Linkerd в плане базовой настройки действительно проще. linkerd install генерирует манифесты с разумными дефолтами, аннотация linkerd.io/inject: enabled на неймспейсе или поде - и sidecar появляется при следующем рестарте. mTLS между подами в mesh включён по умолчанию и работает без дополнительных манифестов. Никаких MeshPolicy, DestinationRule, PeerAuthentication.

Обратная сторона простоты - скудость настроек. Если нужно:

• Тонкое управление трафиком - canary по заголовкам, retries с кастомными условиями, fault injection для тестирования отказов.
• Политики авторизации - кто и к чему имеет доступ на уровне mesh, не только mTLS но и RBAC поверх него.
• Интеграция с JWT и внешними auth-провайдерами - EnvoyFilter, RequestAuthentication в Istio.
• Мультикластер - в Linkerd 2.5 этого пока нет в штатном виде.

Во всём этом Istio существенно богаче. VirtualService, DestinationRule, ClusterRbacConfig/ServiceRole, EnvoyFilter - это мощный набор, но за него платишь сложностью. Когда что-то идёт не так, дебажить Istio - это отдельное занятие. Kiali помогает, но не всегда отвечает на вопрос «почему запрос идёт не туда».

Observability

Оба дают L7-метрики из коробки: success rate, latency percentiles, RPS по неймспейсам и сервисам. Linkerd Dashboard - простой, понятный, работает без лишних телодвижений. Grafana дашборды из Linkerd тоже вполне читаемые.

Istio в этом плане гибче: можно прокинуть метрики в любой внешний Prometheus, настроить кастомные правила телеметрии через Mixer. Но гибкость опять же покупается за счёт настройки.

Distributed tracing в Linkerd 2.5 - экспериментальная фича, требует отдельного включения и работает через OpenCensus. В Istio интеграция с Jaeger и Zipkin стабильная и задокументированная.

Что из этого следует для нас

Мы не пришли к выводу «нужно срочно мигрировать с Istio на Linkerd» или наоборот. Ситуация выглядит так:

• Если задача - базовая сервисная сетка с mTLS и observability без сложной маршрутизации - Linkerd 2.5 ставится быстрее, потребляет меньше, разбираться в нём проще. Для небольших кластеров или команд, у которых нет отдельного человека на поддержку mesh, это реальный аргумент.
• Если нужна тонкая политика трафика - canary, circuit breaker с настройками, JWT auth, rate limiting - без Istio здесь пока не обойтись. Функциональность Linkerd в этой области значительно уже.

На managed-кластерах у нас сейчас работает Istio - задачи по traffic management и авторизации там регулярные, и возможности нужны. Но несколько клиентских кластеров, где mesh нужен только ради mTLS и метрик, - это кандидаты на то, чтобы попробовать Linkerd в продакшне. Overhead от Istio там сложно оправдать.

Linkerd 2.x - молодой проект, и это чувствуется в краях функциональности. Но там где он закрывает задачу, он закрывает её хорошо и без лишнего шума.