Linkerd: детальный разбор сервис-меша для Kubernetes без магии

В мире микросервисов и Kubernetes управление коммуникацией между сотнями подов стало нетривиальной задачей. На помощь приходят service mesh — инфраструктурный слой для обработки межсервисного трафика. Linkerd, один из первопроходцев в этой области, позиционирует себя как «ультралегкий» и самый простой в использовании mesh. Но что скрывается за этой простотой? Давайте разберем Linkerd по винтикам, убрав магию и поняв, как он на самом деле работает.

В основе архитектуры Linkerd 2.x (теперь просто Linkerd) лежит модель sidecar-прокси. Рядом с каждым подом вашего приложения в кластере Kubernetes запускается крошечный прокси-контейнер на Rust под названием `linkerd-proxy`. Это data plane — плоскость данных, которая фактически перехватывает весь входящий и исходящий TCP-трафик пода. Управляет этими прокси control plane — плоскость управления, состоящая из нескольких компонентов (`destination`, `identity`, `proxy-injector`), развернутых в отдельном неймспейсе.

Ключевой момент — как трафик попадает в прокси? Linkerd использует механизм `iptables` (через CNI-плагин `linkerd-cni` или меньшее по возможностям `linkerd-init` контейнер). При старте пода правила `iptables` перенаправляют весь исходящий трафик с портов пода на порт `4143` sidecar-прокси, а весь входящий трафик — на порт `4140`. Прокси, получив трафик, принимает решение на основе информации от control plane: куда его направить, нужно ли шифровать, какие метрики собрать.

Плоскость управления — мозг операции. Компонент `destination` является источником истины о том, какие сервисы существуют и на какие конкретные поды (и их прокси) они указывают. Он агрегирует данные из Kubernetes API. Компонент `identity` отвечает за mTLS (взаимный TLS), автоматически выдавая сертификаты для каждого прокси и обеспечивая шифрование «из коробки» для всего трафика меша. `Proxy-injector` — это admission controller, который автоматически добавляет sidecar-контейнер в поды при их создании, если они помечены нужной аннотацией или находятся в помеченном неймспейсе.

Теперь о том, что Linkerd делает с трафиком. Во-первых, это разгрузка (load balancing). Прокси использует алгоритм «наименьших активных запросов» для выбора цели, что эффективнее стандартного round-robin в kube-proxy. Во-вторых, это отказоустойчивость: автоматические повторные попытки для идемпотентных запросов и circuit breaking при множественных ошибках. В-третьих, это observability: каждый прокси автоматически экспортирует метрики (latency, RPS, error rates) в формате Prometheus, предоставляя детальную картину здоровья связи «сервис-к-сервису» без изменения кода приложения.

Одна из самых сильных сторон Linkerd — его подход к безопасности. Вместо сложной настройки сертификатов Linkerd использует механизм доверенных сертификатов на уровне кластера (через компонент `identity`). Каждому прокси при запуске выдается кратковременный сертификат, и весь трафик между прокси автоматически шифруется с помощью mTLS. Это происходит прозрачно для приложения. Администратор видит, какой процент трафика в меше зашифрован, через веб-дашборд или CLI.

Установка и эксплуатация намеренно сделаны простыми. Базовая установка выполняется одной командой `linkerd install | kubectl apply -f -`. Основные операции — проверка работоспособности (`linkerd check`), просмотр метрик (`linkerd viz dashboard`), ввод/вывод из меша (`linkerd inject`). Философия Linkerd — «просто работает». Он не имеет встроенного API-шлюза (в отличие от Istio) и фокусируется исключительно на внутреннем трафике между сервисами, что делает его менее сложным.

Однако у простоты есть обратная сторона. Linkerd менее гибок в кастомизации, чем Istio. Например, для реализации сложных правил маршрутизации (canary-развертывания, A/B-тестирования) вам понадобится использовать его CRD (Custom Resource Definitions), возможности которых, хотя и растут, пока уступают богатому набору VirtualService и DestinationRule в Istio. Linkerd сознательно жертвует гибкостью ради безопасности, простоты и минимального overhead — его прокси на Rust имеют ничтожное потребление памяти и CPU по сравнению с Envoy.

В итоге, Linkerd — это не волшебная таблетка, а тщательно спроектированный инженерный продукт, который решает конкретный набор проблем: обеспечение надежности, безопасности и наблюдаемости межсервисной связи в Kubernetes с минимальными затратами на внедрение и эксплуатацию. Его архитектура, основанная на sidecar-прокси и автоматическом mTLS, делает его отличным выбором для команд, которые ценят простоту и хотят получить базовые преимущества service mesh без глубокого погружения в его внутреннюю кухню.