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

В този случай «пожела и се преведе» описанието на двата компонента на сервизната мрежа – данни плейн и контролен плейн. Това описание ми се стори най-разбираемо и интересно, а най-важното – подводещо към осъзнаването на въпроса: «А нужно ли е изобщо?»

Тъй като идеята за «Сервизна мрежа (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: Преглед на сервизната мрежа (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)

Плоскост на данни на сервизната мрежа (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