Заўв. перав.: гэты матэрыял ад адукацыйнага праекта - адказ на папулярнае пытанне пры праектаванні інфраструктуры на базе Kubernetes. Спадзяемся, што дастаткова разгорнутыя апісанні плюсаў і мінусаў кожнага з варыянтаў дапамогуць зрабіць аптымальны выбар і для вашага праекта.
TL, д-р: адзін і той жа набор працоўных нагрузак можна запусціць на некалькіх буйных кластарах (на кожны кластар будзе прыходзіцца вялікі лік workload'ов) або на мностве дробных (з малым лікам нагрузак у кожным кластары).
Ніжэй прыведзена табліца, у якой ацэньваюцца плюсы і мінусы кожнага падыходу:
Пры выкарыстанні Kubernetes у якасці платформы для эксплуатацыі прыкладанняў часта ўзнікаюць некалькі фундаментальных пытанняў аб тонкасцях налады кластараў:
- Які лік кластараў выкарыстоўваць?
- Наколькі буйнымі іх рабіць?
- Што павінен уключаць кожны кластар?
У гэтым артыкуле я паспрабую адказаць на ўсе гэтыя пытанні, прааналізаваўшы плюсы і мінусы кожнага падыходу.
пастаноўка пытання
Як стваральнік ПЗ, вы хутчэй за ўсё паралельна распрацоўваеце і эксплуатуеце мноства прыкладанняў.
Акрамя таго, мноства асобнікаў гэтых прыкладанняў напэўна запускаюцца ў розных асяродках - да прыкладу, гэта могуць быць DEV, тэст и prod.
У выніку атрымліваецца цэлая матрыца з прыкладанняў і асяроддзяў:
Прыкладання і асяроддзі
У прыведзеным вышэй прыкладзе прадстаўлены 3 прыкладанні і 3 асяроддзі, што ў выніку дае 9 магчымых варыянтаў.
Кожны асобнік прыкладання ўяўляе сабой самадастатковую deployment-адзінку, з якой можна працаваць незалежна ад іншых.
Звярніце ўвагу, што экзэмпляр прыкладання можа складацца з мноства кампанентаў, такіх як фронтэнд, бэкенд, база дадзеных і г.д. У выпадку мікрасэрвіснага дадатку экзэмпляр будзе ўключаць у сябе ўсе мікрасэрвісы.
У выніку ў карыстальнікаў Kubernetes узнікаюць некалькі пытанняў:
- Ці варта размяшчаць усе асобнікі дадатку ў адным кластары?
- Ці варта заводзіць асобны кластар пад кожны асобнік дадатку?
- Ці, магчыма, варта карыстацца камбінацыяй вышэйпералічаных падыходаў?
Усе гэтыя варыянты цалкам жыццяздольныя, паколькі Kubernetes - гэта гнуткая сістэма, якая не абмяжоўвае карыстальніка ў магчымасцях.
Вось некаторыя з магчымых шляхоў:
- адзін вялікі агульны кластар;
- мноства невялікіх вузкаспецыялізаваных кластараў;
- адзін кластар на кожнае прыкладанне;
- адзін кластар на кожнае асяроддзе.
Як паказана ніжэй, першыя два падыходы знаходзяцца на супрацьлеглых канцах шкалы варыянтаў:
Ад некалькіх вялікіх кластараў (злева) да мноства маленькіх (справа)
У агульным выпадку лічыцца, што адзін кластар "больш" іншага калі ў яго больш сума вузлоў і pod'аў. Напрыклад, кластар з 10-ю вузламі і 100 pod'амі больш кластара з 1-м вузлом і 10-ю pod'амі.
Што ж, давайце пачнем!
1. Адзін вялікі агульны кластар
Першы варыянт - размясціць усе працоўныя нагрузкі ў адным кластары:
Адзін вялікі кластар
У рамках гэтага падыходу кластар выкарыстоўваецца як універсальная інфраструктурная платформа - усё неабходнае вы проста разгортваеце ў існуючым кластары Kubernetes.
Kubernetes дазваляюць лагічна аддзяліць часткі кластара адзін ад аднаго, так што для кожнага асобніка прыкладання можна выкарыстоўваць сваю прастору імёнаў.
Давайце разгледзім плюсы і мінусы гэтага падыходу.
+ Эфектыўнае выкарыстанне рэсурсаў
У выпадку адзінага кластара спатрэбіцца толькі адна копія ўсіх рэсурсаў, неабходных для запуску кластара Kubernetes і кіраванне ім.
Напрыклад, гэта справядліва для майстар-вузлоў. Звычайна на кожны кластар Kubernetes прыходзіцца па 3 майстар-вузла, таму для аднаго адзінага кластара іх лік такім і застанецца (для параўнання, 10 кластарам спатрэбяцца 30 майстар-вузлоў).
Вышэйназваная тонкасць ставіцца і іншым сэрвісам, якія функцыянуюць у маштабах усяго кластара, такім як балансавальнікі нагрузкі, кантролеры Ingress, сістэмы аўтэнтыфікацыі, лагіравання і маніторынгу.
У адзіным кластары ўсе гэтыя сэрвісы можна выкарыстоўваць адразу для ўсіх працоўных нагрузак (не трэба ствараць іх копіі, як у выпадку некалькіх кластараў).
+ Таннасць
Як следства вышэйпададзенага, меншая колькасць кластараў звычайна абыходзіцца танней, паколькі адсутнічаюць выдаткі на залішнія рэсурсы.
Гэта асабліва справядліва для майстар-вузлоў, якія могуць каштаваць значных грошай незалежна ад спосабу размяшчэння (on-premises ці ў воблаку).
Некаторыя кіраваныя (managed) сэрвісы Kubernetes, такія як або , падаюць кіраўнік пласт бясплатна. У дадзеным выпадку пытанне затрат варта менш востра.
Таксама існуюць managed-сэрвісы, якія спаганяюць фіксаваную плату за працу кожнага кластара Kubernetes (напрыклад, ).
+ Эфектыўнае адміністраванне
Кіраваць адным кластарам прасцей, чым некалькімі.
Адміністраванне можа ўключаць у сябе наступныя задачы:
- абнаўленне версіі Kubernetes;
- настройка канвеера CI/CD;
- усталёўка плагіна CNI;
- настройка сістэмы аўтэнтыфікацыі карыстальнікаў;
- усталёўка кантролера допуску;
и многие другие…
У выпадку аднаго кластара займацца ўсім гэтым давядзецца толькі адзін раз.
Для мноства кластараў аперацыі прыйдзецца паўтараць шматкроць, што, верагодна, запатрабуе нейкай аўтаматызацыі працэсаў і прылад, каб забяспечыць сістэматычнасць і аднастайнасць працэсу.
А зараз некалькі слоў аб мінусах.
− Адзіны пункт адмовы
У выпадку адмовы адзінага кластара перастануць працаваць адразу ўсё працоўныя нагрузкі!
Існуе маса варыянтаў, калі нешта можа пайсці не так:
- абнаўленне Kubernetes прыводзіць да нечаканых пабочных эфектаў;
- агульнакластарны кампанент (напрыклад, убудова CNI) пачынае працаваць не так, як чакалася;
- адзін з кампанентаў кластара настроены няправільна;
- збой у ніжэйлеглай інфраструктуры.
Адзін такі інцыдэнт можа нанесці сур'ёзныя страты ўсім працоўным нагрузкам, размешчаным у агульным кластары.
− Адсутнасць жорсткай ізаляцыі
Праца ў агульным кластары азначае, што прыкладанні сумесна выкарыстоўваюць апаратнае забеспячэнне, сеткавыя магчымасці і аперацыйную сістэму на вузлах кластара.
У вызначаным сэнсе два кантэйнера з двума рознымі прыкладаннямі, якія працуюць на адным і тым жа вузле, падобныя да двух працэсаў, якія працуюць на адной і той жа машыне пад кіраваннем аднаго і таго ж ядра АС.
Кантэйнеры Linux забяспечваюць некаторую форму ізаляцыі, але яна далёка не такая моцная, як тая, якую забяспечваюць, скажам, віртуальныя машыны. У сутнасці, працэс у кантэйнеры - гэта той жа працэс, запушчаны ў аперацыйнай сістэме хаста.
Гэта можа стаць праблемай з пункту гледжання бяспекі: падобная арганізацыя тэарэтычна дазваляе незвязаным дадаткам ўзаемадзейнічаць адзін з адным (наўмысна або выпадкова).
Акрамя таго, усе працоўныя нагрузкі ў кластары Kubernetes сумесна выкарыстоўваюць некаторыя агульнакластарныя сэрвісы, такія як - гэта дазваляе прыкладанням знаходзіць Service'ы іншых прыкладанняў у кластары.
Усе вышэйпералічаныя пункты могуць мець рознае значэнне ў залежнасці ад патрабаванняў, што прад'яўляюцца да бяспекі прыкладанняў.
Kubernetes дае розныя інструменты для прадухілення праблем у сістэме бяспекі, такія як и . Аднак для іх правільнай налады патрабуецца вызначаны досвед акрамя таго, яны не ў стане зачыніць абсалютна ўсе дзюры ў бяспецы.
Важна заўсёды памятаць, што Kubernetes першапачаткова распрацаваны для сумеснага выкарыстання, а не для ізаляцыі і бяспекі.
− Адсутнасць жорсткай multi-tenancy
Улічваючы багацце агульных рэсурсаў у кластары Kubernetes, існуе мноства спосабаў, якімі розныя прыкладанні могуць "наступаць адзін аднаму на пяткі".
Напрыклад, прыкладанне можа манапалізаваць нейкі агульны рэсурс (накшталт працэсара або памяці) і пазбавіць іншыя прыкладанні, якія працуюць на тым жа вузле, доступу да яго.
Kubernetes забяспечвае розныя механізмы кантролю за падобнымі паводзінамі, такія як (гл. таксама артыкул «» - заўв. перав.), и . Аднак, як і ў выпадку бяспекі, іх настройка дастаткова нетрывіяльная і яны не здольныя прадухіліць абсалютна ўсе непрадбачаныя пабочныя эфекты.
− Вялікая колькасць карыстальнікаў
У выпадку адзінага кластара даводзіцца адчыняць доступ да яго мноству людзей. І чым больш значны іх лік, тым вышэй рызыка таго, што яны што-небудзь «зламаюць».
Унутры кластара можна кантраляваць, хто і што можа рабіць з дапамогай (гл. артыкул «» - заўв. перав.). Зрэшты, яно не перашкодзіць карыстальнікам "зламаць" нешта ў межах сваёй зоны адказнасці.
− Кластары не могуць расці да бясконцасці
Кластар, які выкарыстоўваецца для ўсіх працоўных нагрузак, будзе, верагодна, вельмі вялікім (па ліку вузлоў і pod'ов).
Але тут узнікае іншая праблема: кластары ў Kubernetes не могуць расці да бясконцасці.
Існуе тэарэтычны мяжа на памер кластара. У Kubernetes ён складае прыкладна .
Аднак у рэальным жыцці праблемы могуць пачацца значна раней - напрыклад, усяго пры .
Справа ў тым, што буйныя кластары аказваюць высокую нагрузку на кіруючы пласт Kubernetes. Іншымі словамі, каб падтрымліваць кластар у працоўным стане і эфектыўна выкарыстоўваць рэсурсы, патрабуецца старанная настройка.
Гэтая праблема вывучаецца ў адпаведным артыкуле ў арыгінальным блогу пад назвай «.
Але давайце разгледзім супрацьлеглы падыход: мноства дробных кластараў.
2. Мноства невялікіх, спецыялізаваных кластараў
Пры дадзеным падыходзе вы выкарыстоўваеце асобны кластар для кожнага элемента, які разгортваецца:
Мноства дробных кластараў
Для мэт гэтага артыкула пад разгортваемым элементам разумеецца асобнік прыкладання - напрыклад, dev-версія асобнага прыкладання.
У дадзенай стратэгіі Kubernetes выкарыстоўваецца як спецыялізаваная асяроддзе выканання для асобных экзэмпляраў прыкладання.
Давайце разгледзім плюсы і мінусы гэтага падыходу.
+ Абмежаваны «радыус выбуху»
Пры «паломцы» кластара негатыўныя наступствы абмяжоўваюцца толькі тымі працоўнымі нагрузкамі, якія былі разгорнутыя ў гэтым кластары. Усе іншыя workload'ы застаюцца некранутымі.
+ Ізаляцыя
Рабочыя нагрузкі, размешчаныя ў індывідуальных кластарах, не маюць агульных рэсурсаў, такіх як працэсар, памяць, аперацыйная сістэма, сетка ці іншыя сэрвісы.
У выніку мы атрымліваем жорсткую ізаляцыю паміж незвязанымі праграмамі, што можа спрыяльна адбіцца на іх бяспецы.
+ Малы лік карыстальнікаў
Улічваючы, што ў кожным кластары ўтрымоўваецца толькі абмежаваны набор працоўных нагрузак, скарачаецца лік карыстачоў з доступам да яго.
Чым менш людзей маюць доступ да кластара, тым ніжэй рызыка таго, што нешта "зламаецца".
Давайце паглядзім на мінусы.
− Неэфектыўнае выкарыстанне рэсурсаў
Як згадвалася раней, кожнаму кластару Kubernetes патрабуецца вызначаны набор кіраўнікоў рэсурсаў: майстар-вузлы, кампаненты кантрольнага пласта, рашэнні для маніторынгу і вядзенні логаў.
У выпадку вялікай колькасці малых кластараў даводзіцца выдзяляць большую долю рэсурсаў на кіраванне.
− Дарагоўля
Неэфектыўнае выкарыстанне рэсурсаў аўтаматычна цягне за сабой высокія выдаткі.
Напрыклад, змест 30 майстар-вузлоў замест трох пры той жа вылічальнай магутнасці абавязкова адаб'ецца на расходах.
− Складанасці адміністравання
Адміністраваць мноства кластараў Kubernetes значна складаней, чым працаваць з адным.
Напрыклад, давядзецца наладжваць аўтэнтыфікацыю і аўтарызацыю для кожнага кластара. Абнаўленне версіі Kubernetes таксама давядзецца праводзіць па некалькі разоў.
Хутчэй за ўсё, давядзецца прымяніць аўтаматызацыю, каб павысіць эфектыўнасць усіх гэтых задач.
Цяпер разгледзім менш экстрэмальныя сцэнары.
3. Адзін кластар на кожнае прыкладанне
У рамках гэтага падыходу вы ствараеце асобны кластар для ўсіх экзэмпляраў канкрэтнага прыкладання:
Кластар на дадатак
Такі шлях можна разглядаць як абагульненне прынцыпу.асобны кластар на каманду», паколькі звычайна каманда інжынераў займаецца распрацоўкай аднаго або некалькіх прыкладанняў.
Давайце разгледзім плюсы і мінусы гэтага падыходу.
+ Кластар можна падбудаваць пад дадатак
Калі ў дадатку маюцца асаблівыя патрэбнасці, іх можна рэалізаваць у кластары, не закранаючы іншыя кластары.
Такія запатрабаванні могуць уключаць worker'ы з GPU, вызначаныя плагіны CNI, service mesh ці які-небудзь іншы сэрвіс.
Кожны кластар можна падбудаваць пад якое працуе ў ім прыкладанне, каб ён утрымліваў толькі тое, што неабходна.
− Розныя асяроддзі ў адным кластары
Недахопам гэтага падыходу з'яўляецца тое, што асобнікі прыкладанняў з розных акружэнняў суіснуюць у адным кластары.
Напрыклад, prod-версія дадатку працуе ў тым жа кластары, што і dev-версія. Гэта таксама азначае, што распрацоўшчыкі вядуць сваю дзейнасць у тым жа кластары, у якім эксплуатуецца production-версія прыкладання.
Калі з-за дзеянняў распрацоўшчыкаў або глюкаў dev-версіі ў кластары адбудзецца збой, то патэнцыйна можа пацярпець і prod-версія – велізарны недахоп такога падыходу.
Ну і, нарэшце, апошні сцэнар у нашым сьпісе.
4. Адзін кластар на кожнае асяроддзе
Дадзены сцэнар прадугледжвае вылучэнне асобнага кластара на кожнае асяроддзе:
Адзін кластар на асяроддзе
Напрыклад, у вас могуць быць кластары DEV, тэст и prod, У якіх вы будзеце запускаць усе экзэмпляры прыкладання, прызначаныя для пэўнага асяроддзя.
Вось плюсы і мінусы такога падыходу.
+ Ізаляцыя prod-асяроддзя
У рамках гэтага падыходу ўсе асяроддзі апыняюцца ізаляванымі сябар ад сябра. Аднак на практыцы гэта асабліва важна для prod-асяроддзя.
Production-версіі прыкладання зараз не залежаць ад таго, што адбываецца ў іншых кластарах і асяроддзях.
Такім чынам, калі ў dev-кластары раптам узнікне праблема, prod-версіі прыкладанняў працягнуць працаваць як быццам нічога не здарылася.
+ Кластар можна падбудаваць пад сераду
Кожны кластар можна падбудаваць пад яго асяроддзе. Напрыклад, можна:
- усталяваць у dev-кластары прылады для распрацоўкі і адладкі;
- усталяваць тэставыя фрэймворкі і інструменты ў кластары тэст;
- выкарыстоўваць больш магутнае абсталяванне і сеткавыя каналы ў кластары prod.
Гэта дазваляе павысіць эфектыўнасць як распрацоўкі, так і эксплуатацыі дадаткаў.
+ Абмежаванне доступу да production-кластару
Неабходнасць працаваць з prod-кластарам напрамую ўзнікае нячаста, так што можна значна абмежаваць кола асоб, якія маюць да яго доступ.
Можна пайсці яшчэ далей і наогул пазбавіць людзей доступу да гэтага кластара, а ўсе разгортванні выконваць з дапамогай аўтаматызаванай прылады CI/CD. Падобны падыход дазволіць максімальна знізіць рызыку чалавечых памылак менавіта там, дзе гэта найболей актуальна.
А зараз некалькі слоў аб мінусах.
− Адсутнасць ізаляцыі паміж праграмамі
Асноўны недахоп падыходу - адсутнасць апаратнай і рэсурснай ізаляцыі паміж прыкладаннямі.
Нязвязаныя прыкладанні сумесна выкарыстоўваюць рэсурсы кластара: сістэмнае ядро, працэсар, памяць і некаторыя іншыя службы.
Як ужо згадвалася, гэта можа быць патэнцыйна небяспечным.
− Немагчымасць лакалізаваць залежнасці прыкладанняў
Калі ў дадатку маюцца асаблівыя патрабаванні, то іх даводзіцца задавальняць ва ўсіх кластарах.
Напрыклад, калі з дадаткам неабходны GPU, то кожны кластар павінен утрымліваць прынамсі адзін worker з GPU (нават калі ён выкарыстоўваецца толькі гэтым дадаткам).
У выніку мы рызыкуем атрымаць больш высокія выдаткі і неэфектыўнае выкарыстанне рэсурсаў.
Заключэнне
Пры наяўнасці вызначанага набору прыкладанняў іх можна размясціць у некалькіх вялікіх кластарах ці ў мностве малых.
У артыкуле разгледжаны плюсы і мінусы розных падыходаў, пачынаючы ад аднаго глабальнага кластара і заканчваючы некалькімі невялікімі і вузкаспецыялізаванымі:
- адзін буйны агульны кластар;
- мноства невялікіх вузкаспецыялізаваных кластараў;
- адзін кластар на кожнае прыкладанне;
- адзін кластар на кожнае асяроддзе.
Такім чынам, які падыход выбраць?
Як звычайна, адказ залежыць ад сцэнара выкарыстання: неабходна ўзважыць плюсы і мінусы розных падыходаў і абраць найболей аптымальны варыянт.
Аднак выбар не абмяжоўваецца прыведзенымі вышэй прыкладамі - можна задзейнічаць любое іх спалучэнне!
Напрыклад, можна арганізаваць па пары кластараў на кожную каманду: кластар для распрацоўкі (у якім будуць асяроддзі DEV и тэст) і кластар для вытворчасць (дзе будзе знаходзіцца production-асяроддзе).
Абапіраючыся на інфармацыю з гэтага артыкула, вы зможаце якая адпавядае выявай аптымізаваць плюсы і мінусы пад пэўны сцэнар. Удачы!
PS
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com