Здравей, Хабр! Представям ви превода на статията «Данен план на услугите срещу контролен план» автора Мат Клайн.

В този случай реших да преведа описанието на двата компонента на услугите в мрежата, данението и контролния план. Това описание ми се стори най-разбираемо и интересно, а най-важното е, че подхожда на разбирането на въпроса «Нужно ли е изобщо?».

Тъй като идеята за «Услугова мрежа (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)» на много високо ниво, а след това ще обясня как термините се отнасят към проектите, споменати в туитите.

Каква е услугова мрежа (Какво е услугова мрежа наистина)?

Рисунок 1: Преглед на услугова мрежа (Преглед на услугова мрежа)

Рисунок 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)

Мрежовата абстракция, която локалният прокси предоставя в данъчната плоскост, е магическа (?). Въпреки това, как прокси сървърът всъщност научава маршрута «/foo» към услугата B? Как данните от откритията на услугите, които се попълват от прокси исканията, могат да бъдат използвани? Как се настройват параметрите за баланс на натоварването, тайм аута, прекъсвания и т.н.? Как се извършва разгръщането на приложението, използвайки метода синьо/зелено или метода на постепенното пренасочване на трафика? Кой настройва параметрите за общата система за автентикация и авторизация?

Всички изброени по-горе точки принадлежат на контролната плоскост на мрежата за услуги. Контролният панел приема набор от изолирани прокситасървъри без състояние и ги преобразува в разпределена система..

Мисля, че причината, поради която много технологични специалисти намират разделените концепции на данъчната плоскост и контролната плоскост за объркващи, е, че за повечето хора данъчната плоскост е позната, докато контролната плоскост е чужда/неразбираема. Отдавна работим с физически мрежови маршрутизатори и комутатори. Разбираме, че пакетите/исканията трябва да преминат от точка А до точка Б, и какво можем да използваме за това хардвер и софтуер. Новото поколение софтуерни проксита просто са модни версии на инструментите, които използваме от дълго време.

Фигура 2: Човешка контролна плоскост

Въпреки това, ние дълго време сме използвали контролни плоскости, макар че повечето мрежови оператори може да не свързват тази част от системата с какъвто и да е технологичен компонент. Причината за това е проста:
Повечето от контролни плоскости, използвани днес, са... ние.

На на фигура 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)

• Данната площ на мрежата за услуги (Service mesh data plane): засяга всеки пакет / заявка в системата. Отговаря за откритие на приложения/услуги, проверка на работоспособността, маршрутизация, разпределяне на натоварването, удостоверяване / авторизация и наблюдаемост.
• Контролният слой на мрежата за услуги (Service mesh control plane): предоставя политика и конфигурация за всички работещи данни площи в рамките на мрежата за услуги. Не засяга никакви пакети / заявки в системата. Контролният слой превръща всички данни площи в разпределена система.

Текущото състояние на проекта (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 година). Linkerd и 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).

Източник: habr.com