Прывітанне, Хабр! Уяўляю вашай увазе пераклад артыкула "Service mesh data plane vs 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) на самым базавым узроўні. Ёсць чатыры сэрвісных кластара (AD). Кожны асобнік сэрвісу злучаны з лакальным проксі серверам. Увесь сеткавы трафік (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 года). Лінкерд і 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