27. априла на конференцији , у оквиру секције „ДевОпс“, дат је извештај „Аутоскалирање и управљање ресурсима у Кубернетесу“. Говори о томе како можете да користите К8с да бисте обезбедили високу доступност својих апликација и обезбедили врхунске перформансе.
По традицији, са задовољством представљамо (44 минута, много информативније од чланка) и главни резиме у текстуалном облику. Иди!
Анализирајмо тему извештаја реч по реч и кренимо од краја.
Кубернетес
Рецимо да имамо Доцкер контејнере на нашем хосту. За шта? Да би се обезбедила поновљивост и изолација, што заузврат омогућава једноставну и добру примену, ЦИ/ЦД. Имамо много таквих возила са контејнерима.
Шта Кубернетес пружа у овом случају?
- Престајемо да размишљамо о овим машинама и почињемо да радимо са "облаком" кластер контејнера или махуне (групе контејнера).
- Штавише, чак и не размишљамо о појединачним махунама, већ управљамо вишеовеће групе. Такве примитивима високог нивоа дозволите нам да кажемо да постоји шаблон за покретање одређеног радног оптерећења, а овде је потребан број инстанци за његово покретање. Ако накнадно променимо шаблон, све инстанце ће се променити.
- Са декларативни АПИ Уместо извршавања низа специфичних команди, описујемо „структуру света“ (у ИАМЛ), коју креира Кубернетес. И опет: када се опис промени, промениће се и његов стварни приказ.
Управљање ресурсима
Процесор
Хајде да покренемо нгинк, пхп-фпм и мискл на серверу. Ове услуге ће заправо имати још више покренутих процеса, од којих сваки захтева рачунарске ресурсе:
(бројеви на слајду су „папагаји“, апстрактна потреба сваког процеса за рачунарском снагом)
Да бисмо олакшали рад са овим, логично је комбиновати процесе у групе (на пример, све нгинк процесе у једну групу „нгинк“). Једноставан и очигледан начин да то урадите је да сваку групу ставите у контејнер:
Да бисте наставили, морате запамтити шта је контејнер (у Линук-у). Њихово појављивање је омогућено захваљујући три кључне карактеристике у кернелу, имплементиране доста давно: , и . А даљи развој су олакшале друге технологије (укључујући погодне „љуске“ као што је Доцкер):
У контексту извештаја, занима нас само цгроупс, јер су контролне групе део функционалности контејнера (Доцкер итд.) који имплементира управљање ресурсима. Процеси комбиновани у групе, како смо желели, су контролне групе.
Вратимо се захтевима ЦПУ-а за ове процесе, а сада за групе процеса:
(Понављам да су сви бројеви апстрактни израз потребе за ресурсима)
Истовремено, сам ЦПУ има одређени ограничени ресурс (у примеру ово је 1000), што свима може недостајати (збир потреба свих група је 150+850+460=1460). Шта ће се десити у овом случају?
Кернел почиње да дистрибуира ресурсе и то чини „поштено“, дајући исту количину ресурса свакој групи. Али у првом случају их има више него што је потребно (333>150), па вишак (333-150=183) остаје у резерви, који се такође подједнако распоређује између два друга контејнера:
Као резултат: први контејнер је имао довољно ресурса, други - није имао довољно ресурса, трећи - није имао довољно ресурса. Ово је резултат акција "поштени" планер у Линуку - . Његов рад се може подесити помоћу задатка утези сваки од контејнера. На пример, овако:
Погледајмо случај недостатка ресурса у другом контејнеру (пхп-фпм). Сви ресурси контејнера су подједнако распоређени између процеса. Као резултат тога, главни процес функционише добро, али сви радници успоравају, примајући мање од половине онога што им је потребно:
Овако ради ЦФС планер. Даље ћемо звати тежине које додељујемо контејнерима захтева. Зашто је то тако - погледајте даље.
Погледајмо целу ситуацију са друге стране. Као што знате, сви путеви воде у Рим, а у случају рачунара, до ЦПУ-а. Један ЦПУ, много задатака - потребан вам је семафор. Најједноставнији начин управљања ресурсима је „семафор“: једном процесу су дали фиксно време приступа ЦПУ-у, затим следећем, итд.
Овај приступ се назива чврсте квоте (тешко ограничење). Сетимо се једноставно као granice. Међутим, ако распоредите ограничења на све контејнере, појављује се проблем: мискл се возио путем и у неком тренутку је његова потреба за ЦПУ-ом престала, али сви остали процеси су приморани да чекају док ЦПУ неактиван.
Вратимо се Линук кернелу и његовој интеракцији са ЦПУ-ом - укупна слика је следећа:
цгроуп има два подешавања - у суштини ово су два једноставна „окрета“ која вам омогућавају да одредите:
- тежина за контејнер (захтеви) је акција;
- проценат укупног ЦПУ времена за рад на контејнерским задацима (ограничења) је удео.
Како измерити ЦПУ?
Постоје различити начини:
- Шта је папагаји, нико не зна - сваки пут треба преговарати.
- Интерес јасније, али релативно: 50% сервера са 4 језгра и са 20 језгара су потпуно различите ствари.
- Можете користити оне које су већ поменуте утези, које Линук познаје, али су такође релативне.
- Најадекватнија опција је мерење рачунарских ресурса у секунди. Оне. у секундама процесорског времена у односу на секунде реалног времена: 1 секунда процесорског времена је дата за 1 реалну секунду - ово је једно цело језгро ЦПУ-а.
Да би још лакше говорили, почели су директно да мере језгра, што значи исто ЦПУ време у односу на стварно. Пошто Линук разуме тежине, али не толико ЦПУ време/језгра, био је потребан механизам за превођење са једног на други.
Хајде да размотримо једноставан пример са сервером са 3 ЦПУ језгра, где ће три махуне добити тежине (500, 1000 и 1500) које се лако конвертују у одговарајуће делове језгара који су им додељени (0,5, 1 и 1,5).
Ако узмете други сервер, где ће бити дупло више језгара (6), и тамо поставите исте подове, дистрибуција језгара се може лако израчунати једноставним множењем са 2 (1, 2 и 3, респективно). Али важан моменат се дешава када се на овом серверу појави четврти под, чија ће тежина, ради погодности, бити 3000. Одузима део ЦПУ ресурса (половина језгара), а за преостале подове се прерачунавају (преполовљавају):
Кубернетес и ЦПУ ресурси
У Кубернетесу се ресурси процесора обично мере у миллиадрак, тј. 0,001 језгра се узима као основна тежина. (Иста ствар у терминологији Линук/цгроупс се зове удео ЦПУ-а, мада, тачније, 1000 милицорес = 1024 ЦПУ дељења.) К8с осигурава да не поставља више подова на сервер него што има ЦПУ ресурса за збир тежина свих подова.
Како се ово дешава? Када додате сервер у Кубернетес кластер, пријављује се колико ЦПУ језгара има на располагању. А када креирате нови под, Кубернетес планер зна колико ће језгара овом модулу требати. Дакле, под ће бити додељен серверу где има довољно језгара.
Шта ће се десити ако не захтев је наведен (тј. под нема дефинисан број потребних језгара)? Хајде да схватимо како Кубернетес уопштено броји ресурсе.
За под можете навести и захтеве (ЦФС планер) и ограничења (сећате се семафора?):
- Ако су специфицирани једнаки, под је додељена КоС класа гарантовано. Овај број језгара који су му увек доступни је загарантован.
- Ако је захтев мањи од ограничења - КоС класа бурстабле. Оне. Очекујемо да под, на пример, увек користи 1 језгро, али ова вредност није ограничење за њега: Понекад под може да користи више (када сервер има слободне ресурсе за ово).
- Постоји и КоС класа најбољи труд — укључује управо оне махуне за које захтев није одређен. Средства им се дају последњи.
меморија
Са меморијом, ситуација је слична, али мало другачија - на крају крајева, природа ових ресурса је другачија. Генерално, аналогија је следећа:
Хајде да видимо како се захтеви имплементирају у меморију. Пустите махуне да живе на серверу, мењајући потрошњу меморије, све док једна од њих не постане толико велика да остане без меморије. У овом случају, појављује се ООМ убица и убија највећи процес:
То нам не одговара увек, па је могуће регулисати који процеси су нам важни и не треба их убијати. Да бисте то урадили, користите параметар оом_сцоре_адј.
Вратимо се КоС класама ЦПУ-а и направимо аналогију са вредностима оом_сцоре_адј које одређују приоритете потрошње меморије за подове:
- Најнижа вредност оом_сцоре_адј за махунарку - -998 - значи да такву махуну треба убити последња, ово гарантовано.
- Највиша - 1000 - је најбољи труд, такве махуне се прво убијају.
- Да бисте израчунали преостале вредности (бурстабле) постоји формула чија се суштина своди на чињеницу да што више ресурса капсула захтева, мања је вероватноћа да ће бити убијена.
Други "окрет" - лимит_ин_битес - за границе. Са њим је све једноставније: једноставно додељујемо максималну количину издате меморије, а овде (за разлику од ЦПУ) нема питања како да је измеримо (меморију).
Укупно
Сваки под у Кубернетесу је дат requests и limits - оба параметра за ЦПУ и меморију:
- на основу захтева ради Кубернетес планер, који дистрибуира подове између сервера;
- на основу свих параметара, одређује се КоС класа под;
- Релативне тежине се израчунавају на основу ЦПУ захтева;
- ЦФС планер је конфигурисан на основу ЦПУ захтева;
- ООМ киллер се конфигурише на основу захтева за меморијом;
- „семафор“ је конфигурисан на основу ограничења ЦПУ-а;
- На основу ограничења меморије, ограничење је конфигурисано за цгроуп.
Генерално, ова слика одговара на сва питања о томе како се главни део управљања ресурсима одвија у Кубернетесу.
Аутоматско скалирање
К8с кластер-аутоскалер
Замислимо да је цео кластер већ заузет и да треба креирати нову капсулу. Док се модул не може појавити, виси у статусу На чекању. Да би се појавио, можемо повезати нови сервер са кластером или... инсталирати цлустер-аутосцалер, који ће то учинити за нас: наручити виртуелну машину од провајдера у облаку (помоћу АПИ захтева) и повезати је са кластером , након чега ће се додати под .
Ово је аутоматско скалирање Кубернетес кластера, што одлично функционише (по нашем искуству). Међутим, као и другде, и овде постоје неке нијансе...
Докле год смо повећавали величину кластера, све је било у реду, али шта се дешава када се кластер почео да се ослобађа? Проблем је у томе што је миграција подова (да би се ослободили хостови) веома технички тешка и скупа у смислу ресурса. Кубернетес користи потпуно другачији приступ.
Размислите о групи од 3 сервера који имају имплементацију. Има 6 подова: сада постоје 2 за сваки сервер. Из неког разлога смо желели да искључимо један од сервера. Да бисмо то урадили, користићемо команду kubectl drain, која:
- ће забранити слање нових подова на овај сервер;
- ће избрисати постојеће подове на серверу.
Пошто је Кубернетес одговоран за одржавање броја подова (6), једноставно ће поново створити на другим чворовима, али не и на оном који је онемогућен, пошто је већ означен као недоступан за хостовање нових подова. Ово је основна механика за Кубернетес.
Међутим, и овде постоји нијанса. У сличној ситуацији, за СтатефулСет (уместо Деплоимент), радње ће бити другачије. Сада већ имамо апликацију са стањем – на пример, три под-а са МонгоДБ-ом, од којих један има неку врсту проблема (подаци су се оштетили или друга грешка која спречава да се под правилно покрене). И поново одлучујемо да онемогућимо један сервер. Шта ће се десити?
МонгоДБ могао умре зато што му је потребан кворум: за кластер од три инсталације, најмање две морају да функционишу. Међутим, ово не дешава се - захваљујући ПодДисруптионБудгет. Овај параметар одређује минимално потребан број радних махуна. Знајући да један од МонгоДБ модула више не ради, и видети да је ПодДисруптионБудгет подешен за МонгоДБ minAvailable: 2, Кубернетес вам неће дозволити да избришете под.
Закључак: да би кретање (и заправо, поновно креирање) подова функционисало исправно када се кластер ослободи, потребно је конфигурисати ПодДисруптионБудгет.
Хоризонтално скалирање
Хајде да размотримо другу ситуацију. Постоји апликација која ради као Деплоимент у Кубернетес-у. Кориснички саобраћај долази до његових подова (на пример, има их три), а ми у њима меримо одређени индикатор (рецимо оптерећење ЦПУ-а). Када се оптерећење повећа, снимамо га на распореду и повећавамо број подова за дистрибуцију захтева.
Данас у Кубернетес-у то не треба да се ради ручно: аутоматско повећање/смањење броја подова је конфигурисано у зависности од вредности измерених индикатора оптерећења.
Главна питања овде су: шта тачно мерити и како тумачити добијене вредности (за доношење одлуке о промени броја махуна). Можете измерити много:
Како то технички урадити - прикупити метрику итд. — Детаљно сам говорио у извештају о . А главни савет за избор оптималних параметара је експеримент!
Ту је (Засићеност коришћења и грешке), чије је значење следеће. На основу чега има смисла скалирати, на пример, пхп-фпм? На основу чињенице да радника понестаје, ово је употреба. А ако су радници готови и нове везе се не примају, ово је већ засићење. Оба ова параметра се морају измерити и у зависности од вредности мора се извршити скалирање.
Уместо закључка
Извештај има наставак: о вертикалном скалирању и како одабрати праве ресурсе. О томе ћу причати у будућим видео снимцима - претплатите се да не бисте пропустили!
Видео снимци и слајдови
Видео са наступа (44 минута):
Презентација извештаја:
ПС
Остали извештаји о Кубернетес-у на нашем блогу:
- «» (Андреј Половов; 8. април 2019. на Саинт ХигхЛоад++);
- «» (Дмитриј Стољаров; 8. новембар 2018. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 28. мај 2018. на РоотЦонф-у);
- «» (Дмитриј Стољаров; 7. новембар 2017. на ХигхЛоад++);
- «» (Дмитриј Стољаров; 6. јун 2017. на РоотЦонф-у).
Извор: ввв.хабр.цом