Данас планирам да причам о томе како писати апликације и који су услови да би ваша апликација добро радила у Кубернетесу. Тако да нема главобоље са апликацијом, тако да не морате да измишљате и правите било какве „греботине“ око ње - и све функционише онако како је сам Кубернетес намеравао.
Ово предавање је део „" Отворена теоријска предавања Вечерње школе можете погледати . За оне који више воле текст него видео, припремили смо овај чланак.
Моје име је Павел Селиванов, тренутно сам водећи ДевОпс инжењер у Маил.ру Цлоуд Солутионс, правимо облаке, правимо кубернете за управљање и тако даље. Моји задаци сада укључују помоћ у развоју, увођење ових облака, увођење апликација које пишемо и директан развој алата које пружамо нашим корисницима.
Ја се бавим ДевОпс-ом, мислим, последње, вероватно, три године. Али, у принципу, радим оно што ДевОпс ради вероватно око пет година. Пре тога сам се углавном бавио администраторским стварима. Почео сам да радим са Кубернетес-ом давно – вероватно је прошло око четири године откако сам почео да радим са њим.
Генерално, почео сам када је Кубернетес био верзија 1.3, вероватно, а можда и 1.2 - када је још био у повојима. Сада више није у повојима – и очигледно је да на тржишту постоји огромна потражња за инжењерима који би желели да могу да раде Кубернетес. А компаније имају веома велику потражњу за таквим људима. Стога се, заправо, и појавило ово предавање.
Ако говоримо по плану о чему ћу причати, то изгледа овако, у заградама је написано (ТЛ;ДР) – „предуго; не читај“. Моја данашња презентација ће се састојати од бескрајних листа.
У ствари, ни ја сам не волим такве презентације када се праве, али ово је толика тема да када сам припремао ову презентацију једноставно нисам смислио како да другачије организујем те информације.
Јер, углавном, ове информације су „цтрл+ц, цтрл+в“, између осталог, са наше Вики у одељку ДевОпс, где смо написали захтеве за програмере: „момци, да покренемо вашу апликацију у Кубернетес, требало би да буде овако."
Зато се испоставило да је презентација била тако велика листа. Извињавам се. Покушаћу да испричам што више да не буде досадно ако је могуће.
Шта ћемо сада да погледамо:
- ово су, прво, логови (дневници апликација?), шта да се ради са њима у Кубернетесу, шта да се ради са њима, шта треба да буду;
- шта радити са конфигурацијама у Кубернетес-у, који су најбољи и најгори начини за конфигурисање апликације за Кубернетес;
- Хајде да разговарамо о томе шта су провере приступачности уопште, како би требало да изгледају;
- хајде да причамо о томе шта је грациозно гашење;
- хајде да поново причамо о ресурсима;
- Дотакнимо се још једном теме складиштења података;
- и на крају ћу вам рећи који је појам ова мистериозна апликација која је изворна у облаку. Облачност, као придев овог појма.
Дневници
Предлажем да почнете од дневника - где ове евиденције треба да се угурају у Кубернетес. Сада сте покренули апликацију у Кубернетесу. Према класицима, раније апликације су увек писале дневнике негде у датотеку. Лоше апликације су писале евиденције у датотеку у матичном директоријуму програмера који је покренуо апликацију. Добре апликације су написале евиденције у датотеку негде у њој /var/log.
Сходно томе, даље, добри администратори су у својим инфраструктурама конфигурисали неке ствари да ови логови могу да ротирају - исти рсислог, који гледа ове логове и када им се нешто деси, има их много, прави резервне копије, ставља дневнике тамо , брише старе датотеке, више од недељу дана, шест месеци и још неке. У теорији, требало би да имамо одредбе тако да једноставно зато што апликација пише дневнике, простор на производним серверима (борбеним серверима?) не понестане. И, сходно томе, читава производња није стала због трупаца.
Када пређемо у свет Кубернетеса и тамо покренемо исту ствар, прво на шта можете да обратите пажњу је чињеница да људи, како су писали логове у фајл, настављају да их пишу.
Испоставило се да ако говоримо о Кубернетес-у, право место за писање дневника негде из доцкер контејнера је једноставно да их запишете из апликације у такозвани Стдоут/Стдерр, односно стандардни излазни токови оперативног система, стандардни излаз грешке. Ово је најисправнији, најједноставнији и најлогичнији начин да се у принципу ставе евиденције у Доцкер и конкретно у Кубернетис. Јер ако ваша апликација пише евиденције у Стдоут/Стдерр, онда је на Доцкер-у и Кубернетес додатку да одлуче шта да раде са овим евиденцијама. Доцкер ће подразумевано изградити своје посебне датотеке у ЈСОН формату.
Овде се поставља питање шта ћете даље да радите са овим логовима? Најлакши начин је јасан, имамо могућности да урадимо kubectl logs и погледајте ове дневнике ових „махуна“. Али, вероватно, ово није баш добра опција - потребно је нешто друго урадити са трупцима.
За сада, хајде да причамо у исто време, пошто смо се дотакли теме дневника, о томе како би трупци требало да изгледају. Односно, ово се не односи директно на Кубернетес, али када почнемо да размишљамо шта да радимо са евиденцијама, било би добро да размислимо и о овоме.
Треба нам нека врста алата, на пријатељски начин, који ће узети ове евиденције које наш доцкер ставља у своје датотеке и послати их негде. Углавном, обично покрећемо неку врсту агента унутар Кубернетеса у облику ДаемонСет-а - сакупљача дневника, коме се једноставно каже где се налазе евиденције које Доцкер прикупља. А овај сакупљач их једноставно узима, можда чак и некако успут анализира, можда их обогати неким додатним мета-информацијама и, на крају, шаље их негде на складиште. Ту су већ могуће варијације. Најчешћи је вероватно Еластицсеарцх, где можете да складиштите евиденције и одатле их можете лако преузети. Затим, користећи захтев, користећи Кибана, на пример, направите графиконе на основу њих, направите упозорења на основу њих итд.
Најважнија идеја, желим да је поновим, јесте да је унутар Доцкер-а, посебно унутар Кубернетеса, чување ваших евиденција у датотеци веома лоша идеја.
Јер, прво, тешко је добити евиденције унутар контејнера у датотеци. Прво морате ући у контејнер, извршити тамо, а затим погледати дневнике. Следећа ствар је да ако имате дневнике у датотеци, онда контејнери обично имају минималистичко окружење и не постоје услужни програми који су обично потребни за нормалан рад са евиденцијама. Закопајте их, погледајте их, отворите их у уређивачу текста. Следећи тренутак је када имамо логове у датотеци унутар контејнера, ако се овај контејнер избрише, разумете, евиденције ће умрети заједно са њим. Сходно томе, свако поновно покретање контејнера значи да више нема евиденције. Опет лоша опција.
И последња тачка је да унутар контејнера обично имате своју апликацију и то је то - обично је то једини процес који се покреће. Уопште нема говора о било каквом процесу који би ротирао датотеке са вашим евиденцијама. Чим евиденције почну да се уписују у датотеку, то значи да ћемо, извините, почети да губимо производни сервер. Јер, прво, тешко их је пронаћи, нико их не прати, плус нико их не контролише - сходно томе, датотека расте бескрајно све док простор на серверу једноставно не понестане. Стога, поново кажем да је пријављивање у Доцкер, посебно у Кубернетес, у датотеку лоша идеја.
Следећа тачка, овде желим поново да причам о овоме - пошто се дотичемо теме дневника, било би добро да разговарамо о томе како би логови требало да изгледају да би било згодно радити са њима. Као што сам рекао, тема није директно везана за Кубернетес, али се веома добро односи на тему ДевОпс-а. На тему културе развоја и пријатељства између ова два различита одељења - Дев и Опс, да свима буде удобно.
То значи да би данас у идеалном случају евиденције требало да буду написане у ЈСОН формату. Ако имате неку своју неразумљиву апликацију, која пише логове у неразумљивим форматима јер убацујете неку врсту принта или тако нешто, онда је време да прогуглате некакав оквир, некакав омотач који вам омогућава да имплементирате нормално логовање; тамо омогући евидентирање параметара у ЈСОН-у, јер је ЈСОН једноставан формат, рашчлањивање је једноставно.
Ако вам ЈСОН не ради по неким критеријумима, нико не зна шта, онда бар напишите дневнике у формату који може да се рашчлани. Овде, радије, вреди размислити о чињеници да, на пример, ако покрећете гомилу контејнера или само процесе са нгинк-ом, и сваки има своја подешавања евидентирања, онда се вероватно чини да ће вам бити веома незгодно да рашчланити их. Зато што за сваку нову нгинк инстанцу треба да напишете сопствени парсер, јер они другачије пишу дневнике. Опет, вероватно је вредело размислити о томе да све ове нгинк инстанце имају исту конфигурацију евидентирања и да су све своје евиденције написале апсолутно уједначено. Исто важи за апсолутно све апликације.
На крају, такође желим да долијем уље на ватру да би, у идеалном случају, требало избегавати дневнике у више редова. Ево у чему је ствар, ако сте икада радили са сакупљачима дневника, онда сте највероватније видели шта вам обећавају, да могу да раде са вишелинијским дневникима, знају како да их сакупљају итд. Заправо, по мом мишљењу, ни један сакупљач данас не може нормално, потпуно и без грешака да сакупља вишелинијске дневнике. На људски начин, тако да је згодно и без грешака.
Али праћење стека је увек вишелинијска евиденција и како их избећи. Питање је да је дневник запис догађаја, а стацтраце заправо није дневник. Ако прикупимо евиденције и ставимо их негде у Еластицсеарцх, а затим из њих извучемо графиконе, направимо неке извештаје о активностима корисника на вашој веб локацији, онда када добијете траг стека, то значи да се дешава нешто неочекивано у вашој апликацији. И има смисла аутоматски отпремити траг стека негде у систем који може да их прати.
Ово је софтвер (исти Сентри) који је направљен посебно за рад са праћењем стека. Може одмах креирати аутоматизоване задатке, доделити их некоме, упозорити када се стацттрацес појаве, груписати ове стацттрацес по једном типу, итд. У принципу, нема много смисла говорити о стацтрацес-има када говоримо о дневникима, јер су то, на крају крајева, различите ствари са различитим сврхама.
Конфигурација
Затим говоримо о конфигурацији у Кубернетес-у: шта да радимо са тим и како треба да се конфигуришу апликације унутар Кубернетеса. Генерално, обично кажем да Доцкер није о контејнерима. Сви знају да се Доцкер бави контејнерима, чак и они који нису много радили са Доцкером. Понављам, Доцкер није у вези са контејнерима.
Доцкер се, по мом мишљењу, односи на стандарде. И постоје стандарди за практично све: стандарди за прављење ваше апликације, стандарди за инсталирање ваше апликације.
А ова ствар – користили смо је раније, управо је постала посебно популарна са појавом контејнера – ова ствар се зове ЕНВ (окружење) променљиве, односно променљиве окружења које се налазе у вашем оперативном систему. Ово је генерално идеалан начин да конфигуришете своју апликацију, јер ако имате апликације у ЈАВА, Питхон, Го, Перл, не дај Боже, и све оне могу да читају хост базе података, корисника базе података, променљиве лозинке базе података, онда је то идеално. Имате апликације на четири различита језика конфигурисане у плану базе података на исти начин. Нема више различитих конфигурација.
Све се може конфигурисати помоћу ЕНВ променљивих. Када говоримо о Кубернетес-у, постоји одличан начин да се декларишу ЕНВ променљиве директно унутар Деплоимент-а. Сходно томе, ако говоримо о тајним подацима, онда можемо одмах да гурнемо тајне податке из ЕНВ променљивих (лозинке за базе података, итд.) у тајну, креирамо тајни кластер и назначимо у ЕНВ опису у Деплоимент-у да не декларишемо директно вредност ове променљиве, а вредност ове променљиве лозинке базе података ће бити прочитана из тајне. Ово је стандардно понашање Кубернетеса. А ово је најидеалнија опција за конфигурисање ваших апликација. Само на нивоу кода, опет ово важи за програмере. Ако сте ДевОпс, можете питати: „Момци, научите своју апликацију да чита променљиве окружења. И сви ћемо бити срећни.”
Ако сви у компанији читају исте именоване променљиве окружења, онда је то сјајно. Да се не деси да једни чекају на постгрес базу, други на име базе, трећи чекају нешто друго, трећи чекају неку врсту дбн-а, тако да, сходно томе, постоји униформност.
Проблем настаје када имате толико променљивих окружења да само отворите Деплоимент - а постоји пет стотина редова променљивих окружења. У овом случају, једноставно сте прерасли варијабле окружења - и више не морате да се мучите. У овом случају, имало би смисла почети користити конфигурације. То јест, обучите своју апликацију да користи конфигурације.
Питање је само да конфигурације нису оно што мислите. Цонфиг.пи није конфигурација која је згодна за коришћење. Или нека конфигурација у вашем формату, алтернативно надарена - ово такође није конфигурација на коју мислим.
Оно о чему говорим је конфигурисање у прихватљивим форматима, односно далеко најпопуларнији стандард је .иамл стандард. Јасно је како се чита, човек је читљив, јасно је како се чита из апликације.
Сходно томе, поред ИАМЛ-а, можете, на пример, да користите и ЈСОН, рашчлањивање је једнако згодно као и ИАМЛ у смислу читања конфигурације апликације одатле. Људима је приметно незгодније да читају. Можете пробати формат, а ла ини. Са људске тачке гледишта, прилично је згодно за читање, али може бити незгодно аутоматски га обрадити, у смислу да ако икада пожелите да генеришете сопствене конфигурације, ини формат можда већ није згодан за генерисање.
Али у сваком случају, који год формат да изаберете, поента је да је са Кубернетес тачке гледишта веома згодно. Можете ставити целу своју конфигурацију у Кубернетес, у ЦонфигМап. И онда узмите ову конфигурациону мапу и замолите је да се монтира унутар вашег под-а у неком одређеном директоријуму, где ће ваша апликација прочитати конфигурацију са ове конфигурационе мапе као да је то само датотека. Ово је, у ствари, оно што је добро урадити када имате пуно опција конфигурације у вашој апликацији. Или је то само нека сложена структура, постоји гнежђење.
Ако имате конфигурациону мапу, онда можете врло добро да научите своју апликацију, на пример, да аутоматски прати промене у датотеци где је конфигурациона мапа монтирана, и такође аутоматски поново учитава вашу апликацију када се конфигурације промене. Ово би генерално била идеална опција.
Опет, већ сам говорио о овоме - тајне информације нису у конфигурационој мапи, тајне информације нису у варијаблама, тајне информације нису у тајнама. Одатле повежите ове тајне информације са дипломатијом. Обично све описе Кубернетес објеката, имплементација, конфигурационих мапа, услуга чувамо у гит-у. Сходно томе, стављање лозинке за базу података у гит, чак и ако је то ваш гит, који имате интерно у компанији, је лоша идеја. Јер, у најмању руку, гит памти све и једноставно уклањање лозинки одатле није тако лако.
Здравствени преглед
Следећа тачка је ова ствар која се зове Здравствена провера. Генерално, провера здравља је једноставно провера да ли ваша апликација ради. При томе, најчешће говоримо о одређеним веб апликацијама, за које ће, сходно томе, са становишта здравствене провере (боље је не преводити овде и даље) то бити нека посебна УРЛ адреса, коју они обрађују као стандард, обично раде /health.
Приликом приступа овој УРЛ адреси, сходно томе, наша апликација каже или „да, добро, све је у реду са мном, 200“ или „не, није све у реду са мном, неких 500“. Сходно томе, ако наша апликација није хттп, није веб апликација, сада говоримо о некаквом демону, можемо смислити како да урадимо здравствене провере. Односно, није неопходно, ако апликација није хттп, онда све ради без здравствене провере и то никако не може да се уради. Можете периодично ажурирати неке информације у датотеци, можете смислити неку посебну команду за свој демон, као, daemon status, који ће рећи „да, све је у реду, демон ради, жив је“.
За шта је то? Прва и најочигледнија ствар је вероватно зашто је потребна здравствена провера - да би се разумело да апликација ради. Мислим, једноставно је глупо, када је сада горе, изгледа да ради, тако да можете бити сигурни да ради. И испоставило се да апликација ради, контејнер ради, инстанца ради, све је у реду - а онда су корисници већ прекинули све бројеве телефона техничке подршке и рекли „шта си ти..., ти заспао, ништа не ради.”
Здравствена провера је управо такав начин да се са становишта корисника види да функционише. Једна од метода. Рецимо то овако. Са становишта Кубернетеса, ово је такође начин да се разуме када се апликација покреће, јер разумемо да постоји разлика између времена када је контејнер покренут, креиран и покренут и када је апликација покренута директно у овом контејнеру. Јер ако узмемо неку просечну јава апликацију и покушамо да је покренемо у доку, онда на четрдесет секунди, или чак минут, или чак десет, може да почне сасвим добро. У овом случају, можете бар да куцате на његове портове, он неће одговорити тамо, односно још није спреман за пријем саобраћаја.
Опет, уз помоћ здравствене провере и уз помоћ чињенице да се овде окрећемо, у Кубернетесу можемо разумети да се не само да се контејнер у апликацији подигао, већ је и сама апликација покренута, већ одговара на здравствену проверу, што значи да можемо тамо послати саобраћај.
Оно о чему сада говорим се зове тестови спремности/живости унутар Кубернетеса, сходно томе, наши тестови спремности су одговорни за доступност апликације у балансирању. То јест, ако се у апликацији врше тестови спремности, онда је све у реду, клијентски саобраћај иде у апликацију. Ако се тестови спремности не изврше, онда апликација једноставно не учествује, ова конкретна инстанца не учествује у балансирању, уклања се из балансирања и клијентски саобраћај не тече. Сходно томе, тестови Ливенесс-а у оквиру Кубернетес-а су потребни да би се, ако се апликација заглави, могла поново покренути. Ако тест живости не ради за апликацију која је декларисана у Кубернетес-у, онда се апликација не само уклања из балансирања, већ се поново покреће.
И ево једне важне тачке коју бих желео да напоменем: са практичне тачке гледишта, тест спремности се обично користи чешће и чешће је потребан од теста живости. Односно, једноставно непромишљено декларисање и тестова спремности и животности, јер Кубернетес то може, и хајде да искористимо све што може, није баш добра идеја. Објаснићу зашто. Јер тачка број два у тестирању је да би било добро да проверите основну услугу у вашим здравственим прегледима. То значи да ако имате веб апликацију која даје неке информације, које она, наравно, мора однекуд узети. У бази података, на пример. Па, он чува информације које долазе у овај РЕСТ АПИ у исту базу података. Затим, сходно томе, ако ваша здравствена провера реагује једноставно као контактиран сласххеалтх, апликација каже „200, у реду, све је у реду“, а истовремено је база података ваше апликације недоступна, а апликација Хеалтхцхецк каже „200, у реду, све је у реду ” – Ово је лош здравствени преглед. Овако не би требало да функционише.
Односно, ваша пријава, када јој дође захтев /health, не одговара само „200, ок“, прво иде, на пример, у базу података, покушава да се повеже са њом, ради нешто веома основно тамо, као што је изаберите једну, само проверава да ли постоји веза у базу података и можете поставити упит бази података. Ако је све ово било успешно, онда је одговор "200, ок." Ако не успе, пише да је дошло до грешке, база података је недоступна.
Стога, у вези са тим, поново се враћам на тестове спремности/живости - зашто вам је највероватније потребан тест спремности, а тест животности је у питању. Јер ако опишете здравствене прегледе тачно као што сам управо рекао, онда ће се испоставити да то није доступно у делу инстанцев или со всех instanceу бази података, на пример. Када сте прогласили тест спремности, наше здравствене провере су почеле да не успевају, и сходно томе све апликације из којих база података није доступна, једноставно се искључују из балансирања и заправо „висе“ само у запуштеном стању и чекају да се њихове базе података рад.
Ако смо прогласили тест живости, онда замислите, наша база података је покварена, а у вашем Кубернетес-у пола свега почиње да се поново покреће јер тест живости не успе. То значи да морате поново покренути. Ово уопште није оно што желите, чак сам имао лично искуство у пракси. Имали смо апликацију за ћаскање која је била написана на ЈС-у и унета у Монго базу података. А проблем је био што смо на почетку мог рада са Кубернетесом описали спремност, живост тестова по принципу да Кубернетес то може, па ћемо га користити. Сходно томе, у неком тренутку Монго је постао мало „туп“ и узорак је почео да пропада. Сходно томе, према тесту кише, махуне су почеле да "убијају".
Као што разумете, када су „убијени“, ово је ћаскање, односно на њему виси много веза клијената. Они су и „убијани“ – не, не клијенти, само везе – не сви у исто време, а због чињенице да нису убијени у исто време, неки раније, неки касније, не почињу у исто време време. Плус стандардно насумично, не можемо да предвидимо са тачношћу од милисекунди време почетка апликације сваки пут, тако да они то раде једну по једну инстанцу. Један инфоспот се диже, додаје се на балансирање, сви клијенти долазе тамо, не може да издржи такво оптерећење, јер је сам, а, грубо речено, ради их десетак, и пада. Следећи се диже, цео терет је на њему, он такође пада. Па, ови падови само настављају да каскадирају. На крају, како је то решено – само смо морали стриктно да зауставимо кориснички саобраћај ка овој апликацији, да пустимо све инстанце да се подигну и онда да покренемо сав кориснички саобраћај одједном тако да је већ распоређен на свих десет инстанци.
Да није било најављеног теста живости, који би приморао да се све поново покрене, апликација би то сасвим добро решила. Али све од балансирања нам је онемогућено, јер су базе података недоступне и сви корисници су „отпали“. Затим, када ова база података постане доступна, све је укључено у балансирање, али апликације не морају поново да се покрећу, и нема потребе да губите време и ресурсе на ово. Сви су већ ту, спремни су за саобраћај, па се саобраћај тек отвара, све је у реду - апликација је на месту, све ради.
Дакле, тестови спремности и животности су различити, чак штавише, теоретски можете радити различите здравствене провере, један тип радијуса, један тип лив, на пример, и проверавати различите ствари. Током тестова спремности, проверите своје позадине. А на тесту живости, на пример, не проверавате са тачке гледишта да је тест живахности генерално само апликација која реагује, ако је уопште у стању да реагује.
Зато што је тест животности, углавном, када смо „заглављени“. Почела је бесконачна петља или нешто друго - и више се захтеви не обрађују. Стога их има смисла чак и раздвојити – и имплементирати у њих другачију логику.
Што се тиче тога шта треба да одговорите када имате тест, када радите здравствене прегледе. То је стварно бол. Они који су упознати са овим ће се вероватно насмејати – али озбиљно, видео сам услуге у свом животу које одговарају са „200“ у XNUMX% случајева. Односно ко је успешан. Али у исто време у телу одговора пишу „тава и таква грешка“.
То јест, статус одговора вам долази - све је успешно. Али у исто време, морате рашчланити тело, јер тело каже „извините, захтев је завршен са грешком“ и то је само реалност. Видео сам ово у стварном животу.
И да некима то не би било смешно, а другима веома болно, ипак се вреди придржавати једноставног правила. У здравственим прегледима, и у принципу при раду са веб апликацијама.
Ако је све прошло добро, одговорите са две стотине одговора. У принципу, одговараће вам било који двестоти одговор. Ако добро читате рагси и знате да се неки статуси одговора разликују од других, одговорите одговарајућим: 204, 5, 10, 15, било шта. Ако није баш добро, онда само „два нула нула“. Ако све прође лоше, а здравствени преглед не реагује, одговорите са било којом петстотином. Опет, ако разумете како да одговорите, колико се различити статуси одговора разликују један од другог. Ако не разумете, онда је 502 ваша опција да одговорите на здравствене прегледе ако нешто крене наопако.
Ово је још једна ствар, желим да се вратим мало на проверу основних услуга. Ако почнете, на пример, да проверавате све основне услуге које стоје иза ваше апликације - све уопштено. Оно што добијамо са становишта микросервисне архитектуре, имамо концепт као што је „ниска спрега“ - то јест, када су ваше услуге минимално зависне једна од друге. Ако један од њих не успе, сви остали без ове функционалности ће једноставно наставити да раде. Неке функције једноставно не раде. Сходно томе, ако повежете све здравствене прегледе једни са другима, онда ћете завршити са једним недостатком у инфраструктури, а пошто је пала, сви здравствени прегледи свих услуга такође почињу да пропадају - и постоји више инфраструктуре уопште за целокупна микросервисна архитектура бр. Тамо се све замрачило.
Због тога желим још једном да поновим да треба да проверите основне услуге, оне без којих ваша апликација у сто одсто случајева не може да ради свој посао. Односно, логично је да ако имате РЕСТ АПИ преко којег корисник чува у бази података или преузима из базе, онда у одсуству базе података не можете гарантовати рад са својим корисницима.
Али ако су ваши корисници, када их извадите из базе података, додатно обогаћени неким другим метаподацима, са другог бекенда, које уносите пре него што пошаљете одговор на фронтенд – а овај бекенд није доступан, то значи да дајете свој одговор без икаквог дела метаподатака.
Затим, имамо и један од болних проблема приликом покретања апликација.
У ствари, ово се углавном не односи само на Кубернетес, једноставно се догодило да је култура неке врсте масовног развоја и ДевОпс-а почела да се шири отприлике у исто време када и Кубернетес. Стога се, углавном, испоставило да морате грациозно да затворите своју апликацију без Кубернетеса. И пре Кубернетеса, људи су то радили, али са појавом Кубернетеса почели смо масовно да причамо о томе.
Грацефул Схутдовн
Генерално, шта је Грацефул Схутдовн и зашто је потребно? Ради се о томе када се ваша апликација из неког разлога руши, што морате да урадите app stop - или добијете, на пример, сигнал од оперативног система, ваша апликација мора да га разуме и уради нешто по том питању. Најгори сценарио је, наравно, када ваша апликација добије СИГТЕРМ и гласи „СИГТЕРМ, хајде да се држимо, радимо, не радимо ништа“. Ово је сасвим лоша опција.
Скоро једнако лоша опција је када ваша апликација прими СИГТЕРМ и буде као „рекли су сегтерм, то значи да завршавамо, нисам видео, не знам ниједан захтев корисника, не знам какав захтеве на којима тренутно радим, рекли су СИГТЕРМ, то значи да завршавамо " Ово је такође лоша опција.
Која је опција добра? Прва тачка је да се узме у обзир завршетак операција. Добра опција је да ваш сервер и даље узима у обзир шта ради ако прими СИГТЕРМ.
СИГТЕРМ је меко гашење, посебно је дизајнирано, може се пресрести на нивоу кода, може се обрадити, реци то сад, чекај, прво ћемо завршити посао који имамо, па ћемо изаћи.
Из Кубернетес перспективе, овако изгледа. Када кажемо модулу који ради у Кубернетес кластеру, „молим вас зауставите, одлазите,“ или смо поново покренути, или дође до ажурирања када Кубернетес поново креира модуле, Кубернетес шаље исту СИГТЕРМ поруку модулу, чека неко време, и, ово је време које он чека, такође је конфигурисано, постоји такав посебан параметар у дипломама и зове се Грацефул СхутдовнТимеоут. Као што разумете, не зове се тако џабе, и није узалуд што сада о томе причамо.
Тамо можемо конкретно да кажемо колико дуго треба да чекамо између времена када пошаљемо СИГТЕРМ апликацији и када схватимо да је апликација полудела за нечим или да се „заглавила“ и да се неће завршити – а ми треба да пошаљите му СИГКИЛЛ, односно тешко завршите свој посао. То јест, сходно томе, имамо неку врсту демона који ради, он обрађује операције. Разумемо да у просеку наше операције на којима демон ради не трају дуже од 30 секунди. Сходно томе, када СИГТЕРМ стигне, разумемо да наш демон може, највише, да заврши 30 секунди после СИГТЕРМ-а. Напишемо то, на пример, 45 секунди за сваки случај и кажемо да СИГТЕРМ. Након тога чекамо 45 секунди. У теорији, за то време демон је требало да заврши свој посао и да се заврши. Али ако одједном не може, то значи да се највероватније заглавило - више не обрађује наше захтеве нормално. И за 45 секунди можете безбедно, у ствари, да га закуцате.
И овде се, у ствари, могу узети у обзир чак 2 аспекта. Прво, схватите да ако сте добили захтев, почели сте некако да радите са њим и нисте дали одговор кориснику, али сте добили СИГТЕРМ, на пример. Има смисла то прецизирати и дати одговор кориснику. Ово је тачка број један у овом погледу. Тачка број два овде је да ако напишете сопствену апликацију, генерално изградите архитектуру на такав начин да добијете захтев за своју апликацију, онда започнете неки посао, почнете да преузимате датотеке однекуд, преузимате базу података и шта не. То. Генерално, ваш корисник, ваш захтев виси пола сата и чека да му одговорите - тада, највероватније, треба да радите на архитектури. То јест, само узмите у обзир чак и здрав разум да ако су ваше операције кратке, онда има смисла игнорисати СИГТЕРМ и модификовати га. Ако су ваше операције дуге, онда нема смисла игнорисати СИГТЕРМ у овом случају. Има смисла редизајнирати архитектуру како би се избегле тако дуге операције. Тако да корисници не само да се мотају и чекају. Не знам, направи ту неку врсту вебсоцкета, направи реверсе хоокове које ће твој сервер већ послати клијенту, било шта друго, али немој терати корисника да виси пола сата и само чекај сесију док ти одговори му. Зато што је непредвидиво где се може покварити.
Када се ваша апликација заврши, требало би да наведете неки одговарајући излазни код. То јест, ако је од ваше апликације затражено да се затвори, заустави и она је могла да се сама заустави нормално, онда не морате да враћате неку врсту излазног кода 1,5,255 и тако даље. Све што није нулти код, барем у Линук системима, сигуран сам у ово, сматра се неуспешним. Односно, сматра се да се ваша пријава у овом случају завршила грешком. Сходно томе, на пријатељски начин, ако је ваша апликација завршена без грешке, кажете 0 на излазу. Ако ваша апликација не успе из неког разлога, кажете да није-0 у излазу. И можете радити са овим информацијама.
И последња опција. Лоше је када ваш корисник пошаље захтев и виси пола сата док га обрађујете. Али генерално, такође бих желео да кажем шта је уопште вредно тога са стране клијента. Није важно да ли имате мобилну апликацију, фронт-енд итд. Неопходно је узети у обзир да генерално сесија корисника може бити прекинута, може се десити свашта. Захтев може бити послат, на пример, недовољно обрађен и без одговора. Ваш фронтенд или ваша мобилна апликација - било који фронтенд уопште, хајде да то тако кажемо - треба да узме ово у обзир. Ако радите са вебсоцкет-има, ово је генерално најгори бол који сам икада имао.
Када програмери неких редовних ћаскања то не знају, испоставило се да се вебсоцкет може покварити. За њих, када се нешто деси на проксију, ми само променимо конфигурацију и она се поново учитава. Наравно, све дуговечне сесије су у овом случају поцепане. Програмери нам притрчавају и кажу: „Момци, шта радите, разговор се покварио за све наше клијенте!“ Кажемо им: „Шта то радите? Да ли ваши клијенти не могу да се поново повежу? Кажу: „Не, треба да се седнице не кидају. Укратко, ово је заправо глупост. Потребно је узети у обзир страну клијента. Нарочито, као што сам рекао, са дуготрајним сесијама као што су вебсоцкети, може се покварити и, неприметно од стране корисника, морате бити у могућности да поново инсталирате такве сесије. И онда је све савршено.
Ресурси
Заправо, овде ћу вам испричати праву причу. Опет из стварног живота. Најболеснија ствар коју сам икада чуо о ресурсима.
Ресурси у овом случају, мислим на неке врсте захтева, ограничења која можете ставити на подове у својим Кубернетес кластерима. Најсмешнија ствар коју сам чуо од програмера... Један од мојих колега програмера на претходном месту рада је једном рекао: „Моја апликација неће почети у кластеру.“ Погледао сам да не почиње, али или се није уклапао у ресурсе, или су поставили врло мала ограничења. Укратко, апликација не може да се покрене због ресурса. Кажем: „Неће почети због ресурса, ви одлучите колико вам треба и одредите адекватну вредност. Он каже: "Какви ресурси?" Почео сам да му објашњавам да треба поставити Кубернетес, ограничења на захтеве и бла, бла, бла. Човек је слушао пет минута, климнуо главом и рекао: „Дошао сам овде да радим као програмер, не желим да знам ништа о било каквим ресурсима. Дошао сам овде да напишем код и то је то." То је тужно. Ово је веома тужан концепт са тачке гледишта програмера. Поготово у савременом свету, да тако кажем, прогресивних девопова.
Зашто су ресурси уопште потребни? У Кубернетесу постоје 2 врсте ресурса. Неки се зову захтеви, други се зову ограничења. Под ресурсима ћемо разумети да у основи увек постоје само два основна ограничења. То јест, временска ограничења ЦПУ-а и ограничења РАМ-а за контејнер који ради у Кубернетес-у.
Ограничење поставља горњу границу начина на који се ресурс може користити у вашој апликацији. То јест, сходно томе, ако кажете 1ГБ РАМ-а у границама, онда ваша апликација неће моћи да користи више од 1ГБ РАМ-а. А ако он то изненада пожели и покуша да уради, онда ће процес који се зове оом убица, без меморије, то јест, доћи и убити вашу апликацију - то јест, једноставно ће се поново покренути. Апликације се неће поново покренути на основу ЦПУ-а. Што се тиче ЦПУ-а, ако апликација покушава да користи много, више него што је наведено у ограничењима, ЦПУ ће једноставно бити строго одабран. Ово не доводи до поновног покретања. Ово је граница - ово је горња граница.
И постоји захтев. Захтев је како Кубернетес разуме како су чворови у вашем Кубернетес кластеру попуњени апликацијама. То јест, захтев је нека врста обавезе ваше апликације. Пише оно што желим да користим: „Желео бих да резервишете оволико ЦПУ-а и оволико меморије за мене.“ Тако једноставна аналогија. Шта ако имамо чвор који има, не знам, укупно 8 ЦПУ-а. И тамо стиже под, чији захтеви кажу 1 ЦПУ, што значи да чвор има 7 преосталих ЦПУ-а. То јест, сходно томе, чим 8 подова стигне на овај чвор, од којих сваки има 1 ЦПУ у својим захтевима, чвор, као да је са становишта Кубернетеса, остао без ЦПУ-а и више подова са захтевима не може бити покренут на овом чвору. Ако сви чворови остану без ЦПУ-а, Кубернетес ће почети да говори да у кластеру нема одговарајућих чворова за покретање ваших подова јер је ЦПУ понестало.
Зашто су потребни захтеви и зашто без захтева, мислим да нема потребе да се било шта покреће у Кубернетесу? Хајде да замислимо хипотетичку ситуацију. Покренете своју апликацију без захтева, Кубернетес не зна колико тога имате, на које чворове можете да је гурнете. Па, гура, гура, гура на чворове. У неком тренутку ћете почети да добијате саобраћај на вашој апликацији. И једна од апликација одједном почиње да користи ресурсе до граница које има према границама. Испоставило се да постоји још једна апликација у близини и да су јој такође потребни ресурси. Чвору заправо почиње физички понестајати ресурса, на пример, ОП. Чвору заправо почиње физички да понестаје ресурса, на пример, меморије са случајним приступом (РАМ). Када чвор остане без струје, пре свега ће престати да реагује докер, затим кубелет, а затим ОС. Једноставно ће се онесвестити и СВЕ ће дефинитивно престати да ради за вас. То јест, ово ће довести до тога да се ваш чвор заглави и мораћете да га поново покренете. Укратко, ситуација није баш добра.
А када имате захтеве, ограничења се не разликују много, барем не много пута више од ограничења или захтева, онда можете имати тако нормално, рационално попуњавање апликација преко чворова Кубернетес кластера. У исто време, Кубернетес је отприлике свестан колико шта где ставља, колико се где користи. Односно, то је само такав тренутак. Важно је то разумети. И важно је контролисати да је то назначено.
Складиштење података
Наша следећа тачка је о складиштењу података. Шта да радимо са њима и уопште, шта да радимо са истрајношћу у Кубернетесу?
Мислим, опет, унутар нашег , постојала је тема о бази података у Кубернетесу. И чини ми се да чак отприлике знам шта су вам колеге рекле на питање: „Да ли је могуће покренути базу података у Кубернетесу?“ Из неког разлога, чини ми се да су ваше колеге требало да вам кажу да ако постављате питање да ли је могуће покренути базу података у Кубернетесу, онда је то немогуће.
Логика је овде једноставна. За сваки случај, још једном ћу вам објаснити, ако сте стварно кул момак који може да изгради прилично толерантни систем дистрибуираног мрежног складиштења, разумете како да уклопите базу података у овај случај, како би требало да функционише цлоуд изворни у контејнерима у бази података уопште. Највероватније, немате питања о томе како да га покренете. Ако имате такво питање, и желите да будете сигурни да се све одвија и да стоји до смрти у производњи и да никада не падне, онда се то неће догодити. Оваквим приступом гарантовано ћете пуцати себи у ногу. Према томе, боље је не.
Шта да радимо са подацима које наша апликација жели да сачува, неким сликама које корисници постављају, неким стварима које наша апликација генерише током свог рада, на пример при покретању? Шта радити са њима у Кубернетесу?
Генерално, идеално, да, наравно, Кубернетес је веома добро дизајниран и генерално је првобитно замишљен за апликације без држављанства. Односно, за оне апликације које уопште не чувају информације. Ово је идеално.
Али, наравно, идеална опција не постоји увек. Па шта? Прва и најједноставнија тачка је да узмете неки С3, само не домаћи, који такође није јасно како ради, већ од неког провајдера. Добар, нормалан провајдер - и научи своју апликацију да користи С3. Односно, када ваш корисник жели да отпреми датотеку, реците „овде, молим, отпремите је на С3“. Када жели да га прими, реците: „Ево линка за С3 назад и преузми га одавде.“ Ово је идеално.
Ако изненада из неког разлога ова идеална опција није прикладна, имате апликацију коју нисте написали, не развијате или је нека врста страшног наслеђа, не може да користи С3 протокол, већ мора да ради са локалним директоријумима у локалне фасцикле . Узмите нешто мање-више једноставно, примените Кубернетес. Односно, одмах оградити Цепх за неке минималне задатке, чини ми се, је лоша идеја. Јер Цеф је, наравно, добар и модеран. Али ако заиста не разумете шта радите, онда када једном ставите нешто на Цепх, можете врло лако и једноставно никада више то извући одатле. Јер, као што знате, Цепх чува податке у свом кластеру у бинарном облику, а не у облику једноставних датотека. Стога, ако се изненада Цепх кластер поквари, постоји потпуна и велика вероватноћа да никада више нећете добити своје податке одатле.
Имаћемо курс о Цепху, можете .
Због тога је боље урадити нешто једноставно као што је НФС сервер. Кубернетес може да ради са њима, можете да монтирате директоријум испод НФС сервера - ваша апликација је као локални директоријум. У исто време, наравно, морате схватити да, опет, морате нешто да урадите са својим НФС-ом, морате схватити да понекад може постати недоступан и размислити о томе шта ћете учинити у овом случају. Можда би требало да се направи резервна копија негде на посебној машини.
Следећа тачка о којој сам говорио је шта треба урадити ако ваша апликација генерише неке датотеке током рада. На пример, када се покрене, генерише неку статичку датотеку, која се заснива на неким информацијама које апликација добија само у тренутку покретања. Какав тренутак. Ако таквих података нема много, онда се уопште не морате мучити, само инсталирајте ову апликацију за себе и радите. Питање је само шта, види. Врло често, свакакви застарели системи, попут ВордПресс-а и тако даље, посебно са модификованим некаквим паметним додацима, паметним ПХП програмерима, често знају како да то направе тако да сами генеришу неку врсту фајла. Сходно томе, један генерише једну датотеку, други генерише другу датотеку. Они су различити. Балансирање се дешава у Кубернетес кластеру купаца једноставно случајно. Сходно томе, испада да на пример не знају како да раде заједно. Један даје једну информацију, други даје кориснику другу информацију. Ово је нешто што треба да избегавате. То јест, у Кубернетесу, све што покренете гарантовано ће моћи да ради у више инстанци. Зато што је Кубернетес покретна ствар. Сходно томе, он може да помери било шта, кад год пожели, а да никога уопште не пита. Стога, морате рачунати на ово. Све што је покренуто у једном случају ће пре или касније пропасти. Што више резервација имате, то боље. Али опет, кажем, ако имате неколико таквих фајлова, онда их можете ставити тачно испод себе, они су мало тешки. Ако их има мало више, вероватно их не бисте требали гурати у контејнер.
Саветовао бих да постоји тако дивна ствар у Кубернетесу, можете користити волумен. Конкретно, постоји волумен типа празан дир. Односно, Кубернетес ће аутоматски креирати директоријум у својим сервисним директоријумима на серверу на ком сте започели. И он ће вам га дати да га користите. Постоји само једна важна тачка. То јест, ваши подаци неће бити ускладиштени унутар контејнера, већ на хосту на којем радите. Штавише, Кубернетес може да контролише такве празне директоријуме под нормалном конфигурацијом и може да контролише њихову максималну величину и не дозволи да се она прекорачи. Једина ствар је да се оно што сте написали у празном директоријуму не изгуби током рестартовања под. То јест, ако ваша махуна грешком падне и поново се подигне, информације у празном директоријуму неће отићи никуда. Може га поново користити на новом почетку - и то је добро. Ако ваша махуна оде негде, онда ће наравно отићи без података. То јест, чим под из чвора где је покренут са празним директоријумом нестане, празан директоријум се брише.
Шта је још добро у празном диру? На пример, може се користити као кеш меморија. Замислимо да наша апликација генерише нешто у ходу, даје то корисницима и то ради дуго времена. Дакле, апликација је, на пример, генерише и даје корисницима, а притом је негде и складишти, тако да ће следећи пут када корисник дође по исту ствар, брже да је да одмах генерисану. Празан директоријум се може затражити од Кубернетеса да га креира у меморији. И стога, ваши кешови генерално могу да раде муњевитом брзином - у смислу брзине приступа диску. То јест, имате празан директоријум у меморији, у ОС-у је ускладиштен у меморији, али за вас, за корисника унутар под-а, то изгледа само као локални директоријум. Није вам потребна апликација да бисте посебно подучавали било какву магију. Ви само директно узимате и стављате своју датотеку у директоријум, али, у ствари, у меморију на ОС-у. Ово је такође веома згодна карактеристика у погледу Кубернетеса.
Какве проблеме има Минио? Главни проблем са Миниом је што да би ова ствар функционисала, мора негде да ради и да постоји нека врста система датотека, односно складиштења. И овде се сусрећемо са истим проблемима које има Цепх. То јест, Минио мора негде да складишти своје датотеке. То је једноставно ХТТП интерфејс за ваше датотеке. Штавише, функционалност је очигледно лошија од оне код Амазоновог С3. Раније није био у могућности да правилно овласти корисника. Сада, колико ја знам, већ може да креира канте са различитим овлашћењима, али опет, чини ми се да је главни проблем, да тако кажем, основни систем складиштења на минимум.
Како Празан директоријум у меморији утиче на ограничења? Ни на који начин не утиче на границе. Лежи у меморији домаћина, а не у меморији вашег контејнера. То јест, ваш контејнер не види празан директоријум у меморији као део своје заузете меморије. Домаћин ово види. Сходно томе, да, са становишта кубернетеса, када почнете да користите ово, било би добро да схватите да део своје меморије посвећујете празном директоријуму. И сходно томе, схватите да меморија може да понестане не само због апликација, већ и зато што неко пише у ове празне директоријуме.
Цлоуднативенесс
И последња подтема је шта је Цлоуднативе. Зашто је то потребно? Облачност и тако даље.
Односно оне апликације које су способне и написане да раде у савременој инфраструктури облака. Али, у ствари, Цлоуднативе има још један такав аспект. Да ово није само апликација која узима у обзир све захтеве савремене клауд инфраструктуре, већ и зна како да ради са овом савременом клауд инфраструктуром, искористите предности и мане чињенице да ради у овим облацима. Немојте само претерати и радити у облацима, већ искористите предности рада у облаку.
Узмимо само Кубернетес као пример. Ваша апликација ради у Кубернетес-у. Ваша апликација увек може, односно администратори ваше апликације, увек могу да креирају налог услуге. То јест, налог за ауторизацију у самом Кубернетес-у на његовом серверу. Додајте тамо нека права која су нам потребна. И можете приступити Кубернетесу из ваше апликације. Шта можете учинити на овај начин? На пример, из апликације примите податке о томе где се налазе ваше друге апликације, друге сличне инстанце и заједно се некако групишу на врху Кубернетеса, ако постоји таква потреба.
Опет, недавно смо буквално имали случај. Имамо једног контролора који прати ред. А када се неки нови задаци појаве у овом реду, он иде у Кубернетес - и унутар Кубернетеса креира нови под. Даје овом под неки нови задатак и у оквиру овог под-а, под извршава задатак, шаље одговор самом контролору, а контролор онда ради нешто са овом информацијом. На пример, додаје базу података. То је, опет, плус чињенице да наша апликација ради у Кубернетесу. Можемо користити саму уграђену Кубернетес функционалност да бисмо некако проширили и учинили функционалност наше апликације практичнијом. То јест, немојте скривати неку магију о томе како да покренете апликацију, како да покренете радника. У Кубернетес-у једноставно шаљете захтев у апликацију ако је апликација написана у Питхон-у.
Исто важи и ако идемо даље од Кубернетеса. Имамо наш Кубернетес који ради негде - добро је ако је у некој врсти облака. Опет, можемо да користимо, па чак и треба, верујем, да користимо могућности самог облака тамо где трчимо. Од елементарних ствари које нам облак пружа. Балансирање, односно можемо да креирамо клауд балансере и да их користимо. Ово је директна предност онога што можемо да искористимо. Зато што балансирање облака, прво, једноставно глупо скида одговорност са нас за то како функционише, како је конфигурисано. Осим тога, веома је згодно, јер се обични Кубернетес може интегрисати са облацима.
Исто важи и за скалирање. Обични Кубернетес може да се интегрише са добављачима у облаку. Зна како да разуме да ако у кластеру понестане чворова, односно понестане простора за чворове, онда треба да додате - сам Кубернетес ће додати нове чворове у ваш кластер и почети да покреће подове на њима. То јест, када дође ваше оптерећење, број огњишта почиње да се повећава. Када понестане чворова у кластеру за ове подове, Кубернетес покреће нове чворове и, сходно томе, број подова и даље може да се повећа. И веома је згодно. Ово је директна прилика за скалирање кластера у ходу. Не баш брзо, у смислу да није секунда, више је као минут за додавање нових чворова.
Али из мог искуства, опет, то је нешто најбоље што сам икада видео. Када је кластер Цлоуднативе скалиран на основу доба дана. То је била позадинска услуга коју су користили људи у позадинској канцеларији. Односно, они долазе на посао у 9 ујутро, почињу да се пријављују у систем, и сходно томе, Цлоуднативе кластер, где све ради, почиње да набуја, покрећући нове подове тако да свако ко дође на посао може да ради са апликацијом. Када напусте посао у 8 или 6 часова, Кубернетес кластери примећују да нико више не користи апликацију и почињу да се смањују. Уштеде до 30 одсто су загарантоване. У то време је функционисало у Амазону, у то време није било никога ко би то могао да уради тако добро.
Рећи ћу вам директно, уштеде су 30 посто једноставно зато што користимо Кубернетес и користимо предности облака. Сада се то може урадити у Русији. Нећу се никоме оглашавати, наравно, али рецимо само да постоје провајдери који то могу да ураде, да то обезбеде одмах из кутије помоћу дугмета.
Постоји још једна ствар на коју бих такође желео да вам скренем пажњу. Да би ваша апликација, ваша инфраструктура била Цлоуднативе, има смисла да коначно почнете да прилагођавате приступ који се зове Инфраструктура као код, то јест, то значи да је ваша апликација, односно ваша инфраструктура, потребна на потпуно исти начин цоде Опишите своју апликацију, своју пословну логику у облику кода. И радите са њим као кодом, односно тестирајте га, развијајте га, чувајте га у гит-у, примените ЦИЦД на њега.
И управо то вам омогућава, прво, да увек имате контролу над својом инфраструктуром, да увек разумете у каквом је стању. Друго, избегавајте ручне операције које узрокују грешке. Треће, избегавајте једноставно оно што се зове флуктуација, када стално морате да обављате исте ручне задатке. Четврто, омогућава вам да се опоравите много брже у случају квара. У Русији, сваки пут када причам о томе, увек постоји огроман број људи који кажу: „Да, јасно је, али имате приступе, укратко, нема потребе да се поправља. Али то је истина. Ако је нешто покварено у вашој инфраструктури, онда је са тачке гледишта Цлоуднативе приступа и са становишта инфраструктуре као кода, лакше него да то поправите, одете на сервер, откријете шта је покварено и поправите то да избришете сервер и поново га креирате. И даћу да се све ово обнови.
О свим овим питањима детаљније се говори на . Пратећи линк можете се упознати са програмом и условима. Згодна ствар је што Кубернетес можете савладати тако што ћете учити од куће или радити 1-2 сата дневно.
Извор: ввв.хабр.цом