Привет, Хабр! Представляю вашему вниманию перевод статьи «Service mesh data plane vs control plane» автора Matt Klein.
В этот раз «захотелось и перевелось» описание обоих компонентов service mesh, data plane и control plane. Это описание мне показалось самым понятным и интересным, а главное подводящим к пониманию «А нужно ли оно вообще?».
Поскольку идея «Сервисной сети (Service mesh)» становится все более популярной в течение последних двух лет (Оригинальная статья от 10 октября 2017), а число участников в пространстве возросло, я увидел соразмерный рост путаницы среди всего технического сообщества в отношении того, как сравнивать и противопоставлять разные решения.
Ситуацию лучше всего описать следующими сериями твитов, которые я написал в июле:
Рисунок 1: Обзор сервисной сети (Service mesh overview)
Рисунок 1 иллюстрирует концепцию сервисной сети (service mesh) на самом базовом уровне. Есть четыре сервисных кластера (A-D). Каждый экземпляр сервиса связан с локальным прокси сервером. Весь сетевой трафик (HTTP, REST, gRPC, Redis и т. Д.) от отдельного экземпляра приложения передается через локальный прокси-сервер в соответствующие внешние сервисные кластеры. Таким образом, экземпляр приложения не знает о сети в целом и знает только о своем локальном прокси. Фактически, сеть распределенной системы была удалена от сервиса.
В сервисной сети (service mesh) прокси-сервер, расположенный локально для приложения, выполняет следующие задачи:
За все предыдущие пункты в сервисной сети (service mesh), отвечает плоскость данных (data plane). По сути, локальный для сервиса (sidecar) прокси и является плоскостью данных (data plane). Иными словами, плоскость данных (data plane) отвечает за условную трансляцию, пересылку и наблюдение за каждым сетевым пакетом, который присылается в сервис или отсылается из него.
Сетевая абстракция, которую обеспечивает локальный прокси в плоскости данных (data plane), является волшебной (?). Тем не менее, как прокси-сервер на самом деле узнает о маршруте "/foo" к сервису B? Как данные обнаружения сервисов (service discovery), которые заполняются прокси-запросами, могут быть использованы? Как настроены параметры балансировки нагрузки, таймаута (timeout), обрыва цепи (circuit breaking) и т.д.? Как осуществляется развертывание приложения с использованием синего/зеленого (blue/green) метода или метода постепенного перевода трафика? Кто настраивает параметры общесистемной аутентификации и авторизации?
Все вышеперечисленные пункты находятся в ведении плоскости управления (control plane) сервисной сети (service mesh). Плоскость управления (control plane) принимает набор изолированных прокси-серверов без состояния и превращает их в распределенную систему.
Я думаю, что причина, по которой многие технологи находят запутанными разделенные понятия плоскости данных (data plane) и плоскости управления (control plane), заключается в том, что для большинства людей плоскость данных знакома, в то время как плоскость управления чужеродна/непонятна. Мы уже давно работаем с физическими сетевыми маршрутизаторами и коммутаторами. Мы понимаем, что пакеты/запросы должны идти из пункта А в пункт Б, и что мы можем использовать для этого аппаратное и программное обеспечение. Новое поколение программных прокси — это просто модные версии инструментов, которые мы использовали в течение долгого времени.
Рисунок 2: Человеческая плоскость управления (Human control plane)
Однако, мы уже долгое время использовали плоскости управления (control plane), хотя большинство сетевых операторов могут не связывать эту часть системы с каким-либо технологическим компонентом. Причина этого проста:
Большинство используемых сегодня плоскостей управления (control plane) -это… мы.
На рисунке 2 показано то, что я называю «Человеческой плоскостью управления (Human control plane)». В этом типе развертывания, которое все еще встречается очень часто, человек-оператор, вероятно сварливый, создает статические конфигурации — потенциально, с п��мощью скриптов — и развертывает их с помощью какого-то специального процесса на всех прокси-серверах. Затем прокси начинают использовать эту конфигурацию и приступают к обработке плоскости данных (data plane) с использованием обновленных настроек.
Рисунок 3: Расширенная плоскость управления сервисной сетью (Advanced service mesh control plane)
На рисунке 3 показана «расширенная» плоскость управления (control plane) сервисной сети (service mesh). Она состоит из следующих частей:
По сути, цель плоскости управления (control plane) состоит в том, чтобы установить политику, которая в конечном итоге будет принята плоскостью данных (data plane). Более совершенные плоскости управления (control plane) уберут от оператора больше деталей некоторых систем и потребуют меньше ручного управления, при условии, что они работают правильно!..
Разобравшись с объяснением выше, давайте посмотрим на текущее состояние проекта «сервисной сети (service mesh)».
Вместо того, чтобы проводить углубленный анализ каждого из вышеперечисленных решений, я кратко остановлюсь на некоторых моментах, которые, по моему мнению, вызывают большую часть путаницы в экосистеме прямо сейчас.
В начале 2016 года Linkerd был одним из первых прокси-серверов плоскости данных (data plane) для сервисной сети (service mesh) и проделал фантастическую работу по повышению осведомленности и увеличению внимания к модели проектирования «сервисная сеть» (service mesh). Примерно через 6 месяцев после этого Envoy присоединился к Linkerd (хотя работал в Lyft с конца 2015 года). Линкерд и Envoy — это два проекта, которые чаще всего упоминаются при обсуждении сервисных сетей (service mesh).
Istio было объявлено в мае 2017 года. Цели проекта Istio очень похожи на расширенную плоскость управления (control plane), показанную на рисунке 3. Envoy для Istio является прокси-сервером «по умолчанию». Таким образом, Istio является плоскостью управления (control plane), а Envoy — плоскостью данных (data plane). За короткое время Istio вызвало много волнений, и другие плоскости данных (data plane) начали интеграцию в качестве замены Envoy (и Linkerd, и NGINX продемонстрировали интеграцию с Istio). Тот факт, что в одной плоскости управления (control plane) можно использовать разные плоскости данных (data plane), означает, что плоскость управления (control plane) и плоскость данных (data plane) не обязательно тесно связаны. Такой API как универсальный API плоскости данных (data plane) Envoy может образовывать мост между двумя частями системы.
Nelson и SmartStack помогают дополнительно проиллюстрировать разделение плоскости управления (control plane) и плоскости данных (data plane). Nelson использует Envoy в качестве своего прокси и строит надежную плоскость управления (control plane) сервисной сетью (service mesh) на базе стека HashiCorp, т.е. Nomad и т.д. SmartStack стал, пожалуй, первым из новой волны сервисных сетей (service mesh). SmartStack формирует плоскость управлен��я (control plane) вокруг HAProxy или NGINX, демонстрируя возможность развязки плоскости управления (control plane) сервисной сетью (service mesh) и плоскости данных (data plane).
Микросервисная архитектура с сервисной сетью (service mesh) привлекает к себе все больше внимания (правильно!), и все больше проектов и вендоров начинают работать в этом направлении. В течение следующих нескольких лет мы увидим много инноваций как в плоскостях данных (data plane), так и в плоскостях управления (control plane), а также дальнейшее смешивание различных компонентов. В конечным счете микросервисная архитектура должна стать более прозрачной и волшебной (?) для оператора.
Надеюсь, все менее и менее раздраженного.
В этот раз «захотелось и перевелось» описание обоих компонентов service mesh, data plane и control plane. Это описание мне показалось самым понятным и интересным, а главное подводящим к пониманию «А нужно ли оно вообще?».
Поскольку идея «Сервисной сети (Service mesh)» становится все более популярной в течение последних двух лет (Оригинальная статья от 10 октября 2017), а число участников в пространстве возросло, я увидел соразмерный рост путаницы среди всего технического сообщества в отношении того, как сравнивать и противопоставлять разные решения.
Ситуацию лучше всего описать следующими сериями твитов, которые я написал в июле:
Путаница с сервисной сетью (service mesh) № 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ни один из них не равен Istio. Istio — это нечто совсем другое. 1 /
Первые просто плоскости данных (data planes). Сами по себе они ничего не делают. Они должны быть настроены на ��то-то большее. 2 /
Istio является примером плоскости управления (control plane), которая связывает части вместе вместе. Это другой слой. /конецВ предыдущих твитах упоминается несколько разных проектов (Linkerd, NGINX, HAProxy, Envoy и Istio), но, что более важно, вводятся общие понятия плоскости данных (data plane), сервисной сети (service mesh) и плоскости управления (control plane). В этом посте я сделаю шаг назад и расскажу, что я имею в виду под терминами «плоскость данных (data plane)» и «плоскость управления (control plane)» на очень высоком уровне, а затем расскажу, как термины относятся к проектам, упомянутым в твитах.
Что такое сервисная сеть (What is a service mesh, really)?
Рисунок 1: Обзор сервисной сети (Service mesh overview)
Рисунок 1 иллюстрирует концепцию сервисной сети (service mesh) на самом базовом уровне. Есть четыре сервисных кластера (A-D). Каждый экземпляр сервиса связан с локальным прокси сервером. Весь сетевой трафик (HTTP, REST, gRPC, Redis и т. Д.) от отдельного экземпляра приложения передается через локальный прокси-сервер в соответствующие внешние сервисные кластеры. Таким образом, экземпляр приложения не знает о сети в целом и знает только о своем локальном прокси. Фактически, сеть распределенной системы была удалена от сервиса.
Плоскость данных (Data plane)
В сервисной сети (service mesh) прокси-сервер, расположенный локально для приложения, выполняет следующие задачи:
- Обнаружение сервисов (Service discovery). Какие сервисы/службы/приложения доступны для вашего приложения?
- Проверка работоспособности (Health checking). Являются ли экземпляры сервисов, возвращенные обнаружением сервисов (service discovery), работоспособными и готовы ли принимать сетевой трафик? Это может включать как активную (например, проверка ответа / healthcheck), так и пассивную (например, с использованием 3 последовательных 5xx ошибок в качестве индикации нездорового состояния сервиса) проверки работоспособности.
- Маршрутизация (Routing). Получив от сервиса REST запрос к "/foo", в какой сервисный кластер следует отправлять запрос?
- Балансировка нагрузки (Load balancing). После того как во время маршрутизации был выбран кластер сервиса, в какой экземпляр сервиса должен быть отправлен запрос? С каким таймаутом? С какими настройками обрыва цепи (circuit breaking)? Если запрос не удался, его следует повторить?
- Аутентификация и авторизация (Authentication and authorization). Для входящих запросов может ли вызывающий сервис быть криптографически опознан/авторизован с помощью mTLS или какого-либо другого механизма? Если он опознан/авторизован, разрешено ли ему вызывать запрошенную операцию (endpoint) в сервисе или должен быть возвращен неаутентифицированный ответ?
- Наблюдаемость (Observability). Для каждого запроса должны быть сгенерированы подробные статистические данные, журналы/логи и данные распределенной трассировки, чтобы операторы могли понимать распределенный поток трафика и проблемы отладки по мере их возникновения.
За все предыдущие пункты в сервисной сети (service mesh), отвечает плоскость данных (data plane). По сути, локальный для сервиса (sidecar) прокси и является плоскостью данных (data plane). Иными словами, плоскость данных (data plane) отвечает за условную трансляцию, пересылку и наблюдение за каждым сетевым пакетом, который присылается в сервис или отсылается из него.
Плоскость управления (The control plane)
Сетевая абстракция, которую обеспечивает локальный прокси в плоскости данных (data plane), является волшебной (?). Тем не менее, как прокси-сервер на самом деле узнает о маршруте "/foo" к сервису B? Как данные обнаружения сервисов (service discovery), которые заполняются прокси-запросами, могут быть использованы? Как настроены параметры балансировки нагрузки, таймаута (timeout), обрыва цепи (circuit breaking) и т.д.? Как осуществляется развертывание приложения с использованием синего/зеленого (blue/green) метода или метода постепенного перевода трафика? Кто настраивает параметры общесистемной аутентификации и авторизации?
Все вышеперечисленные пункты находятся в ведении плоскости управления (control plane) сервисной сети (service mesh). Плоскость управления (control plane) принимает набор изолированных прокси-серверов без состояния и превращает их в распределенную систему.
Я думаю, что причина, по которой многие технологи находят запутанными разделенные понятия плоскости данных (data plane) и плоскости управления (control plane), заключается в том, что для большинства людей плоскость данных знакома, в то время как плоскость управления чужеродна/непонятна. Мы уже давно работаем с физическими сетевыми маршрутизаторами и коммутаторами. Мы понимаем, что пакеты/запросы должны идти из пункта А в пункт Б, и что мы можем использовать для этого аппаратное и программное обеспечение. Новое поколение программных прокси — это просто модные версии инструментов, которые мы использовали в течение долгого времени.
Рисунок 2: Человеческая плоскость управления (Human control plane)
Однако, мы уже долгое время использовали плоскости управления (control plane), хотя большинство сетевых операторов могут не связывать эту часть системы с каким-либо технологическим компонентом. Причина этого проста:
Большинство используемых сегодня плоскостей управления (control plane) -это… мы.
На рисунке 2 показано то, что я называю «Человеческой плоскостью управления (Human control plane)». В этом типе развертывания, которое все еще встречается очень часто, человек-оператор, вероятно сварливый, создает статические конфигурации — потенциально, с п��мощью скриптов — и развертывает их с помощью какого-то специального процесса на всех прокси-серверах. Затем прокси начинают использовать эту конфигурацию и приступают к обработке плоскости данных (data plane) с использованием обновленных настроек.
Рисунок 3: Расширенная плоскость управления сервисной сетью (Advanced service mesh control plane)
На рисунке 3 показана «расширенная» плоскость управления (control plane) сервисной сети (service mesh). Она состоит из следующих частей:
- Человек (The human): Все еще есть человек (надеюсь, менее сердитый), который принимает решения на высоком уровне в отношении всей системы в целом.
- Пользовательский интерфейс плоскости управления (Control plane UI): Человек взаимодействует с каким-либо типом пользовательского интерфейса для управления системой. Это может быть веб-портал, приложение командной строки (CLI) или какой-то другой интерфейс. С помощью пользовательского интерфейса оператор имеет доступ к таким глобальным параметрам конфигурации системы, как:
- Управление развертыванием, синий/зеленый (blue/green) и/или с постепенным перевода трафика
- Параметры аутентификации и авторизации
- Спецификации таблицы маршрутизации, например, когда приложение A запрашивает информацию о "/foo", что происходит
- Настройки балансировщика нагрузки, например, таймауты (timeouts), повторные попытки (retries), параметры обрыва цепи (circuit breaking) и т.д.
- Планировщик рабочей нагрузки (Workload scheduler): Сервисы запускаются в инфраструктуре через систему планирования/оркестрации определенного типа, например, Kubernetes или Nomad. Планировщик отвечает за загрузку службы вместе с ее локальным прокси-сервером.
- Обнаружение сервиса (Service discovery). Когда планировщик запускает и останавливает экземпляры сервиса, он сообщает о состоянии работоспособности в систему обнаружения сервиса.
- API конфигурации локального прокси-сервера (Sidecar proxy configuration APIs) : Локальные прокси-серверы динамически извлекают состояние из различных компонентов системы по модели «согласованность в конечном счёте» (eventually consistent) без участия оператора. Вся система, состоящая из всех запущенных на данный момент экземпляров сервисов и локальных прокси-серверов, в конечном итоге сходится в одну экосистему. API универсальной плоскости данных (data plane) в Envoy является одним из примеров того, как это работает на практике.
По сути, цель плоскости управления (control plane) состоит в том, чтобы установить политику, которая в конечном итоге будет принята плоскостью данных (data plane). Более совершенные плоскости управления (control plane) уберут от оператора больше деталей некоторых систем и потребуют меньше ручного управления, при условии, что они работают правильно!..
Плоскость данных и плоскость управления. Сводка (Data plane vs. control plane summary)
- Плоскость данных cервисной сети (Service mesh data plane): затрагивает каждый пакет / запрос в системе. Отвечает за обнаружение приложенией/сервисов, проверку работоспособности, маршрутизацию, распределение нагрузки, аутентификацию / авторизацию и наблюдаемость.
- Плоскость управления cервисной сети (Service mesh control plane): предоставляет политику и конфигурацию для всех работающих плоскостей данных внутри cервисной сети. Не трогает никаких пакетов / запросов в системе. Плоскость управления превращает все плоскости данных в распределенную систему.
Текущее состояние проекта (Current project landscape)
Разобравшись с объяснением выше, давайте посмотрим на текущее состояние проекта «сервисной сети (service mesh)».
- Плоскости данных (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
- Плоскости управления (Control planes): Istio, Nelson, SmartStack
Вместо того, чтобы проводить углубленный анализ каждого из вышеперечисленных решений, я кратко остановлюсь на некоторых моментах, которые, по моему мнению, вызывают большую часть путаницы в экосистеме прямо сейчас.
В начале 2016 года Linkerd был одним из первых прокси-серверов плоскости данных (data plane) для сервисной сети (service mesh) и проделал фантастическую работу по повышению осведомленности и увеличению внимания к модели проектирования «сервисная сеть» (service mesh). Примерно через 6 месяцев после этого Envoy присоединился к Linkerd (хотя работал в Lyft с конца 2015 года). Линкерд и Envoy — это два проекта, которые чаще всего упоминаются при обсуждении сервисных сетей (service mesh).
Istio было объявлено в мае 2017 года. Цели проекта Istio очень похожи на расширенную плоскость управления (control plane), показанную на рисунке 3. Envoy для Istio является прокси-сервером «по умолчанию». Таким образом, Istio является плоскостью управления (control plane), а Envoy — плоскостью данных (data plane). За короткое время Istio вызвало много волнений, и другие плоскости данных (data plane) начали интеграцию в качестве замены Envoy (и Linkerd, и NGINX продемонстрировали интеграцию с Istio). Тот факт, что в одной плоскости управления (control plane) можно использовать разные плоскости данных (data plane), означает, что плоскость управления (control plane) и плоскость данных (data plane) не обязательно тесно связаны. Такой API как универсальный API плоскости данных (data plane) Envoy может образовывать мост между двумя частями системы.
Nelson и SmartStack помогают дополнительно проиллюстрировать разделение плоскости управления (control plane) и плоскости данных (data plane). Nelson использует Envoy в качестве своего прокси и строит надежную плоскость управления (control plane) сервисной сетью (service mesh) на базе стека HashiCorp, т.е. Nomad и т.д. SmartStack стал, пожалуй, первым из новой волны сервисных сетей (service mesh). SmartStack формирует плоскость управлен��я (control plane) вокруг HAProxy или NGINX, демонстрируя возможность развязки плоскости управления (control plane) сервисной сетью (service mesh) и плоскости данных (data plane).
Микросервисная архитектура с сервисной сетью (service mesh) привлекает к себе все больше внимания (правильно!), и все больше проектов и вендоров начинают работать в этом направлении. В течение следующих нескольких лет мы увидим много инноваций как в плоскостях данных (data plane), так и в плоскостях управления (control plane), а также дальнейшее смешивание различных компонентов. В конечным счете микросервисная архитектура должна стать более прозрачной и волшебной (?) для оператора.
Надеюсь, все менее и менее раздраженного.
Ключевые моменты (Key takeaways)
- Сервисная сеть (service mesh) состоит из двух разных частей: плоскости данных (data plane) и плоскости управления (control plane). Оба компонента обязательны, и без них система не будет работать.
- Все знакомы с плоскостью управления (control plane), и на данный момент плоскостью управления (control plane) можете быть вы!
- Все плоскости данных (data plane) конкурируют между собой по функциям, производительности, конфигурируемости и расширяемости.
- Все плоскости управления (control plane) конкурируют между собой по функциям, конфигурируемости, расширяемости и удобству использования.
- Одна плоскость управления (control plane) может содержать правильные абстракции и API, чтобы можно было использовать несколько плоскостей данных (data plane).
