Дизајнирање на Kubernetes кластери: Колку треба да има?

Забелешка. превод.: овој материјал е од едукативен проект учи8s - одговорот на популарното прашање при дизајнирање на инфраструктура заснована на Kubernetes. Се надеваме дека доволно деталните описи на добрите и лошите страни на секоја од опциите ќе ви помогнат да го направите најдобриот избор за вашиот проект.

TL; ДР: истиот сет на оптоварувања може да се извршува на неколку големи кластери (секој кластер ќе има голем број на оптоварувања) или на многу мали (со мал број на оптоварувања во секој кластер).

Подолу е табела која ги оценува добрите и лошите страни на секој пристап:

Кога користите Kubernetes како платформа за извршување на апликации, често има неколку основни прашања за сложеноста на конфигурирањето на кластерите:

• Колку кластери да се користат?
• Колку големи треба да ги направите?
• Што треба да содржи секој кластер?

Во оваа статија, ќе се обидам да одговорам на сите овие прашања со анализа на добрите и лошите страни на секој пристап.

Изјава за прашање

Како развивач на софтвер, најверојатно ќе развивате и ќе управувате со многу апликации паралелно.

Покрај тоа, многу примери на овие апликации најверојатно ќе работат во различни средини - на пример, овие може да бидат dev, тест и prod.

Резултатот е цела матрица на апликации и околини:

Апликации и околини

Во примерот погоре, има 3 апликации и 3 околини, што резултира со вкупно 9 можни опции.

Секој примерок на апликација е самостојна единица за распоредување со која можете да работите независно од другите.

Имајте на ум дека пример за апликација може да се состои од многу компонентикако што се фронтенд, заден дел, база на податоци итн. Во случај на апликација за микросервис, примерокот ќе ги вклучи сите микроуслуги.

Како резултат на тоа, корисниците на Kubernetes имаат неколку прашања:

• Дали сите примероци на апликации треба да бидат хостирани на истиот кластер?
• Дали вреди да се започне посебен кластер за секоја апликација?
• Или можеби треба да се користи комбинација од горенаведените пристапи?

Сите овие опции се остварливи, бидејќи Kubernetes е флексибилен систем кој не ги ограничува опциите на корисникот.

Еве некои од можните начини:

• еден голем заеднички кластер;
• многу мали високо специјализирани кластери;
• еден кластер по апликација;
• еден кластер по средина.

Како што е прикажано подолу, првите два пристапа се на спротивните краеви на скалата на опции:

Од неколку големи кластери (лево) до многу мали (десно)

Генерално, се смета дека еден кластер е „поголем“ од друг ако има повеќе од збирот на јазли и мешунки. На пример, кластер со 10 јазли и 100 мешунки е поголем од кластер со 1 јазол и 10 мешунки.

Па, ајде да започнеме!

1. Еден голем споделен кластер

Првата опција е да ги поставите сите оптоварувања во еден кластер:

Еден голем кластер

Во рамките на овој пристап, кластерот се користи како универзален инфраструктурна платформа - едноставно распоредувате се што ви треба во постоечки кластер на Кубернет.

Простори со имиња Kubernetes ви овозможува логички да ги одделите деловите од кластерот еден од друг, така што секој примерок на апликација може да користи свој именски простор.

Ајде да ги погледнеме добрите и лошите страни на овој пристап.

+ Ефикасно користење на ресурсите

Во случај на еден кластер, ќе биде потребна само една копија од сите ресурси потребни за извршување и управување со кластерот Kubernetes.

На пример, ова важи за главните јазли. Вообичаено, има 3 главни јазли по кластерот Kubernetes, така што за еден кластер, нивниот број ќе остане таков (за споредба, на 10 кластери ќе им требаат 30 главни јазли).

Горенаведената суптилност се однесува и на други услуги кои работат низ целиот кластер, како што се балансери на оптоварување, контролери за влез, системи за автентикација, логирање и следење.

Во еден кластер, сите овие услуги може да се користат за сите оптоварувања одеднаш (нема потреба да се создаваат копии од нив, како во случајот со повеќе кластери).

+ евтини

Како последица на горенаведеното, помалку кластери обично се поевтини бидејќи нема трошок за вишок ресурси.

Ова е особено точно за masternodes, кои може да чинат значителна сума пари без разлика дали се хостирани во простории или во облак.

Некои управуваа со услугите на Кубернетес, како на пр Google Kubernetes Engine (GKE) или Azure Kubernetes Service (AKS), обезбедете го контролниот слој бесплатно. Во овој случај, прашањето за трошоците е помалку акутно.

Исто така, постојат управувани услуги кои наплаќаат фиксна такса за работењето на секој кластер на Кубернетес (на пример, Амазон Еластик Кубернетес сервис, EKS).

+ Ефикасна администрација

Полесно е да се управува со еден кластер отколку со неколку.

Администрацијата може да ги вклучи следните задачи:

• ажурирање на верзијата на Kubernetes;
• конфигурирање на цевководот CI/CD;
• инсталирање на приклучокот CNI;
• поставување систем за автентикација на корисникот;
• инсталација на контролорот за прием;

и многу други…

Во случај на еден кластер, сето ова ќе треба да го направите само еднаш.

За многу кластери, операциите ќе треба да се повторуваат многу пати, што веројатно ќе бара одредена автоматизација на процесите и алатките за да се обезбеди систематски и униформен процес.

И сега неколку зборови за лошите страни.

− Единствена точка на неуспех

Во случај на одбивање единствено кластерите веднаш ќе престанат да работат сите обемот на работа!

Постојат многу опции за тоа кога нешто може да тргне наопаку:

• Надградбата на Kubernetes доведува до неочекувани несакани ефекти
• компонента ширум кластерот (на пример, CNI приклучок) не започнува да работи како што се очекуваше;
• една од компонентите на кластерот е погрешно конфигурирана;
• неуспех во основната инфраструктура.

Еден таков инцидент може да предизвика сериозна штета на сите оптоварувања сместени во заеднички кластер.

− Недостаток на цврста изолација

Работењето во споделен кластер значи дека апликациите го споделуваат хардверот, мрежните способности и оперативниот систем на јазлите на кластерот.

Во извесна смисла, два контејнери со две различни апликации кои работат на ист домаќин се како два процеси кои работат на иста машина што работат на истиот кернел на ОС.

Контејнерите на Линукс обезбедуваат некаква форма на изолација, но не е ни приближно толку силна како што, да речеме, виртуелните машини обезбедуваат. Во суштина, процес во контејнер е истиот процес што се извршува на оперативниот систем домаќин.

Ова може да биде безбедносен проблем: оваа организација теоретски дозволува неповрзани апликации да комуницираат едни со други (намерно или случајно).

Дополнително, сите оптоварувања во кластерот Kubernetes споделуваат некои услуги низ целиот кластер, како на пр DNS - ова им овозможува на апликациите да најдат Услуги на други апликации во кластерот.

Сите горенаведени точки може да имаат различно значење во зависност од безбедносните барања на апликацијата.

Kubernetes обезбедува различни алатки за да се спречат безбедносни проблеми како што се PodSecurityPolicies и Мрежни политики. Сепак, тие бараат одредено искуство за правилно конфигурирање и не се во можност да ги затворат апсолутно сите безбедносни дупки.

Важно е секогаш да се запамети дека Кубернетес првично беше дизајниран да споделување, не за изолација и безбедност.

− Недостаток на тврдо мулти-закуп

Со оглед на изобилството на споделени ресурси во кластерот Kubernetes, постојат многу начини на кои различни апликации можат да стапнат една на друга.

На пример, апликацијата може да монополизира споделен ресурс (како што е процесор или меморија) и да им забрани пристап до него на други апликации што работат на истиот домаќин.

Kubernetes обезбедува различни механизми за контрола на ова однесување, како на пр барања и ограничувања за ресурси (видете ја и статијата " Ограничувања на процесорот и агресивно пригушување во Кубернетес “- прибл. превод.), РесурсиКвоти и Ограничувања. Сепак, како и во случајот со безбедноста, нивната конфигурација е прилично нетривијална и тие не се во можност да ги спречат апсолутно сите непредвидени несакани ефекти.

− Голем број на корисници

Во случај на еден кластер, треба да отворите пристап до него за многу луѓе. И колку е поголем нивниот број, толку е поголем ризикот да „скршат“ нешто.

Внатре во кластерот, можете да контролирате со кој што може да прави Контрола на пристап заснована на улоги (RBAC) (види статија“ Корисници и овластување RBAC во Kubernetes “- прибл. превод.). Сепак, тоа нема да ги спречи корисниците да „скршат“ нешто во нивната област на одговорност.

− Кластерите не можат да растат бесконечно

Кластерот што се користи за сите оптоварувања веројатно ќе биде доста голем (во однос на бројот на јазли и мешунки).

Но, тука се јавува друг проблем: кластерите во Кубернетес не можат да растат бесконечно.

Постои теоретска граница за големината на кластерот. Во Кубернетес, тоа е приближно 5000 јазли, 150 илјади мешунки и 300 илјади контејнери.

Меѓутоа, во реалниот живот, проблемите можат да започнат многу порано - на пример, токму кога 500 јазли.

Факт е дека големите кластери ставаат големо оптоварување на контролниот слој на Kubernetes. Со други зборови, потребно е внимателно подесување за да се одржи кластерот и да работи ефикасно.

Ова прашање е истражено во поврзана статија на оригиналниот блог со наслов „Архитектирање на кластери Kubernetes - избор на големина на работнички јазол".

Но, да го разгледаме спротивниот пристап: многу мали кластери.

2. Многу мали, специјализирани кластери

Со овој пристап, користите посебен кластер за секоја ставка што ја распоредувате:

Многу мали кластери

За целите на овој член под распоредлив елемент се подразбира како пример на апликацијата - на пример, верзијата dev на посебна апликација.

Во оваа стратегија, Kubernetes се користи како специјализиран траење за индивидуални примери на апликација.

Ајде да ги погледнеме добрите и лошите страни на овој пристап.

+ Ограничен „радиус на експлозија“

Кога кластерот „се скрши“, негативните последици се ограничени само на оние оптоварувања што беа распоредени во овој кластер. Сите други оптоварувања остануваат недопрени.

+ Изолација

Работните оптоварувања сместени во поединечни кластери не споделуваат заеднички ресурси како што се процесор, меморија, оперативен систем, мрежа или други услуги.

Како резултат на тоа, добиваме силна изолација помеѓу неповрзани апликации, што може да биде корисно за нивната безбедност.

+ Мал број на корисници

Со оглед на тоа што секој кластер содржи само ограничен сет на оптоварувања, бројот на корисници со пристап до него е намален.

Колку помалку луѓе имаат пристап до кластерот, толку е помал ризикот дека нешто ќе се „скрши“.

Да ги погледнеме лошите страни.

− Неефикасно користење на ресурсите

Како што беше споменато претходно, секој Kubernetes кластер бара одреден сет на ресурси за управување: мастер јазли, компоненти на контролниот слој, решенија за следење и логирање.

Во случај на голем број мали кластери, поголем дел од ресурсите мора да се распределат на менаџментот.

− Скапо

Неефикасното користење на ресурсите автоматски повлекува високи трошоци.

На пример, одржувањето на 30 мастерноди наместо три со иста компјутерска моќ дефинитивно ќе влијае на трошоците.

− Тешкотии во администрацијата

Администрирањето на повеќе Kubernetes кластери е многу потешко отколку управувањето со еден.

На пример, ќе мора да конфигурирате автентикација и овластување за секој кластер. Надградбата на верзијата на Kubernetes исто така ќе треба да се направи неколку пати.

Најверојатно, ќе треба да примените автоматизација за да ја зголемите ефикасноста на сите овие задачи.

Сега разгледајте помалку екстремни сценарија.

3. Еден кластер по апликација

Со овој пристап, креирате посебен кластер за сите примери на одредена апликација:

Кластер по апликација

Овој начин може да се смета како генерализација на принципот "посебен кластер по тим“ бидејќи обично тим од инженери е вклучен во развојот на една или повеќе апликации.

Ајде да ги погледнеме добрите и лошите страни на овој пристап.

+ Кластерот може да се прилагоди на апликацијата

Ако апликацијата има посебни потреби, тие може да се имплементираат во кластер без да влијаат на други кластери.

Таквите потреби може да вклучуваат работници на графичкиот процесор, одредени CNI приклучоци, мрежа за услуги или некоја друга услуга.

Секој кластер може да се прилагоди на апликацијата што работи на него за да го содржи само она што е потребно.

− Различни средини во еден кластер

Недостаток на овој пристап е што примероците на апликации од различни средини коегзистираат во истиот кластер.

На пример, прод верзијата на апликација работи на истиот кластер како и верзијата на dev. Ова исто така значи дека програмерите работат во истиот кластер како и производната верзија на апликацијата.

Ако кластерот не успее поради дејствата на програмерите или дефекти во верзијата на dev, тогаш и прод верзијата потенцијално може да страда - огромен недостаток на овој пристап.

И конечно, последното сценарио на нашата листа.

4. Еден кластер по средина

Ова сценарио предвидува распределба на посебен кластер за секоја средина:

Еден кластер по средина

На пример, може да имате кластери dev, тест и prod, во која ќе ги извршите сите инстанци од апликацијата кои се наменети за одредена средина.

Еве ги добрите и лошите страни на овој пристап.

+ Изолација на прод-средина

Во рамките на овој пристап, сите средини се изолирани една од друга. Меѓутоа, во пракса, ова е особено важно за прод околината.

Производните верзии на апликацијата сега се независни од она што се случува во другите кластери и средини.

Така, ако ненадејно се појави проблем во кластерот на dev, prod верзиите на апликациите ќе продолжат да работат како ништо да не се случило.

+ Кластерот може да се прилагоди на околината

Секој кластер може да се прилагоди на неговата околина. На пример, можете:

• инсталирајте алатки за развој и дебагирање во кластерот на dev;
• инсталирајте тест рамки и алатки на кластерот тест;
• користете помоќен хардвер и мрежни врски во кластерот prod.

Ова ја подобрува ефикасноста и на развојот и на работата на апликациите.

+ Ограничување на пристапот до производниот кластер

Потребата да се работи директно со кластерот за производи не се јавува често, така што може значително да го ограничите кругот на луѓе кои имаат пристап до него.

Можете да отидете уште подалеку и целосно да ги лишите луѓето од пристапот до овој кластер и да ги правите сите распоредувања користејќи автоматизирана CI / CD алатка. Таквиот пристап ќе го минимизира ризикот од човечки грешки токму онаму каде што е најрелевантно.

И сега неколку зборови за лошите страни.

− Недостаток на изолација помеѓу апликациите

Главниот недостаток на пристапот е недостатокот на хардвер и изолација на ресурси помеѓу апликациите.

Неповрзаните апликации споделуваат ресурси на кластерот: јадро на системот, процесор, меморија и некои други услуги.

Како што веќе споменавме, ова може да биде потенцијално опасно.

− Неможност да се локализираат зависностите на апликациите

Ако апликацијата има посебни барања, тогаш тие мора да бидат задоволни во сите кластери.

На пример, ако на апликацијата и треба графички процесор, тогаш секој кластер мора да содржи најмалку еден работник со графички процесор (дури и ако го користи само оваа апликација).

Како резултат на тоа, ризикуваме повисоки трошоци и неефикасно користење на ресурсите.

Заклучок

Ако имате одреден сет на апликации, тие може да се сместат во неколку големи кластери или во многу мали.

Статијата ги разгледува добрите и лошите страни на различни пристапи, кои се движат од еден глобален кластер до неколку мали и високо специјализирани:

• еден голем заеднички кластер;
• многу мали високо специјализирани кластери;
• еден кластер по апликација;
• еден кластер по средина.

Значи, кој пристап треба да го изберете?

Како и обично, одговорот зависи од случајот на употреба: треба да ги измерите добрите и лошите страни на различните пристапи и да ја изберете најдобрата опција.

Сепак, изборот не е ограничен само на примерите погоре - можете да користите каква било комбинација од нив!

На пример, можете да организирате пар кластери за секој тим: кластер за развој (кој ќе има средини dev и тест) и кластер за производство (каде што ќе биде производствената средина).

Врз основа на информациите во оваа статија, ќе можете соодветно да ги оптимизирате добрите и лошите страни за одредено сценарио. Со среќа!

PS

Прочитајте и на нашиот блог:

• «Визуелен водич за решавање проблеми на Kubernetes";
• «Логира во Кубернетес (и не само) денес: очекувања и реалност";
• «Сервисна мрежа: Што секој софтверски инженер треба да знае за најжешката технологија";
• «ABC за безбедност во Kubernetes: автентикација, овластување, ревизија".

Извор: www.habr.com