Кубернетес је одличан алат за покретање Доцкер контејнера у кластеризованом производном окружењу. Међутим, постоје проблеми које Кубернетес не може да реши. За честе производне имплементације, потребна нам је потпуно аутоматизована плава/зелена примена да бисмо избегли застоје у процесу, који такође треба да обрађује спољне ХТТП захтеве и врши ССЛ отпремање. Ово захтева интеграцију са балансатором оптерећења као што је ха-проки. Још један изазов је полуаутоматско скалирање самог Кубернетес кластера када се ради у окружењу облака, на пример, делимично смањивање кластера ноћу.
Иако Кубернетес нема ове функције ван кутије, он пружа АПИ који можете користити за решавање сличних проблема. Алати за аутоматизовано Блуе/Греен примену и скалирање Кубернетес кластера развијени су као део Цлоуд РТИ пројекта, који је креиран на основу отвореног кода.
Овај чланак, видео транскрипт, показује вам како да подесите Кубернетес заједно са другим компонентама отвореног кода да бисте креирали окружење спремно за производњу које прихвата код из гит урезивања без прекида у производњи.
Дакле, када добијете приступ својим апликацијама из спољашњег света, можете да почнете да потпуно подешавате аутоматизацију, односно да је доведете до фазе у којој можете да извршите гит урезивање и обезбедите да ова гит урезивање заврши у производњи. Наравно, приликом имплементације ових корака, приликом имплементације имплементације, не желимо да се сусрећемо са застојима. Дакле, свака аутоматизација у Кубернетесу почиње са АПИ-јем.
Кубернетес није алатка која се може продуктивно користити из кутије. Наравно, можете то учинити, користити кубецтл и тако даље, али ипак је АПИ најзанимљивија и најкориснија ствар на овој платформи. Коришћењем АПИ-ја као скупа функција, можете приступити скоро свему што желите да радите у Кубернетесу. Сам кубецтл такође користи РЕСТ АПИ.
Ово је РЕСТ, тако да можете користити било који језик или алат за рад са овим АПИ-јем, али ће вам прилагођене библиотеке знатно олакшати живот. Мој тим је написао 2 такве библиотеке: једну за Јава/ОСГи и једну за Го. Други се не користи често, али у сваком случају имате ове корисне ствари на располагању. Они су делимично лиценцирани пројекат отвореног кода. Постоји много таквих библиотека за различите језике, тако да можете изабрати оне које вам највише одговарају.
Дакле, пре него што почнете да аутоматизујете своју примену, морате се уверити да процес неће бити подложан застоју. На пример, наш тим спроводи примену у производњи средином дана када људи највише користе апликације, тако да је важно избећи кашњења у овом процесу. Да би се избегло застоје, користе се 2 методе: плаво/зелено постављање или ажурирање у току. У последњем случају, ако имате 5 покренутих реплика апликације, оне се ажурирају узастопно једна за другом. Овај метод одлично функционише, али није прикладан ако имате различите верзије апликације које раде истовремено током процеса имплементације. У овом случају, можете ажурирати кориснички интерфејс док позадински систем покреће стару верзију и апликација ће престати да ради. Дакле, са програмске тачке гледишта, рад у таквим условима је прилично тежак.
Ово је један од разлога зашто више волимо да користимо плаво/зелену примену да бисмо аутоматизовали примену наших апликација. Овим методом морате осигурати да је само једна верзија апликације активна истовремено.
Плаво/зелени механизам за постављање изгледа овако. Саобраћај за наше апликације примамо преко ха-проки-а, који га прослеђује на покренуте реплике апликације исте верзије.
Када се изврши нова примена, користимо Деплоиер, који добија нове компоненте и примењује нову верзију. Примена нове верзије апликације значи да се нови скуп реплика „подиже“, након чега се ове реплике нове верзије покрећу у засебној, новој подлози. Међутим, ха-проки не зна ништа о њима и још увек им не усмерава никакво радно оптерећење.
Због тога је, пре свега, неопходно извршити проверу перформанси нових верзија провере здравља како би се уверило да су реплике спремне за сервисирање оптерећења.
Све компоненте имплементације морају подржавати неки облик провере здравља. Ово може бити врло једноставна провера ХТТП позива, када добијете код са статусом 200, или детаљнија провера, у којој се проверава повезаност реплика са базом података и другим сервисима, стабилност веза динамичког окружења. , и да ли се све покреће и ради како треба. Овај процес може бити прилично сложен.
Након што систем потврди да све ажуриране реплике раде, Деплоиер ће ажурирати конфигурацију и проследити исправан цонфд, који ће поново конфигурисати ха-проки.
Тек након овога ће саобраћај бити усмерен на под са репликама нове верзије, а стари под ће нестати.
Овај механизам није карактеристика Кубернетеса. Концепт плаво/зелене имплементације постоји већ дуго времена и увек је користио балансер оптерећења. Прво усмеравате сав саобраћај на стару верзију апликације, а након ажурирања га у потпуности преносите на нову верзију. Овај принцип се користи не само у Кубернетесу.
Сада ћу вас упознати са новом компонентом за примену - Деплоиер, која врши провере здравља, реконфигурише проксије и тако даље. Ово је концепт који се не односи на спољни свет и постоји унутар Кубернетеса. Показаћу вам како можете да креирате сопствени концепт Деплоиер користећи алате отвореног кода.
Дакле, прва ствар коју Деплоиер ради је да креира РЦ контролер репликације користећи Кубернетес АПИ. Овај АПИ креира подове и сервисе за даљу имплементацију, односно креира потпуно нови кластер за наше апликације. Чим се РЦ увери да су реплике покренуте, извршиће проверу здравља њихове функционалности. Да би то урадио, Деплоиер користи команду ГЕТ /хеалтх. Покреће одговарајуће компоненте скенирања и проверава све елементе који подржавају рад кластера.
Након што сви подови пријаве своје здравље, Деплоиер креира нови елемент конфигурације - етцд дистрибуирано складиште, које Кубернетес интерно користи, укључујући складиштење конфигурације балансера оптерећења. Записујемо податке у етцд и мали алат који се зове цонфд мониторс етцд за нове податке.
Ако открије било какве промене у почетној конфигурацији, генерише нову датотеку подешавања и преноси је на ха-проки. У овом случају, ха-проки се поново покреће без губитка везе и адресира оптерећење на нове услуге које омогућавају да нова верзија наших апликација ради.
Као што видите, упркос обиљу компоненти, овде нема ништа компликовано. Само треба да обратите више пажње на АПИ и етцд. Желим да вам кажем о опен-соурце деплоиер-у који и сами користимо - Амдату Кубернетес Деплоиер.
То је алатка за оркестрирање Кубернетес имплементације и има следеће карактеристике:
- Плаво/зелено распоређивање;
- постављање екстерног балансера оптерећења;
- управљање дескриптором распоређивања;
- управљање стварним распоређивањем;
- провера функционалности здравствених провера током примене;
- имплементација варијабли окружења у подс.
Овај Деплоиер је изграђен на врху Кубернетес АПИ-ја и обезбеђује РЕСТ АПИ за управљање ручкама и применама, као и Вебсоцкет АПИ за стримовање евиденције током процеса примене.
Ставља податке о конфигурацији балансера оптерећења у етцд, тако да не морате да користите ха-проки са подршком која је ван кутије, већ лако користите сопствену конфигурациону датотеку балансера оптерећења. Амдату Деплоиер је написан у Го, као и сам Кубернетес, и лиценциран је од стране Апацхе-а.
Пре него што сам почео да користим ову верзију програма за постављање, користио сам следећи дескриптор примене, који одређује параметре који су ми потребни.
Један од важних параметара овог кода је да омогући ознаку „усеХеалтхЦхецк“. Морамо да наведемо да се провера исправности мора извршити током процеса имплементације. Ова поставка се може онемогућити када имплементација користи контејнере треће стране који не морају да буду верификовани. Овај дескриптор такође указује на број реплика и фронтенд УРЛ који је потребан ха-проксију. На крају је заставица спецификације под "подспец", која позива Кубернетес за информације о конфигурацији порта, слици итд. Ово је прилично једноставан ЈСОН дескриптор.
Још један алат који је део Амдату пројекта отвореног кода је Деплоиментцтл. Има корисничко сучеље за конфигурисање примене, чува историју примене и садржи веб-хукове за повратне позиве од корисника и програмера трећих страна. Не можете да користите кориснички интерфејс пошто је Амдату Деплоиер сам РЕСТ АПИ, али овај интерфејс вам може олакшати примену без укључивања било каквог АПИ-ја. Деплоиментцтл је написан у ОСГи/Вертк користећи Ангулар 2.
Сада ћу демонстрирати горе наведено на екрану користећи унапред снимљени снимак тако да не морате да чекате. Ми ћемо применити једноставну Го апликацију. Не брините ако нисте раније испробали Го, то је врло једноставна апликација тако да бисте требали моћи да је схватите.
Овде креирамо ХТТП сервер који одговара само на /хеалтх, тако да ова апликација тестира само проверу здравља и ништа друго. Ако провера прође, користи се доле приказана ЈСОН структура. Садржи верзију апликације коју ће имплементирати имплементатор, поруку коју видите на врху датотеке и логички тип података - да ли наша апликација ради или не.
Мало сам преварио са последњим редом, јер сам поставио фиксну логичку вредност на врх датотеке, што ће ми у будућности помоћи да применим чак и „нездраву“ апликацију. Позабавићемо се овим касније.
Па хајде да почнемо. Прво, проверавамо присуство покренутих подова помоћу команде ~ кубецтл гет подс и, на основу одсуства одговора са фронтенд УРЛ-а, уверавамо се да се тренутно не врши никаква имплементација.
Следеће на екрану видите интерфејс Деплоиментцтл који сам поменуо, у којем су постављени параметри за примену: именски простор, име апликације, верзија примене, број реплика, фронт-енд УРЛ, назив контејнера, слика, ограничења ресурса, број порта за проверу здравља, итд. Ограничења ресурса су веома важна, јер вам омогућавају да користите максималну могућу количину хардвера. Овде такође можете погледати дневник имплементације.
Ако сада поновите команду ~ кубецтл гет подс, можете видети да се систем „замрзава“ на 20 секунди, током којих се ха-проки поново конфигурише. Након овога, под почиње, а наша реплика се може видети у дневнику имплементације.
Из видео снимка сам искључио чекање од 20 секунди и сада можете видети на екрану да је прва верзија апликације постављена. Све ово је урађено само помоћу корисничког интерфејса.
Хајде сада да пробамо другу верзију. Да бих то урадио, мењам поруку апликације са „Здраво, Кубернетес!“ на “Хелло, Деплоиер!”, систем креира ову слику и ставља је у Доцкер регистар, након чега једноставно поново кликнемо на дугме “Деплои” у прозору Деплоиментцтл. У овом случају, дневник имплементације се аутоматски покреће на исти начин као што се десило приликом постављања прве верзије апликације.
Команда ~ кубецтл гет подс показује да тренутно постоје 2 верзије апликације које су покренуте, али фронтенд показује да још увек користимо верзију 1.
Балансатор оптерећења чека да се заврши провера здравља пре него што преусмери саобраћај на нову верзију. После 20 секунди прелазимо на цурл и видимо да је сада примењена верзија 2 апликације, а прва је обрисана.
Ово је била примена „здраве“ апликације. Хајде да видимо шта се дешава ако за нову верзију апликације променим параметар Хеалтхи из труе у фалсе, односно покушам да применим нездраву апликацију која није прошла проверу здравља. Ово се може десити ако су неке конфигурационе грешке направљене у апликацији у фази развоја и она је послата у производњу у овом облику.
Као што видите, имплементација пролази кроз све горе наведене кораке и ~кубецтл гет подс показује да су оба модула покренута. Али за разлику од претходне имплементације, дневник приказује статус временског ограничења. То јест, због чињенице да провера здравља није успела, нова верзија апликације не може да се примени. Као резултат тога, видите да се систем вратио на коришћење старе верзије апликације, а да је нова верзија једноставно деинсталирана.
Добра ствар у вези са овим је да чак и ако имате огроман број истовремених захтева који долазе у апликацију, они неће ни приметити застоје током спровођења процедуре распоређивања. Ако тестирате ову апликацију користећи Гатлинг оквир, који јој шаље што је могуће више захтева, ниједан од ових захтева неће бити одбачен. То значи да наши корисници неће ни приметити ажурирања верзија у реалном времену. Ако не успе, рад ће се наставити на старој верзији, ако је успешан, корисници ће прећи на нову верзију.
Постоји само једна ствар која може да пропадне – ако провера здравља успе, али апликација не успе чим се на њу примени радно оптерећење, односно, колапс ће се десити тек након што се имплементација заврши. У овом случају, мораћете ручно да се вратите на стару верзију. Дакле, погледали смо како да користимо Кубернетес са алатима отвореног кода дизајнираним за то. Процес имплементације ће бити много лакши ако уградите ове алате у своје цевоводе Буилд/Деплои. Истовремено, да бисте започели примену, можете користити или кориснички интерфејс или потпуно аутоматизовати овај процес користећи, на пример, цоммит то мастер.
Наш Буилд Сервер ће креирати Доцкер слику, гурнути је у Доцкер Хуб или било који регистар који користите. Доцкер Хуб подржава вебхоок, тако да можемо покренути даљинско примену преко Деплоиер-а на начин приказан изнад. На овај начин можете у потпуности аутоматизовати примену ваше апликације у потенцијалну производњу.
Пређимо на следећу тему - скалирање Кубернетес кластера. Имајте на уму да је команда кубецтл команда за скалирање. Уз већу помоћ, лако можемо повећати број реплика у нашем постојећем кластеру. Међутим, у пракси обично желимо да повећамо број чворова, а не махуна.
Истовремено, током радног времена ћете можда морати да повећате, а ноћу, да бисте смањили цену Амазонових услуга, можда ћете морати да смањите број покренутих инстанци апликације. То не значи да ће скалирање само броја махуна бити довољно, јер чак и ако је један од чворова неактиван, и даље ћете морати да платите Амазону за то. То јест, заједно са скалирањем махуна, мораћете да скалирате број коришћених машина.
Ово може бити изазовно јер било да користимо Амазон или неку другу услугу у облаку, Кубернетес не зна ништа о броју машина које се користе. Недостаје алатка која вам омогућава да скалирате систем на нивоу чвора.
Дакле, мораћемо да водимо рачуна и о чворовима и о махунама. Лако можемо да скалирамо покретање нових чворова користећи АВС АПИ и Сцалинг групне машине да бисмо конфигурисали број Кубернетес радних чворова. Такође можете користити цлоуд-инит или сличну скрипту да региструјете чворове у Кубернетес кластеру.
Нова машина почиње у групи за скалирање, иницира се као чвор, региструје се у мастер регистру и почиње да ради. Након тога, можете повећати број реплика за употребу на резултујућим чворовима. Смањење захтева више напора, јер морате да се уверите да такав корак не доведе до уништења већ покренутих апликација након искључивања „непотребних“ машина. Да бисте спречили такав сценарио, потребно је да поставите чворове на статус „непланирано“. То значи да ће подразумевани планер игнорисати ове чворове приликом заказивања ДаемонСет подова. Планер неће избрисати ништа са ових сервера, али такође неће покренути нове контејнере тамо. Следећи корак је избацивање одводног чвора, односно пребацивање покренутих подова са њега на другу машину или друге чворове који имају довољан капацитет за ово. Када се уверите да више нема контејнера на овим чворовима, можете да их уклоните из Кубернетес-а. Након овога, они ће једноставно престати да постоје за Кубернетес. Затим морате да користите АВС АПИ да бисте онемогућили непотребне чворове или машине.
Можете користити Амдату Сцалерд, још један алат за скалирање отвореног кода сличан АВС АПИ-ју. Обезбеђује ЦЛИ за додавање или уклањање чворова у кластеру. Његова занимљива карактеристика је могућност конфигурисања планера помоћу следеће јсон датотеке.
Приказани код смањује капацитет кластера за половину током ноћног периода. Он конфигурише и број доступних реплика и жељени капацитет Амазон кластера. Коришћење овог планера аутоматски ће смањити број чворова ноћу и повећати их ујутру, штедећи трошкове коришћења чворова из услуге у облаку као што је Амазон. Ова функција није уграђена у Кубернетес, али коришћење Сцалерда ће вам омогућити да скалирате ову платформу како год желите.
Желео бих да истакнем да ми многи људи кажу: „Све је то у реду, али шта је са мојом базом података, која је обично статична?“ Како можете покренути овако нешто у динамичном окружењу као што је Кубернетес? По мом мишљењу, не би требало да радите ово, не би требало да покушавате да покренете складиште података у Кубернетесу. Ово је технички могуће, а на интернету постоје туторијали на ову тему, али ће вам то озбиљно закомпликовати живот.
Да, постоји концепт трајних продавница у Кубернетес-у и можете покушати да покренете продавнице података као што су Монго или МиСКЛ, али ово је прилично напоран задатак. Ово је због чињенице да складишта података не подржавају у потпуности интеракцију са динамичким окружењем. Већина база података захтева значајну конфигурацију, укључујући ручну конфигурацију кластера, не воли аутоматско скалирање и друге сличне ствари.
Стога, не би требало да компликујете свој живот покушавајући да покренете складиште података у Кубернетес-у. Организујте њихов рад на традиционалан начин користећи познате услуге и једноставно омогућите Кубернетесу могућност да их користи.
Да закључим тему, желео бих да вам представим Цлоуд РТИ платформу засновану на Кубернетес-у, на којој ради мој тим. Пружа централизовано евидентирање, праћење апликација и кластера и многе друге корисне функције које ће вам добро доћи. Користи различите алате отвореног кода као што је Графана за приказ надгледања.
Постојало је питање зашто користити ха-проки балансер оптерећења са Кубернетес-ом. Добро питање јер тренутно постоје 2 нивоа балансирања оптерећења. Кубернетес сервиси се и даље налазе на виртуелним ИП адресама. Не можете их користити за портове на спољним хост машинама јер ако Амазон преоптерети свој хост у облаку, адреса ће се променити. Због тога постављамо ха-проки испред сервиса – да бисмо створили статичнију структуру за неометану комуникацију саобраћаја са Кубернетес-ом.
Још једно добро питање је како можете да се бринете о променама шеме базе података када радите плаво/зелену примену? Чињеница је да је, без обзира на употребу Кубернетеса, промена шеме базе података тежак задатак. Морате осигурати да су стара и нова шема компатибилне, након чега можете ажурирати базу података, а затим ажурирати саме апликације. Можете брзо заменити базу података, а затим ажурирати апликације. Знам за људе који су покренули потпуно нови кластер базе података са новом шемом, ово је опција ако имате базу података без шеме као што је Монго, али то ионако није лак задатак. Ако немате више питања, хвала вам на пажњи!
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом