Здраво, моје име је Дмитриј Краснов. Више од пет година администрирам Кубернетес кластере и градим сложене микросервисне архитектуре. Почетком ове године покренули смо сервис за управљање Кубернетес кластерима заснован на Цонтаинеруму. Користећи ову прилику, рећи ћу вам шта је Кубернетес и по чему се интеграција са добављачем разликује од отвореног кода.
За почетак, шта је . Ово је систем за управљање контејнерима на великом броју хостова. Са грчког се, иначе, преводи као "пилот" или "кормилар". Првобитно развијен од стране Гоогле-а, а затим дониран као технолошки допринос Цлоуд Нативе Цомпутинг Фоундатион, међународној непрофитној организацији која окупља водеће светске програмере, крајње кориснике и добављаче технологије контејнера.
Управљајте великим бројем контејнера
Сада хајде да схватимо какви су ово контејнери. Ово је апликација са целим окружењем - углавном библиотекама од којих зависи програм. Све ово је упаковано у архиве и представљено у облику слике која се може покренути без обзира на оперативни систем, тестирати и друго. Али постоји проблем - управљање контејнерима на великом броју хостова је веома тешко. Због тога је створен Кубернетес.
Слика контејнера представља апликацију плус њене зависности. Апликација, њене зависности и слика система датотека ОС налазе се у различитим деловима слике, такозваним слојевима. Слојеви се могу поново користити за различите контејнере. На пример, све апликације у компанији могу користити Убунту основни слој. Када покрећете контејнере, нема потребе да чувате више копија једног основног слоја на хосту. Ово вам омогућава да оптимизујете складиштење и испоруку слика.
Када желимо да покренемо апликацију из контејнера, неопходни слојеви се налажу један на други и формира се систем датотека са преклапањем. На врху се поставља слој за снимање, који се уклања када се контејнер заустави. Ово осигурава да када се контејнер покрене, апликација ће увек имати исто окружење, које се не може променити. Ово гарантује поновљивост окружења на различитим оперативним системима домаћина. Било да је у питању Убунту или ЦентОС, окружење ће увек бити исто. Поред тога, контејнер је изолован од хоста помоћу механизама уграђених у Линук кернел. Апликације у контејнеру не виде датотеке, процесе хоста и суседне контејнере. Ова изолација апликација од ОС-а домаћина пружа додатни ниво сигурности.
Постоји много доступних алата за управљање контејнерима на хосту. Најпопуларнији од њих је Доцкер. Омогућава вам да обезбедите пуни животни циклус контејнера. Међутим, ради само на једном хосту. Ако требате да управљате контејнерима на више хостова, Доцкер може да направи пакао од живота за инжењере. Због тога је створен Кубернетес.
Потражња за Кубернетесом је управо због могућности управљања групама контејнера на више хостова као неком врстом једног ентитета. Популарност система пружа могућност за прављење ДевОпс-а или развојних операција, у којима се Кубернетес користи за покретање процеса управо овог ДевОпс-а.
Слика 1. Шематски приказ како Кубернетес функционише
Потпуна аутоматизација
ДевОпс је у основи аутоматизација процеса развоја. Грубо говорећи, програмери пишу код који се учитава у спремиште. Затим се овај код може аутоматски сакупити одмах у контејнер са свим библиотекама, тестирати и „пребацити“ на следећу фазу - Стагинг, а затим одмах у продукцију.
Заједно са Кубернетес-ом, ДевОпс вам омогућава да аутоматизујете овај процес тако да се одвија без учешћа самих програмера. Због тога је градња знатно бржа, јер програмер не мора то да ради на свом рачунару - он једноставно напише део кода, гура код у спремиште, након чега се покреће цевовод, који може укључивати процес изградње, тестирања и увођења. И то се дешава са сваким урезивањем, тако да се тестирање дешава континуирано.
Истовремено, коришћење контејнера вам омогућава да будете сигурни да ће целокупно окружење овог програма бити пуштено у производњу тачно у облику у којем је тестирано. Односно, неће бити проблема типа „биле су неке верзије на тесту, друге у производњи, али када смо их инсталирали, све је пало“. А пошто данас имамо тренд ка микросервисној архитектури, када уместо једне огромне апликације постоје стотине малих, да би се њима ручно администрирали, биће потребно огромно особље. Зато користимо Кубернетес.
За, за, за
Ако говоримо о предностима Кубернетеса као платформе, онда он има значајне предности са становишта управљања микросервисном архитектуром.
- Управљање вишеструким репликама. Најважнија ствар је управљање контејнерима на више хостова. Што је још важније, управљајте вишеструким репликама апликација у контејнерима као једним ентитетом. Захваљујући томе, инжењери не морају да брину о сваком појединачном контејнеру. Ако се један од контејнера сруши, Кубернетес ће то видети и поново га покренути.
- Мрежа кластера. Кубернетес такође има такозвану мрежу кластера са сопственим адресним простором. Захваљујући томе, свака махуна има своју адресу. Субпод се схвата као минимална структурна јединица кластера у којој се контејнери директно лансирају. Поред тога, Кубернетес има функционалност која комбинује балансирање оптерећења и откривање услуга. Ово вам омогућава да се решите ручног управљања ИП адресама и делегирате овај задатак Кубернетесу. А аутоматске здравствене провере ће помоћи у откривању проблема и преусмеравању саобраћаја на радне подове.
- Управљање конфигурацијом. Када се управља великим бројем апликација, постаје тешко управљати конфигурацијом апликације. У ту сврху, Кубернетес има посебне ЦонфигМап ресурсе. Омогућавају вам да централно складиштите конфигурације и изложите их подовима када покрећете апликације. Овај механизам нам омогућава да гарантујемо конзистентност конфигурације у најмање десет или сто реплика апликације.
- Персистент Волумес. Контејнери су инхерентно непроменљиви и када се контејнер заустави, сви подаци уписани у систем датотека биће уништени. Али неке апликације складиште податке директно на диску. Да би решио овај проблем, Кубернетес има функцију управљања складиштем на диску - Персистент Волумес. Овај механизам користи спољно складиште за податке и може да пренесе трајно складиште, блок или датотеку, у контејнере. Ово решење вам омогућава да чувате податке одвојено од радника, што их штеди ако се ти исти радници покваре.
- Распоређивање оптерећења. Иако у Кубернетесу управљамо апстрактним ентитетима као што су Деплоимент, СтатефулСет, итд., контејнери се на крају покрећу на редовним виртуелним машинама или хардверским серверима. Нису савршени и могу пасти у било ком тренутку. Кубернетес ће то видети и преусмерити интерни саобраћај на друге реплике. Али шта радити са саобраћајем који долази споља? Ако једноставно усмерите саобраћај на једног од радника, ако се сруши, услуга ће постати недоступна. Да би решио овај проблем, Кубернетес има услуге као што је Лоад Баланцер. Дизајнирани су да аутоматски конфигуришу екстерни баланс за облак за све раднике у кластеру. Овај екстерни балансер усмерава спољни саобраћај на раднике и сам прати њихов статус. Ако један или више радника постану недоступни, саобраћај се преусмерава на друге. Ово вам омогућава да креирате високо доступне услуге користећи Кубернетес.
Кубернетес најбоље функционише када покреће микросервисне архитектуре. Могуће је имплементирати систем у класичну архитектуру, али је бесмислено. Ако апликација не може да ради на више реплика, каква је онда разлика - у Кубернетесу или не?
Кубернетес отвореног кода
Кубернетес отвореног кода је одлична ствар: инсталирао сам га и ради. Можете га поставити на сопствене хардверске сервере, на сопствену инфраструктуру, инсталирати мастере и раднике на којима ће све апликације радити. И што је најважније, све ово је бесплатно. Међутим, постоје нијансе.
- Први је захтев за знањем и искуством администратора и инжењера који ће све ово имплементирати и подржати. Пошто клијент добија потпуну слободу деловања у кластеру, он је сам одговоран за рад кластера. И овде је врло лако све разбити.
- Други је недостатак интеграција. Ако покренете Кубернетес без популарне платформе за виртуелизацију, нећете добити све предности програма. Као што је коришћење услуга трајних волумена и балансирања оптерећења.
Слика 2. архитектура к8с
Кубернетес од продавца
Интеграција са добављачем облака пружа две опције:
- Прво, особа може једноставно кликнути на дугме „креирај кластер“ и добити кластер који је већ конфигурисан и спреман за употребу.
- Друго, продавац сам инсталира кластер и поставља интеграцију са облаком.
Како се то дешава овде. Инжењер који покреће кластер прецизира колико радника треба и са којим параметрима (на пример, 5 радника, сваки са 10 ЦПУ-а, 16 ГБ РАМ-а и рецимо 100 ГБ диска). Након тога добија приступ већ формираном кластеру. У овом случају, радници на којима се покреће оптерећење се у потпуности преносе на клијента, али цео ниво управљања остаје под одговорношћу добављача (ако се услуга пружа према моделу управљане услуге).
Међутим, ова шема има своје недостатке. Због чињенице да ниво управљања остаје код продавца, добављач не даје потпуни приступ клијенту, а то смањује флексибилност у раду са Кубернетес-ом. Понекад се дешава да клијент жели да дода неку специфичну функционалност у Кубернетес, на пример, аутентификацију преко ЛДАП-а, али конфигурација равни управљања то не дозвољава.
Слика 3. Пример Кубернетес кластера од добављача облака
Шта изабрати: отворени извор или добављач
Дакле, да ли је Кубернетес отвореног кода или специфичан за добављача? Ако узмемо Кубернетес отвореног кода, онда корисник са њим ради шта хоће. Али постоји велика шанса да пуцате себи у ногу. Са продавцем је теже, јер је све осмишљено и конфигурисано за компанију. Највећи недостатак Кубернетеса отвореног кода је потреба за стручњацима. Са опцијом добављача, компанија је ослобођена ове главобоље, али ће морати да одлучи да ли ће платити својим стручњацима или продавцу.
Па, предности су очигледне, мане су такође познате. Једна ствар је константна: Кубернетес решава многе проблеме аутоматизацијом управљања многим контејнерима. И коју да изаберете, опен соурце или добављача - свако доноси своју одлуку.
Чланак је припремио Дмитриј Краснов, водећи архитекта услуге Цонтаинерум провајдера #ЦлоудМТС
Извор: ввв.хабр.цом