Большой обзор Service Mesh: часть первая

Первая часть обзора решения Service Mesh

Service Mesh входит в перечень стандартных для бэкенда технологий, а недавно и вовсе был на вершине хайпа. Вы решаете идти в ногу со временем и добавить в свой кластер Kubernetes первый Service Mesh. От друзей слышите, что Istio требует много памяти, а прокси в Linkerd очень быстрые, хотя никто не проверял. А еще все почему‑то говорят про Cillium, хотя это CNI‑плагин. Обсудим, что к чему.

Меня зовут Максим Чудновский, я занимаюсь развитием интеграционной платформы Synapse в СберТехе. Она имеет поддержку всех возможных стилей интеграции: RPC, файловые, шаблоны в Event Driven architecture. Есть в ней и RPC, а соответственно и Service Mesh, которым я и занимаюсь. Поэтому сегодня поговорим именно о нем.

Что такое Service Mesh?

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

Концептуальный Service Mesh состоит из двух частей.

Первая часть — Control Plane. Отвечает за назначение и распространение политик маршрутизации трафика, артефакты, безопасности, токены, ключи, сертификаты. А еще за сбор телеметрии и интеграцию с внешней инфраструктурой. Чаще всего это PKI, журналирование, мониторинг и т. д.

Вторая часть — это Data Plane. Размещается непосредственно с приложениями и занимается очень простым делом: исполняет политики, которые получает от Control Plane. Соответственно, Data Plane — это чаще всего сетевые прокси, которые отвечают за маршрутизацию и балансировку трафика в нагруженной среде. Также Data Plane выполняет аутентификацию, авторизацию всех вызовов, формирует спаны для распределенной трассировки и метрики для того, чтобы повысить уровень обозреваемости микросервисных систем.

Классификация

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

Cotrol Plane

Компонентный состав (Type)

С функциональной точки зрения Control Plane очень хорошо декомпозируется, поэтому компонентный состав, как не трудно догадаться, может быть микросервисным. Например, если есть работа с сертификатами, можно создать certification registration authority. А если мы работаем в Kubernetes и хотим автоматически добавить всем рабочим нагрузкам Data Plane Proxy в виде sidecar‑контейнеров, то создаем компонент mutation webhook server и используем механизм Admission Controllers.

Однако в противовес этому есть и другой подход — монолитный, когда все эти функции объединяются в рамках одного daemon, который бежит где‑то в кластере и занимается полезными делами Service Mesh. Этот daemon простой, его удобно сопровождать. С ним все становится гораздо проще.

API

С точки зрения API Control Plane может быть проприетарным. Это история, когда разработчики делают определенный API, чтобы управлять функциональностью своего Service Mesh, и живут с ним в дальнейшем. Он может выглядеть так:

Следующий вариант — это Gateway API. Он пришел из сообщества ванильного Kubernetes и изначально отвечал за ingress трафик. Решение заключалось в том, чтобы разделить зону ответственности между инфраструктурными командами, отвечающими за ingress‑класс, и пользователем, который только использует ingress‑контроллер. Последнему нужно просто сделать какой‑нибудь HTTP route и завести трафик на свой workload в кластере.

Как оказалось, Gateway API очень хорошо подходит для управления HTTP трафиком. Соответственно, во многих реализациях Service Mesh это нашло применение. Вот пример:

И последний доступный вариант API — это Service Mesh Interface (SMI).

Это open source спецификация, которая претендует на звание стандарта по управлению Service Mesh. На текущий момент SMI и Gateway API двигаются в сторону объединения. Скорее всего, в будущем мы увидим уже обобщенную спецификацию, которая будет включать лучшие практики из обоих решений.

Если подвести итог, то один из этих вариантов так или иначе можно встретить в любом Service Mesh. При этом возможны и комбинации — мы рассмотрим такой пример в дальнейшем.

Data Plane

Компонентный состав (Type)

Самый распространенный тип Data Plane — это вариант, который построен на sidecar‑контейнерах. Конструкция простая: рядом с контейнером приложения добавляется еще один, в котором размещается сетевой прокси. При этом правила маршрутизации сетевого трафика в рамках пода настраиваются таким образом, чтобы все запросы проходили через sidecar‑контейнер, который в свою очередь занимается сетевым процессингом на уровнях L4 и L7.

Следующий вариант — это Node Daemon.

Его идея в том, чтобы у вашего пода в кластере не было больше sidecar‑контейнеров с прокси. Они опускаются на уровень ниже, то есть к вычислительным узлам Kubernetes. И там уже переиспользуются между всеми рабочими нагрузками — подами, которые запущены на данном узле. Это помогает экономить вычислительные ресурсы кластера, потому что требуется гораздо меньше экземпляров сетевого прокси.

И ещё один вариант — Proxyless.

Его идея совсем простая: отказаться от сетевых прокси, демонов и дополнительных контейнеров, и вернуть всю сетевую функциональность на уровень приложения, как было принято в 2010 году.

Подход хороший, за исключением того, что он нивелирует многие плюсы Service Mesh, в частности его неинвазивное подключение. Поэтому этот вариант чаще всего применяется с одновременным встраиванием поддержки Service Mesh в тот фреймворк, который используется для сетевых взаимодействий.

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

API

С точки зрения API есть протокол xDS.

Он возник как протокол динамической маршрутизации из проекта Envoy Proxy. XDS хорошо структурирован, понятен и отвечает сразу за множество аспектов работы прокси: за Service Discovery, правила маршрутизации и работу с секретами. Также он полностью отвечает за конфигурацию бэкенда и тех endpoint»ов, которые будут обслуживать этот бэкенд. В частности, xDS отвечает на следующие вопросы:

• Как будет распределяться трафик по весам?

• Какие будут приоритеты?

• Какая зональность будет у endpoint»ов?

• Как будет переключаться трафик в случае недоступности отдельных экземпляров бэкенда?

Так сложилось, что xDS получил широкое распространение вместе c проектом Envoy Proxy. Относительно его популярности в сообществе он стал де‑факто стандартом API для Data Plane в Service Mesh.

Но все же часть людей не использует xDS. И тут альтернативой выступает проприетарный API, например NGINX Plus API.

Traffic Capture

Как мы помним, Data Plane забирает на себя сетевой трафик и осуществляет L4, L7 процессинг. Но как именно Service Mesh настраивает правила для перенаправления сетевого трафика?

Он может это сделать в рамках пода, сразу запуская скрипты редиректа как часть рабочей нагрузки. Чаще всего это реализуется с помощью дополнительного init‑контейнера. В итоге настраивается оверлейная сеть на рабочем узле Kubernetes, чтобы в рамках нашего пода весь сетевой трафик перенаправлялся на sidecar‑контейнер с сетевым прокси из состава Data Plane.

При этом никаких дополнительных компонентов не требуется. В целом это отличная схема. Единственный минус — нужно выдать полномочия NET_RAW и NET_ADMIN для настройки правил Iptables, с помощью которых осуществляется перенаправление трафика внутри пода. А они выдаются не только для init‑контейнера, но и на весь service account, под которым запускается под.

Таким образом application‑контейнер также получает эти полномочия, хотя они ему абсолютно не нужны. Это нарушает правило минимальных привилегий, важное для сред со строгими ограничениями по информационной безопасности.

Другой подход — это Node Level.

В рамках пода запускаются только два контейнера — application и proxy в случае data plane, построенного на sidecar, — внутри которых никакого перенаправления трафика не происходит. Но в кластере есть некоторый Service Mesh CNI Daemon, который делает это за них, используя механизм CNI‑плагинов.

Устроено это так: основной СNI‑плагин инициализирует и исполняет непосредственно оверлейную сеть Kubernetes. А дополнительные плагины могут сделать еще что‑нибудь полезное. Тут в игру вступает наш CNI‑плагин в составе Service Mesh, который в момент инициализации сетевого стека на вашем поде настраивает правила перенаправления трафика.

Для того, чтобы это сработало Service Mesh CNI Daemon раскладывает CNI‑плагин в нужный каталог на всех воркерах, где будут запускаться поды, подключаемые к Service Mesh. При этом этот daemon иногда еще решает вопросы с гонками при старте подов из‑за автоматического кластерного масштабирования.

Вместо итога

Мы рассмотрели основные решения и нюансы реализации Service Mesh, изучили типы Data Plane и Control Plane. С теорией все ясно — осталось посмотреть, как это будет работать на практике.

В следующей статье рассмотрим, как наша классификация накладывается на реальную жизнь и работает в конкретных Service Mesh. Как устроен Platform V Synapse Service Mesh от СберТеха и на что в целом стоит обратить внимание, выбирая оптимальный инструмент для своих задач.