Для кожнага рэсурсу Kubernetes маецца магчымасць наладжваць два тыпу патрабаванняў - Requests і Limits. Першае апісвае мінімальныя патрабаванні да наяўнасці вольных рэсурсаў вузла, неабходных для запуску кантэйнера ці пода, другое цвёрда абмяжоўвае рэсурсы, даступныя кантэйнеру.
Калі Kubernetes плануе pod, вельмі важна, каб у кантэйнераў было дастаткова рэсурсаў для нармальнай працы. Калі вы плануеце разгарнуць вялікае прыкладанне на вузле з абмежаванымі рэсурсамі, цалкам магчыма, што яно не будзе працаваць па прычыне таго, што ў вузла заканчваецца памяць ці яму не хапае магутнасці працэсара. У гэтым артыкуле мы разгледзім, як можна вырашыць праблемы недахопу кампутарных магутнасцяў з дапамогай запытаў на рэсурсы і абмежаванні.
Запыты Requests і абмежаванні Limits - гэта механізмы, якія Kubernetes выкарыстоўвае для кіравання такімі рэсурсамі, як, напрыклад, працэсар і памяць. Requests - гэта тое, у выніку чаго кантэйнер гарантавана атрымлівае запытаны рэсурс. Калі кантэйнер запытвае рэсурс, то Kubernetes заплануе яго толькі на тым вузле, які здольны яго падаць. Абмежаванні Limits кантралююць, што рэсурсы, запытаныя кантэйнерам, ніколі не перавысяць вызначанага значэння.
Кантэйнер можа нарошчваць вылічальныя магутнасці толькі да вызначанай мяжы, пасля чаго будзе абмежаваны. Давайце паглядзім, як гэта працуе. Такім чынам, існуе два тыпу рэсурсаў - працэсар і памяць. Планавальнік Kubernetes выкарыстоўвае дадзеныя аб гэтых рэсурсах, каб высветліць, дзе запускаць вашыя поды. Тыповая спецыфікацыя рэсурсаў для пода выглядае так.
Кожны кантэйнер у pod можа ўсталёўваць свае ўласныя запыты і абмежаванні, усё гэта адытыўна. Рэсурсы працэсара вызначаюцца ў мілікорах. Калі ваш кантэйнер для запуску мае патрэбу ў двух поўных ядрах, вы ўстанаўліваеце значэнне 2000m. Калі ж кантэйнеру патрэбна магутнасць толькі 1/4 ядра, значэнне складзе 250m. Майце на ўвазе, што калі вы прызначыце значэнне рэсурсаў працэсара больш, чым колькасць ядраў самага вялікага вузла, то запуск вашага пода наогул не будзе запланаваны. Аналагічная сітуацыя адбудзецца, калі ў вас ёсць пад, які мае патрэбу ў чатырох ядрах, а кластар Kubernetes складаецца ўсяго толькі з двух асноўных віртуальных машын.
Калі толькі ваша прыкладанне не распрацавана спецыяльна для выкарыстання пераваг некалькіх ядраў (пры гэтым на розум прыходзяць такія праграмы, як складаныя навуковыя вылічэнні і аперацыі з базамі дадзеных), то найлепшай практыкай з'яўляецца ўстаноўка CPU Requests на 1 або ніжэй з наступным запускам большай колькасці рэплік для маштабаванасці. Такое рашэнне надасць сістэме большую гнуткасць і надзейнасць.
Калі справа даходзіць да абмежаванняў працэсара, усё становіцца цікавейшым, паколькі ён лічыцца сцісканым рэсурсам. Калі ваша прыкладанне пачынае набліжацца да ліміту працэсарнай магутнасці, Kubernetes пачне прытармажваць ваш кантэйнер, выкарыстоўваючы CPU Throttling – зніжэнне частаты працэсара. Гэта азначае, што працэсар будзе штучна абмежаваны, падаючы з дадаткам патэнцыйна горшую прадукцыйнасць, аднак працэс не будзе спынены або вынесены.
Рэсурсы памяці вызначаюцца ў байтах. Звычайна значэнне ў наладах вымяраецца ў мебібайтах Mib, але вы можаце задаць любое значэнне, ад байтаў да петабайт. Тут мае месца тая ж сітуацыя, што і з CPU - калі вы размясціце запыт на колькасць памяці, якое перавышае аб'ём памяці на вашых вузлах, выкананне гэтага pod не будзе запланавана. Але ў адрозненне ад рэсурсаў працэсара, памяць не сціскаецца, бо няма ніякага спосабу абмежаваць яе выкарыстанне. Таму выкананне кантэйнера будзе спынена, як толькі ён выйдзе за межы выдзеленай яму памяці.
Важна памятаць, што вы не можаце наладзіць запыты, якія перавышаюць памер рэсурсаў, якія могуць даць вашыя вузлы. Характарыстыкі агульных рэсурсаў для віртуальных машын GKE можна знайсці па спасылках, размешчаных пад дадзеным відэа.
У ідэальным свеце налад кантэйнера па змаўчанні будзе цалкам дастаткова, каб працоўныя працэсы праходзілі гладка. Але рэальны свет не такі, людзі лёгка могуць забыцца наладзіць выкарыстанне рэсурсаў ці ж хакеры ўсталююць запыты і абмежаванні, якія перавышаюць рэальныя магчымасці інфраструктуры. Каб прадухіліць развіццё падобных сцэнараў, можна наладзіць квоты рэсурсаў ResourceQuota і дыяпазоны абмежаванняў LimitRange.
Пасля стварэння прасторы імёнаў іх можна заблакаваць з дапамогай квот. Напрыклад, калі ў вас маюцца прасторы імёнаў prod і dev, выкарыстоўваецца шаблон, пры якім квоты на прадакшн адсутнічаюць наогул, а квоты на дэвэлапмент з'яўляюцца вельмі строгімі. Гэта дазваляе prod у выпадку рэзкага скачка трафіку забраць сабе ўвесь наяўны рэсурс, цалкам заблакаваўшы dev.
Квота рэсурсаў можа выглядаць такім чынам. У гэтым прыкладзе маецца 4 часткі - гэта 4 ніжніх радка кода.
Давайце разгледзім кожны з іх. Requests.cpu - гэта максімальная колькасць камбінаваных запытаў працэсарнай магутнасці, якія могуць паступаць ад усіх кантэйнераў прасторы імёнаў. У дадзеным прыкладзе ў вас могуць быць 50 кантэйнераў з запытамі па 10m, пяць кантэйнераў з запытамі па 100m або проста адзін кантэйнер з запытам 500m. Да таго часу, пакуль агульная колькасць requests.cpu дадзенай прасторы імёнаў будзе менш за 500m, усё будзе ў парадку.
Запытаная памяць requests.memory - гэта максімальная велічыня камбінаваных запытаў памяці, якую могуць мець усе кантэйнеры ў прасторы імёнаў. Як і ў папярэднім выпадку, вы можа мець 50 кантэйнераў па 2 mib, пяць кантэйнераў па 20 Mib або адзіны кантэйнер з 100 Mib да таго часу, пакуль агульная колькасць запытанай памяці ў прасторы імёнаў будзе менш, чым 100 мебібайт.
Limits.cpu - гэта максімальнае камбінаванае значэнне працэсарнай магутнасці, якую могуць выкарыстоўваць усе кантэйнеры прасторы імёнаў. Можна лічыць, што гэта мяжа запытаў працэсарнай магутнасці.
Нарэшце, limits.memory - максімальны аб'ём агульнай памяці, які могуць выкарыстоўваць усе кантэйнеры ў прасторы імёнаў. Гэтае абмежаванне сумарных запытаў памяці.
Такім чынам, па змаўчанні кантэйнеры ў кластары Kubernetes працуюць з неабмежаванымі вылічальнымі рэсурсамі. З дапамогай квотаў рэсурсаў адміністратары кластара могуць абмежаваць спажыванне рэсурсаў і іх стварэнне на аснове прасторы імёнаў. У прасторы імёнаў модуль pod ці кантэйнер можа спажываць гэтулькі магутнасці CPU і памяці, колькі вызначана квотай рэсурсаў прастор імёнаў. Аднак існуе асцярога, што адзін пад або кантэйнер можа манапалізаваць усе наяўныя рэсурсы. Для прадухілення такой сітуацыі выкарыстоўваецца гранічны дыяпазон limit Range - палітыка абмежавання размеркавання рэсурсаў (для падоў або кантэйнераў) у прасторы імёнаў.
Лімітавы дыяпазон дае абмежаванні, якія могуць:
- забяспечваць мінімальнае і максімальнае выкарыстанне вылічальных рэсурсаў для кожнага модуля ці кантэйнера ў прасторы імёнаў;
- прымусова выконваць мінімальны і максімальны запыт сховішчы Starage Request для кожнага PersistentVolumeClaim у прасторы імёнаў;
- прымусова ўсталёўваць суадносіны паміж запытам Request і абмежаваннем Limit для рэсурса ў прасторы імёнаў;
- усталёўваць Requests/Limits па змаўчанні для вылічальных рэсурсаў у прасторы імёнаў і аўтаматычна ўводзіць іх у кантэйнеры падчас выканання.
Такім чынам, вы можаце стварыць гранічны дыяпазон у сваёй прасторы імёнаў. У адрозненне ад квоты, якая распаўсюджваецца на ўсю прастору імёнаў, Limit Range выкарыстоўваецца для асобных кантэйнераў. Гэта можа прадухіліць стварэнне карыстальнікамі зусім маленечкіх ці наадварот, гіганцкіх кантэйнераў ўнутры прасторы імёнаў. Лімітавы дыяпазон Limit Range можа выглядаць так.
Як і ў папярэднім выпадку, тут можна вылучыць 4 раздзелы. Давайце разгледзім кожны.
У падзеле default усталёўваюцца абмежаванні па змаўчанні для кантэйнера ў подзе. Калі вы задасце гэтыя значэнні ў лімітавым дыяпазоне, то любыя кантэйнеры, для якіх гэтыя значэнні не былі відавочна ўсталяваныя, будуць кіравацца значэннямі па змаўчанні.
У раздзеле запыт па змаўчанні defaultRequest настроены запыты па змаўчанні для кантэйнера ў подзе. Ізноў жа, калі вы ўсталюеце гэтыя значэнні ў лімітавым дыяпазоне, то любыя кантэйнеры, для якіх гэтыя параметры відавочна не зададзены, будуць выкарыстоўваць па змаўчанні гэтыя значэнні.
У раздзеле max указаны максімальныя абмежаванні, якія могуць быць устаноўлены для кантэйнера ў подзе. Значэнні ў раздзеле default і абмежаванні для кантэйнера не могуць быць устаноўлены вышэй гэтай мяжы. Важна адзначыць, што калі ўсталявана значэнне max, а частка default адсутнічае, тое максімальнае значэнне становіцца значэннем па змаўчанні.
У раздзеле min указаны мінімальныя запыты, якія могуць быць устаноўлены для кантэйнера ў подзе. Пры гэтым значэння ў раздзеле default і запыты для кантэйнера не могуць быць устаноўлены ніжэй за гэтую мяжу.
Зноў жа, важна адзначыць, што калі гэтае значэнне ўсталявана, значэнне default - не, то мінімальнае значэнне становіцца запытам па змаўчанні.
У выніку гэтыя запыты рэсурсаў выкарыстоўваюцца планавальнікам Kubernetes для выканання вашых працоўных нагрузак. Для таго, каб вы маглі правільна наладзіць свае кантэйнеры, вельмі важна зразумець, як гэта працуе. Выкажам здагадку, вы хочаце запусціць некалькі модуляў у сваім кластары. Мяркуючы, што спецыфікацыі пода сапраўдныя, у раскладзе Kubernetes будзе выкарыстоўвацца цыклічнае балансаванне для выбару вузла для выканання працоўнай нагрузкі.
Kubernetes праверыць, ці дастаткова рэсурсаў у вузла Node 1 для выканання запытаў кантэйнераў пода, і калі гэта не так, то пяройдзе да наступнага вузла. Калі ж ніводны з вузлоў у сістэме не здольны задаволіць запыты, поды пяройдуць у стан чакання Pending state. З дапамогай такіх функцый Google Kubernetes engine, як аўтамаштабаванне вузлоў, GKE можа аўтаматычна вызначыць стан чакання і стварыць яшчэ некалькі дадатковых вузлоў.
Калі ж пасля ўзнікне залішняя ёмістасць вузлоў, функцыя аўтамаштабавання паменшыць іх колькасць, каб зэканоміць вам грошы. Вось чаму Kubernetes плануе поды на аснове запытаў. Аднак ліміт можа вышэй, чым запыты, і ў некаторых выпадках вузел можа фактычна вычарпаць рэсурсы. Мы называем такі стан overcommitment state.
Як я ўжо сказаў, калі гаворка ідзе аб працэсары, Kubernetes пачне абмяжоўваць поды. Кожны pod атрымае столькі, колькі ён прасіў, але калі пры гэтым ён не дасягне ліміту, то пачне прымяняцца тротлінг.
Што да рэсурсаў памяці, то тут Kubernetes змушаны прымаць рашэнні аб тым, якія поды выдаляць, а якія захоўваць, пакуль вы не вызваліце сістэмныя рэсурсы, інакш уся сістэма абрынецца.
Давайце ўявім сабе сцэнар, у якім у вас маецца машына, вычарпалая ліміт памяці як пры гэтым паступіць Kubernetes?
Kubernetes будзе шукаць поды, якія выкарыстоўваюць больш рэсурсаў, чым запытвалі. Так што калі ў вашых кантэйнераў увогуле няма запытаў Requests, гэта азначае, што па змаўчанні яны выкарыстоўваюць больш, чым прасілі, проста таму што яны не прасілі наогул нічога! Такія кантэйнеры становяцца галоўнымі кандыдатамі на адключэнне. Наступнымі кандыдатамі з'яўляюцца кантэйнеры, якія задаволілі ўсе свае запыты, але ўсё яшчэ знаходзяцца ніжэй за максімальны ліміт.
Так што калі Kubernetes знойдзе некалькі подаў, якія перавысілі параметры сваіх запытаў, тое адсартуе іх па прыярытэце, а затым выдаліць самыя нізкапрыярытэтныя модулі. Калі ўсе модулі маюць аднолькавы прыярытэт, то Kubernetes спыніць працу тых подаў, якія перавысілі свае запыты больш, чым астатнія поды.
У вельмі рэдкіх выпадках Kubernetes можа спыніць працу подаў, якія ўсё яшчэ знаходзяцца ў рамках сваіх запытаў. Гэта можа адбыцца, калі такія крытычныя кампаненты сістэмы, як агент Kubelet ці Docker, пачнуць спажываць больш рэсурсаў, чым было для іх зарэзервавана.
Такім чынам, на пачатковых этапах працы невялікіх кампаній кластар Kubernetes можа выдатна працаваць без усталёўкі запытаў рэсурсаў і абмежаванняў, але па меры таго як вашы каманды і праекты пачынаюць расці ў памерах, вы рызыкуеце сутыкнуцца з праблемамі ў гэтай вобласці. Даданне запытаў і абмежаванняў у вашыя модулі і прасторы імёнаў патрабуе зусім крыху дадатковых намаганняў і можа пазбавіць ад многіх клопатаў.
Крыху рэкламы 🙂
Дзякуй, што застаяцеся з намі. Вам падабаюцца нашыя артыкулы? Жадаеце бачыць больш цікавых матэрыялаў? Падтрымайце нас, аформіўшы замову ці парэкамендаваўшы знаёмым, , унікальны аналаг entry-level сервераў, які быў прыдуманы намі для Вас: (даступныя варыянты з RAID1 і RAID10, да 24 ядраў і да 40GB DDR4).
Dell R730xd у 2 разы танней у дата-цэнтры Equinix Tier IV у Амстэрдаме? Толькі ў нас у Нідэрландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – ад $99! Чытайце аб тым
Крыніца: habr.com