Хей Хабр! Представям на вашето внимание превода на статията „Сервизна мрежова равнина на данни срещу контролна равнина“ автор Matt Klein.

Този път „исках и преведох“ описанието на двата компонента на мрежовата услуга, равнината на данни и равнината на управление. Това описание ми се стори най-разбираемото и интересно и най-важното водещо до разбирането на „Необходимо ли е изобщо?“

Тъй като идеята за „сервизна мрежа“ стана все по-популярна през последните две години (Оригинална статия от 10 октомври 2017 г.) и броят на участниците в пространството се увеличи, видях пропорционално увеличение на объркването сред цялото техническа общност по отношение на това как да сравнявате и контрастирате различни решения.

Ситуацията е най-добре обобщена от следната поредица от туитове, които написах през юли:

Объркване на мрежата на услугата #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Никой от тях не е равен на Istio. Istio е нещо съвсем различно. 1 /

Първите са просто равнини за данни. Сами по себе си те не правят нищо. Трябва да са в настроение за нещо повече. 2/

Istio е пример за контролна равнина, която свързва частите заедно. Това е друг слой. /край

Предишните туитове споменават няколко различни проекта (Linkerd, NGINX, HAProxy, Envoy и Istio), но по-важното е, че въвеждат общите концепции за равнина на данни, мрежова мрежа за услуги и равнина на управление. В тази публикация ще направя крачка назад и ще говоря какво имам предвид под термините „равнина на данни“ и „равнина на управление“ на много високо ниво и след това ще говоря за това как термините се прилагат към проектите, споменати в туитове.

Какво всъщност е сервизна мрежа?

Фигура 1: Общ преглед на мрежата на услугата

Фигура 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, Nelson, SmartStack

Вместо да навлизам в задълбочен анализ на всяко от решенията по-горе, ще се спра накратко на някои от точките, които смятам, че причиняват голяма част от объркването в екосистемата в момента.

Linkerd беше един от първите прокси сървъри за равнина на данни за мрежата на услугите в началото на 2016 г. и свърши фантастична работа за повишаване на осведомеността и вниманието към модела на дизайн на мрежата на услугите. Около 6 месеца след това, Envoy се присъедини към Linkerd (въпреки че беше с Lyft от края на 2015 г.). Linkerd и Envoy са двата проекта, които най-често се споменават, когато се обсъждат сервизни мрежи.

Istio беше обявен през май 2017 г. Целите на проекта Istio са много подобни на разширената контролна равнина, показана в фигура 3. Envoy за Istio е проксито по подразбиране. Така Istio е контролната равнина, а Envoy е равнината на данните. За кратко време Istio предизвика много вълнение и други равнини на данни започнаха да се интегрират като заместител на Envoy (както Linkerd, така и NGINX демонстрираха интеграция с Istio). Фактът, че различни равнини на данни могат да се използват в една и съща контролна равнина, означава, че контролната равнина и равнината на данни не са непременно тясно свързани. API като общия API на равнината на данни на Envoy може да формира мост между две части на системата.

Nelson и SmartStack помагат да се илюстрира допълнително разделянето на контролната равнина и равнината на данните. Nelson използва Envoy като свой прокси и изгражда надеждна контролна равнина за мрежовата мрежа на услугата, базирана на стека HashiCorp, т.е. Номад и др. SmartStack беше може би първият от нова вълна сервизни мрежи. SmartStack изгражда контролна равнина около HAProxy или NGINX, демонстрирайки способността за отделяне на контролната равнина от сервизната мрежа от равнината на данни.

Архитектурата на микросервизите със сервизна мрежа привлича все повече внимание (с право!) и все повече проекти и доставчици започват да работят в тази посока. През следващите няколко години ще видим много иновации както в равнината на данни, така и в равнината на управление, както и по-нататъшно смесване на различни компоненти. В крайна сметка архитектурата на микросервизите трябва да стане по-прозрачна и магическа (?) за оператора.
Дано все по-малко се дразни.

Ключови изводи

• Сервизната мрежа се състои от две различни части: равнина на данни и равнина на управление. И двата компонента са задължителни и без тях системата няма да работи.
• Всеки е запознат с контролната равнина и в този момент контролната равнина може да сте вие!
• Всички равнини на данни се конкурират помежду си по характеристики, производителност, конфигурируемост и разширяемост.
• Всички контролни равнини се конкурират помежду си по отношение на характеристиките, конфигурируемостта, разширяемостта и лекотата на използване.
• Една контролна равнина може да съдържа правилните абстракции и API, така че да могат да се използват множество равнини на данни.

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