Кратко о том, что такое Service Mesh.

Service Mesh

Service Mesh - это паттерн, идея или можно назвать это подходом. Когда мы говорим, что хотели бы сделать Service Mesh, стоит уточнять для чего и как мы хотим его реализовывать. Разные реализации Service Mesh имеют разный набор фич, свойств, особенностей.

Идея

Service Mesh - это подход к построению управляемого транспортного слоя для взаимодействия между сервисами в SOA или микро-сервисной архитектуре.

Service Mesh позволяет вынести из приложения на уровень транспорта такие вещи как:

набор фич, реализуемых конкретной реализацией Service Mesh стоит уточнять в документации этой реализации.

• Retry
• Circuit breaker
• Управление таймаутами
• Распределенная трассировка
• Логирование
• Балансировка нагрузки
• Сбор метрик
• Контроль доступа
• Шифрование трафика

Т.е. Service Mesh может взять на себя все проблемы порождаемые коммуникациями между сервисами, но дать возможность приложениям влиять на транспортный слой через конфигурацию.

Также, Service Mesh может обеспечить изоляцию некоторого подмножества сервисов и правила взаимодействия (доступности) между сервисами.

Service Mesh - это про tcp,http,rest, а не про сообщения, брокеры сообщений и т.п.

Реализация идеи

Как правило, Service Mesh разбивается на две части: Control Plane и Data Plane:

Control Plane - это инструменты конфигурирования Data Plane. Отвечает за доставку политик в Data Plane, управление маршрутизацией, балансировку запросов, распространение ключей. Включает в себя компоненты для сбора метрик.

Data Plane - компоненты управляющие трафиком между сервисами. Отвечает за исполнение сетевых политик, политик безопасности и сбор телеметрии. Обычно это прокси, стоящий перед сервисом и реализующий правила и функции Service Mesh. Data Plane часто реализуют как Sidecar паттерн, где к сервису добавляется еще один компонент в виде sidecar контейнера, который является реализацией настраиваемого прокси, перехватывающего входящий и исходящий трафик сервиса и управляющего им. Data Plane может быть реализован как с помощью Sidecar паттерна, так и другими способами. Например, с помощью одного прокси на часть кластера K8s.

Service Mesh - это про P2P коммуникации между сервисами. Обычно это реализуется через добавление компонента к каждому сервису для управления трафиком. В последнее время есть попытки сделать один Data Plane компонент и управлять трафиком внутри него. Такой подход более уязвим к отказам, но реализуется из-за значительного потребления ресурсов сайдкарами в системах с большим количеством сервисов.

Service Mesh и безопасность

Сетевое взаимодействие между сервисами - это один из аспектов, на который обращает свое внимание информационная безопасность. Все довольно просто если мы можем открывать и закрывать порты в файерфолах на или между виртуальными машинами или выделенными серверами. Но как быть если мы живем в Kubernetes и у нас много сервисов?

Service Mesh предоставляет полностью настраиваемый транспортный слой между сервисами в рамках Kubernetes (не обязательно только в K8s), что полностью может закрыть наши потребности:

• Шифрование трафика
• Ограничение взаимодействия между сервисами. Можно запретить все коммуникации кроме разрешенных.
• Авторизация. Включая валидацию JWT с валидацией подписавшего токен, также внешнии провайдеры авторизации.
• Логирование
• Метрики
• Зеркалирование трафика. Для анализа в системах мониторинга трафика

Все это предоставляется на уровне транспорта и не требует изменения в защищаемых сервисов. Может поддерживаться отдельной командой безопасности.

Istio как реализация Service Mesh идей

Разные реализации идей Service Mesh имеют разный набор фич и могут иметь очень разную архитектуру. Для примера я возьму одну из популярных реализаций.

реализации Service Mesh - это довольно спорное утверждение, так как нет стандарта на то, что такое Service Mesh и каждая из "реализации идей Service Mesh" имеет свое представление о том, что такое Service Mesh.

Что такое Istio и из чего он состоит

Istio Architecture

Data Plane в Istio - это envoy прокси, который ставится в виде сайдкара .

Control Plane - управление конфигурациями для envoy прокси в виде istiod. Introducing istiod.

Pilot - Конфигурирование, обслуживание Envoy прокси, получение информации из K8s API.

Citadel - Выпуск и управление сертификатами.

Galley - Проверка (валидация) конфигураций. После проверки конфигурация направляется в Pilot.

Возможности Istio

Управление трафиком

• Request Routing - роутинг запросов на основе url, заголовков и user identity.
• Fault Injection & Request Timeouts - внедрение таймаутов, http ответов с ошибками. "test the resiliency of your application"
• Traffic Shifting - распределение трафика на несколько сервисов. canary deployment, AB.
• TCP Traffic Shifting - "Traffic Shifting" для tcp.
• Circuit Breaking - реализация Circuit Breaker паттерна.
• Mirroring - дублирует трафик и отправляет его на два сервиса: оригинал и дополнительный. ответы с дополнительного дропаются. Может зеркалировать только определенный процент трафика.
• Locality Load Balancing - возможность балансировки нагрузки в зависимости от гео-локации. В некоторых случаях нужно самостоятельно предоставлять метки для хостов.
• Ingress - Контроллер входящего (в Service Mesh) трафика.
• Egress - Контроллер исходящего (из Service Mesh) трафика.

Обеспечение безопасности с Istio

Authentication:

• Весь трафик между сервисами в Service Mesh используется mTLS.
• Выставив настройку mtls.mode со значением STRICT мы получим ограничение на трафик без TLS.
• Аутентификация пользователей может выполнить с использованием JWT с проверкой подписи.

Authorization. Правила доступа к сервисам (Authorization Policies):

• HTTP Traffic Authorization Policies - правила на основе заголовков http
• TCP Traffic Authorization Policies - правила для TCP. Host, Port.
• JWT Token Authorization Policies - JWT с проверкой подписи по ключам.
• External Authorization - возможность вызвать внешний провайдер.

Больше деталей в разделе документации про безопасность Istio

Observability (Наблюдаемость)

• Метрики - сбор метрик с каждого envoy прокси в Prometheus. Возможность кастомизации собираемых логов.
• Логи - сбор access логов. OpenTelemetry.
• Распределенная трассировка - Требует добавления заголовков в запросы: x-request-id, x-b3-*. Поддерживаются: Apache SkyWalking, Jaeger, OpenCensus Agent, Zipkin.

sidecar injection

Добавление сайдкаров к сервисам может быть выполнено несколькими способами.

• Патчинг конфигурации сервиса и применение пропатченной конфигурации

istioctl kube-inject -f original-k8s-cfg.yaml > k8s-cfg-with-istio-sidecars.yaml

• Автоматическая вставка

Требует K8s 1.9 или выше.

Для определенного неймспейса мы можем настроить автоматическое добавление сайдкар прокси и применять оригинальные конфигурации сервисов.

kubectl label namespace our-namespace istio-injection-enabled
kubectl create -n our-namespace -f original-k8s-cfg.yaml

Проблемы Istio в Service Mesh

1. Каждый Envoy proxy потребляет значительно количество ресурсов CPU/MEM/NETWORK.
2. Distributed tracing требует от сервиса прокидывать заголовка http запроса.
3. Control Plane (istiod) - точка отказа. При отказе Mesh продолжает работать, но не следит за изменением K8s. Такой режим работы может привести к проблемам.
4. Значительное увеличение латенси с длинных цепочках вызовов и при большом количестве правил (Authorization Policies).

Альтернативы

• Linkerd & Linkerd2 Менее функционален чем Istio но экономичнее.

• Consul Connect - Consul :)

• netramesh Децентрализован - нет control plane. Может объединять трасы по любому http заголовку. X-Request-Id например.

• Kuma

Интересное

Istio в разрезе: что умеет и не умеет самый популярный Service Mesh (А. Половов, DevOpsConf 2023)
Ambient Mesh
Istio Service Mesh в федеративных топологиях Kubernetes / Максим Чудновский (Сбертех)
Istio Service Mesh Beyond Kubernetes
Proxyless Service Mesh в gRPC Java-сервисах
How to monitor Istio, the Kubernetes service mesh
Бенчмаркинг Linkerd и Istio. [2021]
Performance Benchmark Analysis of Istio and Linkerd. [2019]

Заключение

Отличный инструмент для организации контролируемого транспортного слоя микросервисов. Вместе с плюсами добавляет сложности и потребляет ресурсы. При большом количестве микросервисов может потреблять больше памяти чем сами сервисы.