Белешка. трансл.: овај материјал је из образовног пројекта је одговор на популарно питање приликом дизајнирања инфраструктуре засноване на Кубернетесу. Надамо се да ће вам прилично детаљни описи предности и недостатака сваке опције помоћи да направите најбољи избор за ваш пројекат.
ТЛ; ДР: исти скуп оптерећења се може покренути на неколико великих кластера (сваки кластер ће имати велики број радних оптерећења) или на много малих (са малим бројем радних оптерећења у сваком кластеру).
Испод је табела која процењује предности и недостатке сваког приступа:
Када користите Кубернетес као платформу за покретање апликација, често се поставља неколико основних питања о сложености постављања кластера:
- Колико кластера треба да користим?
- Колико велике да их направим?
- Шта сваки кластер треба да садржи?
У овом чланку покушаћу да одговорим на сва ова питања анализирајући предности и недостатке сваког приступа.
Изјава о питању
Као програмер софтвера, вероватно развијате и користите многе апликације у исто време.
Поред тога, многе инстанце ових апликација ће вероватно радити у различитим окружењима – на пример, то могу бити дев, тест и прод.
Резултат је читава матрица апликација и окружења:
Апликације и окружења
Горњи пример представља 3 апликације и 3 окружења, што резултира са укупно 9 могућих опција.
Свака инстанца апликације је самостална јединица за примену са којом се може радити независно од других.
Имајте на уму да инстанца апликације може се састојати од многих компоненте, као што су фронтенд, бацкенд, база података итд. У случају апликације микросервиса, инстанца ће укључити све микросервисе.
Као резултат тога, корисници Кубернетес-а имају неколико питања:
- Да ли све инстанце апликације треба ставити у један кластер?
- Да ли је вредно имати посебан кластер за сваку инстанцу апликације?
- Или би можда требало користити комбинацију горе наведених приступа?
Све ове опције су прилично одрживе, пошто је Кубернетес флексибилан систем који не ограничава могућности корисника.
Ево неких од могућих начина:
- један велики заједнички кластер;
- много малих високо специјализованих кластера;
- један кластер по апликацији;
- један кластер по средини.
Као што је приказано у наставку, прва два приступа су на супротним крајевима скале опција:
Од неколико великих кластера (лево) до много малих (десно)
Генерално, један кластер се сматра „већим“ од другог ако има већи збир чворова и махуна. На пример, кластер са 10 чворова и 100 махуна је већи од кластера са 1 чвором и 10 махуна.
Па, хајде да почнемо!
1. Један велики заједнички кластер
Прва опција је да сва радна оптерећења поставите у један кластер:
Једна велика група
У оквиру овог приступа, кластер се користи као универзалан инфраструктурна платформа — једноставно поставите све што вам је потребно у постојећи Кубернетес кластер.
Кубернетес омогућава да се делови кластера логички одвоје један од другог, тако да свака инстанца апликације може да има сопствени простор имена.
Хајде да погледамо предности и недостатке овог приступа.
+ Ефикасно коришћење ресурса
Са једним кластером, потребна вам је само једна копија свих ресурса потребних за покретање и управљање Кубернетес кластером.
На пример, ово важи за главне чворове. Обично сваки Кубернетес кластер има 3 главна чвора, тако да ће за један појединачни кластер њихов број остати исти (за поређење, за 10 кластера ће бити потребно 30 главних чворова).
Горе наведена суптилност се такође односи на друге услуге које раде у целом кластеру, као што су балансери оптерећења, улазни контролери, аутентикација, евидентирање и системи за праћење.
У једном кластеру, све ове услуге се могу користити одједном за сва оптерећења (нема потребе да се праве њихове копије, као што је случај са више кластера).
+ Јефтино
Као последица горе наведеног, мање кластера је обично јефтиније јер нема режијских трошкова.
Ово посебно важи за главне чворове, који могу коштати значајну количину новца без обзира на то како се хостују (локално или у облаку).
Неки управљани Кубернетес сервиси, као нпр или , обезбедите контролни слој бесплатно. У овом случају, питање трошкова је мање акутно.
Постоје и управљане услуге које наплаћују фиксну накнаду за рад сваког Кубернетес кластера (нпр. ).
+ Ефикасна администрација
Управљање једним кластером је лакше него управљање неколико.
Администрација може укључивати следеће задатке:
- Ажурирање Кубернетес верзије;
- постављање ЦИ/ЦД цевовода;
- инсталирање ЦНИ додатка;
- постављање система за аутентификацију корисника;
- уградња контролера приступа;
и многи други…
У случају једног кластера, све ово ћете морати да урадите само једном.
За многе кластере, операције ће морати да се понављају много пута, што ће вероватно захтевати извесну аутоматизацију процеса и алата да би се обезбедила доследност и доследност у процесу.
А сада неколико речи о недостацима.
− Појединачна тачка квара
У случају одбијања једини кластер ће одмах престати да ради све оптерећења!
Постоји много начина на које ствари могу кренути по злу:
- ажурирање Кубернетеса доводи до неочекиваних нежељених ефеката;
- Компонента за цео кластер (на пример, ЦНИ додатак) почиње да не ради како се очекивало;
- једна од компоненти кластера није исправно конфигурисана;
- квар у основној инфраструктури.
Један такав инцидент може да изазове озбиљну штету свим радним оптерећењима смештеним у дељеном кластеру.
− Без чврсте изолације
Покретање у дељеном кластеру значи да апликације деле хардвер, мрежне могућности и оперативни систем на чворовима кластера.
У извесном смислу, два контејнера са две различите апликације које се покрећу на истом чвору су као два процеса која се покрећу на истој машини са истим ОС кернелом.
Линук контејнери пружају неки облик изолације, али није ни приближно тако јак као онај који пружају, рецимо, виртуелне машине. У суштини, процес у контејнеру је исти процес који се изводи на оперативном систему домаћина.
Ово може бити безбедносни проблем: овај аранжман теоретски омогућава неповезаним апликацијама да међусобно комуницирају (било намерно или случајно).
Поред тога, сва радна оптерећења у Кубернетес кластеру деле неке услуге на нивоу кластера, као што су - ово омогућава апликацијама да пронађу Услуге других апликација у кластеру.
Све горе наведене тачке могу имати различита значења у зависности од безбедносних захтева апликације.
Кубернетес пружа различите алате за спречавање безбедносних проблема као што су и . Међутим, њихово правилно постављање захтева одређено искуство; осим тога, нису у стању да затворе апсолутно све безбедносне рупе.
Важно је увек запамтити да је Кубернетес првобитно дизајниран за дељење, не за изолацију и сигурност.
− Недостатак стриктног вишестанарства
С обзиром на обиље заједничких ресурса у Кубернетес кластеру, постоји много начина на које различите апликације могу једна другој стати на прсте.
На пример, апликација може монополизовати дељени ресурс (као што је ЦПУ или меморија) и ускратити приступ другим апликацијама које раде на истом чвору.
Кубернетес обезбеђује различите механизме за контролу овог понашања, као што су (види и чланак „“ – прибл. превод), и . Међутим, као иу случају безбедности, њихова конфигурација је прилично нетривијална и нису у стању да спрече апсолутно све непредвиђене нежељене ефекте.
− Велики број корисника
У случају једног кластера, морате му отворити приступ многим људима. И што је њихов број већи, то је већи ризик да ће нешто „сломити“.
Унутар кластера можете контролисати ко може шта да ради користећи (види чланак „“ – прибл. превод). Међутим, то неће спречити кориснике да „разбију“ нешто у оквиру своје области одговорности.
− Кластери не могу бесконачно расти
Кластер који се користи за сва радна оптерећења ће вероватно бити прилично велик (у смислу броја чворова и подова).
Али овде се јавља још један проблем: кластери у Кубернетесу не могу да расту бесконачно.
Постоји теоријско ограничење величине кластера. У Кубернетесу је отприлике .
Међутим, у стварном животу, проблеми могу почети много раније - на пример, само са .
Чињеница је да велики кластери стављају велико оптерећење на контролни слој Кубернетеса. Другим речима, одржавање кластера и његово ефикасно функционисање захтева пажљиво подешавање.
Овај проблем је истражен у повезаном чланку на оригиналном блогу под називом „'.
Али хајде да размотримо супротан приступ: много малих кластера.
2. Много малих, специјализованих кластера
Овим приступом користите посебан кластер за сваки елемент који примењујете:
Много малих кластера
За потребе овог чланка, под елемент који се може распоредити односи се на инстанцу апликације - на пример, дев верзију посебне апликације.
Ова стратегија користи Кубернетес као специјализовану рунтиме за појединачне апликације.
Хајде да погледамо предности и недостатке овог приступа.
+ Ограничени „радијус експлозије“
Када кластер не успе, негативне последице су ограничене само на она оптерећења која су распоређена у том кластеру. Сва остала оптерећења остају нетакнута.
+ Изолација
Радна оптерећења смештена у појединачним кластерима не деле ресурсе као што су процесор, меморија, оперативни систем, мрежа или друге услуге.
Резултат је чврста изолација између неповезаних апликација, што може бити од користи за њихову безбедност.
+ Мали број корисника
С обзиром на то да сваки кластер садржи само ограничен скуп оптерећења, број корисника који му приступају је смањен.
Што мање људи има приступ кластеру, мањи је ризик да ће се нешто „сломити“.
Хајде да погледамо недостатке.
− Неефикасно коришћење ресурса
Као што је раније поменуто, сваки Кубернетес кластер захтева одређени скуп ресурса за управљање: главне чворове, компоненте контролног слоја, решења за праћење и евидентирање.
У случају великог броја малих кластера, већи део ресурса мора бити додељен менаџменту.
− Скупо
Неефикасна употреба ресурса аутоматски повлачи за собом високе трошкове.
На пример, одржавање 30 главних чворова уместо три са истом рачунарском снагом ће нужно утицати на трошкове.
− Потешкоће у администрацији
Управљање више Кубернетес кластера је много теже од управљања само једним.
На пример, мораћете да конфигуришете аутентификацију и ауторизацију за сваки кластер. Кубернетес верзија ће такође морати да се ажурира неколико пута.
Вероватно ћете морати да користите аутоматизацију да бисте све ове задатке учинили ефикаснијим.
Погледајмо сада мање екстремне сценарије.
3. Један кластер по апликацији
У овом приступу, креирате посебан кластер за све инстанце одређене апликације:
Кластер по апликацији
Овај пут се може сматрати генерализацијом принципа „засебан кластер по тиму“, пошто обично тим инжењера развија једну или више апликација.
Хајде да погледамо предности и недостатке овог приступа.
+ Кластер се може прилагодити апликацији
Ако апликација има посебне потребе, оне се могу имплементирати у кластер без утицаја на друге кластере.
Такве потребе могу укључивати ГПУ раднике, одређене ЦНИ додатке, сервисну мрежу или неку другу услугу.
Сваки кластер се може прилагодити апликацији која се у њему изводи тако да садржи само оно што је потребно.
− Различита окружења у једном кластеру
Недостатак овог приступа је што инстанце апликације из различитих окружења коегзистирају у истом кластеру.
На пример, прод верзија апликације ради у истом кластеру као и дев верзија. То такође значи да програмери раде у истом кластеру у којем се ради са производном верзијом апликације.
Ако, због радњи програмера или кварова у дев верзији, дође до квара у кластеру, онда би и прод верзија такође могла да пати - велики недостатак овог приступа.
И на крају, последњи сценарио на нашој листи.
4. Један кластер по окружењу
Овај сценарио укључује додељивање посебног кластера за свако окружење:
Један кластер по окружењу
На пример, можда имате кластере дев, тест и прод, у којој ћете покренути све инстанце апликације посвећене одређеном окружењу.
Ево предности и недостатака овог приступа.
+ Изолација прод окружења
У оквиру овог приступа сва окружења су изолована једно од другог. Међутим, у пракси је ово посебно важно у прод окружењу.
Продукцијске верзије апликације су сада независне од онога што се дешава у другим кластерима и окружењима.
На овај начин, ако се изненада појави проблем у дев кластеру, прод верзије апликација ће наставити да раде као да се ништа није догодило.
+ Кластер се може прилагодити окружењу
Сваки кластер се може прилагодити свом окружењу. На пример, можете:
- инсталирати алате за развој и отклањање грешака у дев кластеру;
- инсталирати тест оквире и алате у кластер тест;
- користите моћнији хардвер и мрежне канале у кластеру прод.
Ово вам омогућава да повећате ефикасност и развоја и рада апликација.
+ Ограничавање приступа производном кластеру
Потреба за директним радом са производним кластером се ретко јавља, тако да можете значајно ограничити круг људи који му имају приступ.
Можете ићи још даље и у потпуности ускратити људима приступ овом кластеру и извршити сва постављања користећи аутоматизовани ЦИ/ЦД алат. Такав приступ ће минимизирати ризик од људских грешака управо тамо где је најрелевантнији.
А сада неколико речи о недостацима.
− Нема изолације између апликација
Главни недостатак приступа је недостатак хардверске и изолације ресурса између апликација.
Неповезане апликације деле ресурсе кластера: језгро система, процесор, меморију и неке друге услуге.
Као што је поменуто, ово може бити потенцијално опасно.
− Немогућност локализације зависности апликације
Ако апликација има посебне захтеве, онда они морају бити задовољени у свим кластерима.
На пример, ако апликација захтева ГПУ, онда сваки кластер мора да садржи најмање једног радника са ГПУ-ом (чак и ако га користи само та апликација).
Као резултат тога, ризикујемо веће трошкове и неефикасну употребу ресурса.
Закључак
Ако имате одређени скуп апликација, оне се могу поставити у неколико великих кластера или много малих.
Чланак говори о предностима и недостацима различитих приступа, у распону од једног глобалног кластера до неколико малих и високо специјализованих:
- један велики општи кластер;
- много малих високо специјализованих кластера;
- један кластер по апликацији;
- један кластер по средини.
Дакле, који приступ треба да узмете?
Као и увек, одговор зависи од случаја употребе: потребно је да измерите предности и недостатке различитих приступа и изаберете најоптималнији избор.
Међутим, избор није ограничен на примере изнад - можете користити било коју њихову комбинацију!
На пример, можете организовати неколико кластера за сваки тим: развојни кластер (у којем ће бити окружења дев и тест) и кластер за производња (где ће се налазити производно окружење).
На основу информација у овом чланку, можете оптимизовати предности и недостатке у складу са одређеним сценаријем. Срећно!
ПС
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом