Привет, Хабр! Представляю вашему вниманию перевод статьи «Плоскость данных Service Mesh и плоскость управления» автор Мэтт Кляйн .
На этот раз я «хотел и перевел» описание обоих компонентов сервисной сетки, плоскости данных и плоскости управления.
Это описание показалось мне самым понятным и интересным, а главное ведущим к пониманию «А нужно ли оно вообщеЭ» Поскольку идея «Сервисной сети» становится все более популярной в течение последних двух лет (Исходная статья от 10 октября 2017 г.
) и число участников пространства увеличивается, я наблюдаю соразмерное увеличение замешательства среди всего сообщества.
техническое сообщество о том, как сравнивать и противопоставлять различные решения.
Ситуацию лучше всего резюмирует следующая серия твитов, которые я написал в июле:
Путаница в Service Mesh №1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ни один из них не равен Istio. Istio — это нечто совершенно другое.1 /
Первые — это просто плоскости данных.Сами по себе они ничего не делают. Должно быть, они настроены на что-то большее.
2/
Istio — это пример плоскости управления, которая связывает части вместе.В предыдущих твитах упоминается несколько различных проектов (Linkerd, NGINX, HAProxy, Envoy и Istio), но, что более важно, представлены общие концепции плоскости данных, сервисной сетки и плоскости управления.Это еще один слой.
/конец
В этом посте я сделаю шаг назад и расскажу о том, что я подразумеваю под терминами «плоскость данных» и «плоскость управления» на очень высоком уровне, а затем расскажу о том, как эти термины применяются к проектам, упомянутым в твитах.
Что такое сервисная сетка на самом деле? 
Рисунок 1. Обзор Service Mesh. Изображение 1 иллюстрирует концепцию сервисной сети на самом базовом уровне.
Существует четыре сервисных кластера (AD).
Каждый экземпляр службы связан с локальным прокси-сервером.
Весь сетевой трафик (HTTP, REST, gRPC, Redis и т. д.) от одного экземпляра приложения передается через локальный прокси-сервер в соответствующие внешние кластеры служб.
Таким образом, экземпляр приложения не знает о сети в целом и знает только о своем локальном прокси-сервере.
По сути, сеть распределенной системы была удалена из обслуживания.
Плоскость данных В сервисной сетке прокси-сервер, расположенный локально для приложения, выполняет следующие задачи:
- Обнаружение службы .
Какие сервисы/приложения доступны для вашего приложения?
- Проверка здоровья .
Являются ли экземпляры службы, возвращенные службой обнаружения, работоспособными и готовыми к приему сетевого трафика? Это может включать как активные (например, ответ/проверка работоспособности), так и пассивные (например, использование 3 последовательных ошибок 5xx как индикатор неработоспособного состояния службы) проверки работоспособности.
- Маршрутизация .
В какой кластер служб следует отправить запрос при получении запроса на «/foo» от службы REST?
- Балансировка нагрузки .
Какому экземпляру службы следует отправить запрос после того, как во время маршрутизации выбран кластер служб? С каким таймаутом? С какими настройками отключения? Если запрос не удался, следует ли его повторить?
- Аутентификация и авторизация .
Для входящих запросов может ли вызывающая служба быть криптографически идентифицирована/авторизована с использованием mTLS или какого-либо другого механизма? Если он распознан/авторизован, разрешено ли ему вызывать запрошенную операцию (конечную точку) в службе или должен быть возвращен неаутентифицированный ответ?
- Наблюдаемость .
Подробная статистика, журналы/журналы и распределенные данные трассировки должны создаваться для каждого запроса, чтобы операторы могли понимать распределенный поток трафика и устранять проблемы по мере их возникновения.
Фактически, локальный для службы прокси (sidecar) — это плоскость данных.
Другими словами, плоскость данных отвечает за условную широковещательную рассылку, пересылку и мониторинг каждого сетевого пакета, который отправляется в службу или из нее.
Плоскость управления Сетевая абстракция, которую локальный прокси-сервер обеспечивает в плоскости данных, является волшебной (?).
Однако как прокси-сервер на самом деле узнает о маршруте «/foo» к службе B? Как можно использовать данные обнаружения служб, заполняемые прокси-запросами? Как настраиваются параметры балансировки нагрузки, таймаута, отключения цепи и т.д.? Как развернуть приложение, используя синий/зеленый метод или метод плавного перехода трафика? Кто настраивает общесистемные параметры аутентификации и авторизации? Все вышеперечисленные элементы находятся под контролем плоскости управления сервисной сетки.
Плоскость управления берет набор изолированных прокси без сохранения состояния и превращает их в распределенную систему.
.
Я думаю, что причина, по которой многие технологи сбивают с толку отдельные концепции плоскости данных и плоскости управления, заключается в том, что для большинства людей плоскость данных знакома, а плоскость управления чужая/непонятная.
Мы уже давно работаем с физическими сетевыми маршрутизаторами и коммутаторами.
Мы понимаем, что пакеты/запросы должны идти из точки А в точку Б и что для этого мы можем использовать аппаратное и программное обеспечение.
Новое поколение программных прокси — это просто причудливые версии инструментов, которые мы используем уже долгое время.
Рисунок 2: Плоскость управления человеком
Однако мы уже давно используем плоскости управления, хотя большинство сетевых операторов могут не связывать эту часть системы с каким-либо технологическим компонентом.
Причина проста: Большинство плоскостей управления, используемых сегодня,.
мы .
На фигура 2 показывает то, что я называю «плоскостью управления человеком».
При этом типе развертывания, который до сих пор очень распространен, вероятно, сварливый человек-оператор создает статические конфигурации (возможно, с помощью сценариев) и развертывает их с помощью специального процесса на всех прокси.
Затем прокси-серверы начинают использовать эту конфигурацию и начинают обработку плоскости данных с использованием обновленных настроек.
Рисунок 3. Плоскость управления расширенной сервисной сеткой.
На Рисунок 3 показывает «расширенную» плоскость управления сервисной сетки.
Он состоит из следующих частей:
- Человек : Ещё есть человек (надеюсь, менее злой), который принимает решения на высоком уровне относительно всей системы в целом.
- Пользовательский интерфейс плоскости управления : человек взаимодействует с пользовательским интерфейсом определенного типа для управления системой.
Это может быть веб-портал, приложение командной строки (CLI) или какой-либо другой интерфейс.
Используя пользовательский интерфейс, оператор имеет доступ к глобальным параметрам конфигурации системы, таким как:
- Контроль развертывания, синий/зеленый и/или постепенный переход трафика
- Параметры аутентификации и авторизации
- Спецификации таблицы маршрутизации, например, когда приложение A запрашивает информацию о «/foo», что происходит
- Настройки балансировщика нагрузки, такие как тайм-ауты, повторные попытки, настройки отключения цепи и т. д.
- Планировщик рабочей нагрузки : Сервисы выполняются в инфраструктуре с помощью какой-либо системы планирования/оркестрации, например Kubernetes или Nomad. Планировщик отвечает за загрузку службы вместе с ее локальным прокси.
- Обнаружение службы .
Когда планировщик запускает и останавливает экземпляры службы, он сообщает о состоянии работоспособности системе обнаружения служб.
- API настройки прокси-сервера Sidecar : Локальные прокси-серверы динамически извлекают состояние из различных компонентов системы, используя согласованную модель без вмешательства оператора.
Вся система, состоящая из всех запущенных в данный момент экземпляров сервисов и локальных прокси-серверов, в конечном итоге объединяется в одну экосистему.
Универсальный API плоскости данных Envoy — один из примеров того, как это работает на практике.
Более совершенные плоскости управления снимают с оператора больше частей некоторых систем и требуют меньше ручного управления, при условии, что они работают корректно!.
Плоскость данных и плоскость управления.
Сводная информация о плоскости данных и плоскости управления
- Плоскость данных сервисной сетки : влияет на каждый пакет/запрос в системе.
Отвечает за обнаружение приложений/сервисов, проверку работоспособности, маршрутизацию, балансировку нагрузки, аутентификацию/авторизацию и наблюдаемость.
- Плоскость управления сервисной сеткой : предоставляет политику и конфигурацию для всех работающих плоскостей данных в сервисной сети.
Не затрагивает никакие пакеты/запросы в системе.
Плоскость управления превращает все плоскости данных в распределенную систему.
- Плоскости данных : Linkerd, NGINX, HAProxy, Envoy, Traefik.
- Плоскости управления : Istio, Нельсон, SmartStack
Linkerd был одним из первых прокси-серверов плоскости данных для Service Mesh в начале 2016 года и проделал фантастическую работу по повышению осведомленности и внимания к модели проектирования Service Mesh. Примерно через 6 месяцев после этого Envoy присоединился к Linkerd (хотя в Lyft он работал с конца 2015 года).
Linkerd и Envoy — два проекта, которые чаще всего упоминаются при обсуждении сервисных сеток.
Об Istio было объявлено в мае 2017 года.
Цели проекта Istio очень похожи на расширенную плоскость управления, показанную на рис.
Рисунок 3 .
Envoy для Istio является прокси-сервером по умолчанию.
Таким образом, Istio — это плоскость управления, а Envoy — плоскость данных.
За короткое время Istio вызвал большой ажиотаж, и другие плоскости передачи данных начали интегрироваться в качестве замены Envoy (и Linkerd, и NGINX продемонстрировали интеграцию с Istio).
Тот факт, что в одной плоскости управления могут использоваться разные плоскости данных, означает, что плоскость управления и плоскость данных не обязательно тесно связаны.
API, такой как универсальный API плоскости данных Envoy, может стать мостом между двумя частями системы.
Нельсон и SmartStack помогают дополнительно проиллюстрировать разделение плоскостей управления и плоскостей данных.
Нельсон использует Envoy в качестве своего прокси и строит надежную плоскость управления сервисной сеткой на основе стека HashiCorp, т.е.
Nomad и т. д. SmartStack был, пожалуй, первым из новой волны сервисных сеток.
SmartStack строит плоскость управления на основе HAProxy или NGINX, демонстрируя возможность отделения плоскости управления от сервисной сетки и плоскости данных.
Микросервисная архитектура с сервисной сеткой привлекает все больше внимания (справедливо!), и все больше проектов и вендоров начинают работать в этом направлении.
В течение следующих нескольких лет мы увидим множество инноваций как в плоскости данных, так и в плоскости управления, а также дальнейшее смешивание различных компонентов.
В конечном итоге микросервисная архитектура должна стать более прозрачной и волшебной (?) для оператора.
Надеюсь, меньше и меньше раздражаюсь.
Ключевые выводы
- Сервисная сетка состоит из двух разных частей: плоскости данных и плоскости управления.
Оба компонента обязательны, без них система не будет работать.
- Все знакомы с плоскостью управления, и на данный момент плоскостью управления можете быть вы!
- Все плоскости данных конкурируют друг с другом по функциям, производительности, настраиваемости и расширяемости.
- Все плоскости управления конкурируют друг с другом по функциям, настраиваемости, расширяемости и простоте использования.
- Одна плоскость управления может содержать правильные абстракции и API, что позволяет использовать несколько плоскостей данных.
-
«Сделай Меня Красивой!» Выпуск №29
19 Oct, 24 -
Король Мертв! Да Здравствует…
19 Oct, 24 -
Круг Общения Замкнут
19 Oct, 24
