llmdocsсправочник разработчика

Service mesh

Материал из llmdocs — справочник разработчика
Портал: Контейнеры и Kubernetes
Service mesh
Назначениеуправление трафиком между сервисами
Архитектураdata plane (прокси) + control plane
ПроксиEnvoy, linkerd2-proxy (Rust), eBPF
РеализацииIstio, Linkerd, Cilium Service Mesh, Consul, Kuma
Режимыsidecar, sidecarless (ambient, eBPF)
СтандартыGateway API (GAMMA), SPIFFE

Service mesh (сервисная сетка) — отдельный инфраструктурный слой, через который проходит весь сетевой трафик между сервисами приложения. Сетка берёт на себя то, что иначе пришлось бы реализовать в каждом сервисе: взаимное шифрование и аутентификацию (mTLS), повторы и тайм-ауты, балансировку, постепенный перевод трафика на новую версию, метрики и распределённую трассировку. Код приложения при этом не меняется. Чаще всего service mesh разворачивают поверх Kubernetes.

Зачем

В монолите вызов другого модуля — вызов функции. В микросервисной архитектуре это сетевой запрос, который может потеряться, зависнуть или прийти от злоумышленника. Компании вроде Twitter и Netflix в 2010-х решали это библиотеками (Finagle, Hystrix), но библиотеки привязаны к языку и требуют обновления всех сервисов. Service mesh выносит эти функции из процесса в прокси рядом с ним — так подход стал независимым от языка.[1]

Архитектура

Плоскость Что делает Примеры
Data plane прокси, через которые идёт трафик: шифрование, маршрутизация, сбор метрик Envoy, linkerd2-proxy, ztunnel
Control plane раздаёт прокси конфигурацию и сертификаты, следит за сервисами istiod, Linkerd control plane

Классическая схема — сайдкар: в каждый Pod автоматически добавляется контейнер-прокси, а правила iptables перенаправляют через него весь входящий и исходящий трафик. Прокси двух сервисов устанавливают между собой mTLS-соединение, проверяя криптографическую идентичность друг друга — обычно в формате SPIFFE (spiffe://cluster.local/ns/shop/sa/payments).[6]

Сайдкары расходуют память и процессор на каждом поде и усложняют обновления, поэтому появились режимы без сайдкаров: Istio ambient mode использует общий L4-прокси на узле (ztunnel) и необязательные L7-прокси на пространство имён,[2] а Cilium реализует часть функций в ядре через eBPF (см. Сетевые плагины (CNI)).

Возможности

  • Безопасность. Автоматический mTLS между всеми сервисами без ручного управления сертификатами; политики авторизации «сервис A может вызывать GET /orders у сервиса B». Это основа модели нулевого доверия (zero trust).
  • Управление трафиком. Канареечные релизы (5% трафика на новую версию), маршрутизация по заголовкам, зеркалирование трафика, внесение задержек и ошибок для тестирования устойчивости.
  • Надёжность. Тайм-ауты, повторы с ограничением, автоматический выключатель (circuit breaker), исключение неисправных экземпляров.
  • Наблюдаемость. «Золотые сигналы» — частота запросов, ошибки, задержки — для каждой пары сервисов без изменения кода; экспорт в Prometheus и трассировку через OpenTelemetry.

Реализации

  • Istio — самая функциональная сетка (Google, IBM, Lyft), прокси Envoy, режимы sidecar и ambient. Выпускник CNCF.
  • Linkerd — упор на простоту и производительность: собственный лёгкий прокси на Rust, mTLS включён по умолчанию.[3]
  • Cilium Service Mesh — на базе eBPF и Envoy, совмещён с CNI.
  • Consul (HashiCorp) и Kuma — работают также вне Kubernetes, на виртуальных машинах.

Прокси Envoy, созданный в Lyft, стал фактическим стандартом data plane и используется также в API-шлюзах и ingress-контроллерах.[4]

Пример: канареечный релиз в Istio

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
    - route:
        - destination: {host: reviews, subset: v1}
          weight: 90
        - destination: {host: reviews, subset: v2}
          weight: 10

Инициатива GAMMA переносит такие правила на стандартные ресурсы Gateway API (HTTPRoute), чтобы конфигурация не зависела от конкретной сетки.[5] Gateway API — развитие Ingress.

Когда нужен

Service mesh добавляет движущиеся части: control plane, прокси, сертификаты, новый слой для отладки. Он оправдан, когда сервисов десятки, требуется обязательный mTLS (регуляторика, zero trust) или нужны единые метрики и канареечные релизы для всех команд. Для нескольких сервисов обычно достаточно ingress-контроллера, сетевых политик CNI и библиотек трассировки в коде. Начинать разумно с минимального набора — mTLS и метрики — и включать сложную маршрутизацию по мере необходимости.

См. также

Источники

  1. Istio — What is a service mesh
  2. Istio — Ambient mode overview
  3. Linkerd — Documentation
  4. Envoy proxy — What is Envoy
  5. Kubernetes Gateway API — GAMMA initiative
  6. SPIFFE — Secure Production Identity Framework for Everyone
Категории: