Pradedant nuo „Kubernetes“ dažnai pamirštama, kaip nustatyti konteinerio išteklius. Šiuo metu pakanka įsitikinti, kad „Docker“ vaizdas veikia ir gali būti įdiegtas „Kubernetes“ klasteryje.
Tačiau vėliau programa turi būti įdiegta gamybos klasteryje kartu su kitomis programomis. Norėdami tai padaryti, turite paskirstyti konteinerio išteklius ir įsitikinti, kad jų yra pakankamai, kad programa būtų sukurta ir paleista, o kitoms veikiančioms programoms nekils problemų.
Komanda išvertė straipsnį apie konteinerio išteklius (CPU ir MEM), užklausas ir išteklių apribojimus. Sužinosite apie šių nustatymų naudą ir kas atsitiks, jei jų nenustatysite.
Skaičiavimo ištekliai
Turime dviejų tipų išteklius su šiais vienetais:
- Centrinis procesorius (CPU) - branduoliai;
- Atmintis (MEM) – baitai.
Kiekvienam konteineriui nurodomi ištekliai. Šiame Pod YAML faile pamatysite išteklių skyrių, kuriame yra prašomi ir ribojami ištekliai:
- Requested Pod Resources = visų konteinerių prašomų išteklių suma;
- Pod Resource Limit = visų Pod išteklių limitų suma.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
— name: main-container
image: my-backend
tag: v1
ports:
— containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiReikalaujamų ir ribotų išteklių pavyzdys
Laukas resources.requested iš specifikacijos Pod yra vienas iš elementų, kuris naudojamas norint rasti norimą mazgą. Jau galite planuoti Pod diegimą. Kaip rasti tinkamą mazgą?
„Kubernetes“ susideda iš kelių komponentų, įskaitant pagrindinį mazgą arba pagrindinį mazgą („Kubernetes Control Plane“). Pagrindiniame mazge yra keli procesai: kube-apiserver, kube-controller-manager ir kube-scheduler.
Kube planuoklio procesas yra atsakingas už naujai sukurtų grupių peržiūrą ir galimų darbuotojų mazgų, atitinkančių visas grupės užklausas, paiešką, įskaitant prašomų išteklių skaičių. Kube-scheduler rastų mazgų sąrašas yra reitinguojamas. Grupė suplanuota aukščiausius balus surinkusiame mazge.
Kur bus dedamas violetinis ankštis?
Paveikslėlyje matote, kad kube planuotojas turėtų suplanuoti naują purpurinį Pod. „Kubernetes“ klasteryje yra du mazgai: A ir B. Kaip matote, „kube-scheduler“ negali planuoti „Pod“ mazge A – turimi (neprašomi) ištekliai neatitinka purpurinio „Pod“ užklausų. Taigi, 1 GB atminties, kurios prašo violetinė Pod, netilps mazge A, nes turima atmintis yra 0,5 GB. Tačiau mazgas B turi pakankamai išteklių. Dėl to kube planuotojas nusprendžia, kad purpurinio Pod paskirties vieta yra mazgas B.
Dabar mes žinome, kaip prašomi ištekliai paveikia mazgo pasirinkimą paleisti Pod. Bet koks yra ribinių išteklių poveikis?
Išteklių limitas yra riba, kurios CPU/MEM negali peržengti. Tačiau procesoriaus ištekliai yra lankstūs, todėl talpyklos, pasiekusios CPU ribas, nesukels Pod išėjimo. Vietoj to prasidės procesoriaus ribojimas. Pasiekus MEM naudojimo limitą, konteineris bus sustabdytas dėl OOM-Killer ir paleistas iš naujo, jei tai leidžia RestartPolicy nuostata.
Detaliai prašomi ir maksimaliai ištekliai
Išteklių ryšys tarp „Docker“ ir „Kubernetes“.
Geriausias būdas paaiškinti, kaip veikia išteklių užklausos ir išteklių apribojimai, yra pristatyti „Kubernetes“ ir „Docker“ ryšį. Viršuje esančiame paveikslėlyje galite pamatyti, kaip yra susiję „Kubernetes“ laukai ir „Docker“ paleisties vėliavėlės.
Atmintis: prašymas ir apribojimas
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Kaip minėta aukščiau, atmintis matuojama baitais. Remiantis , galime nurodyti atmintį kaip skaičių. Paprastai tai yra sveikasis skaičius, pavyzdžiui, 2678, tai yra, 2678 baitai. Taip pat galite naudoti priesagas G и Gi, svarbiausia atsiminti, kad jie nėra lygiaverčiai. Pirmasis yra dešimtainis, o antrasis yra dvejetainis. Kaip pavyzdyje, paminėtame k8s dokumentacijoje: 128974848, 129e6, 129M, 123Mi – jie praktiškai lygiaverčiai.
Kubernetes parinktis limits.memory atitinka vėliavą --memory iš Docker. Tuo atveju request.memory „Docker“ nėra rodyklės, nes „Docker“ nenaudoja šio lauko. Galite paklausti, ar tai išvis būtina? Taip reikia. Kaip sakiau anksčiau, „Kubernetes“ yra svarbi sritis. Remdamasis iš jo gauta informacija, kube planuoklis nusprendžia, kurį mazgą planuoti Pod.
Kas atsitiks, jei užklausai neužtenka atminties?
Jei konteineris pasiekė prašomos atminties ribas, Pod yra įtrauktas į Pod grupę, kuri sustoja, kai mazge nėra pakankamai atminties.
Kas atsitiks, jei nustatysite per mažą atminties limitą?
Jei konteineris viršija atminties limitą, jis bus nutrauktas dėl OOM-Killed. Ir bus paleistas iš naujo, jei įmanoma, remiantis RestartPolicy, kur yra numatytoji reikšmė Always.
Kas atsitiks, jei nenurodysite prašomos atminties?
Kubernetes paims ribinę vertę ir nustatys ją kaip numatytąją vertę.
Kas gali nutikti, jei nenurodysite atminties limito?
Konteineris neturi jokių apribojimų; jis gali naudoti tiek atminties, kiek nori. Jei jis pradės naudoti visą turimą mazgo atmintį, OOM jį nužudys. Tada konteineris bus paleistas iš naujo, jei įmanoma, remiantis RestartPolicy.
Kas nutiks, jei nenurodysite atminties apribojimų?
Tai yra blogiausias scenarijus: planuotojas nežino, kiek išteklių reikia konteineriui, ir tai gali sukelti rimtų problemų mazge. Tokiu atveju būtų puiku, jei vardų erdvėje būtų numatyti numatytieji apribojimai (nustatyta LimitRange). Numatytų apribojimų nėra – Pod neturi jokių apribojimų, gali naudoti tiek atminties, kiek nori.
Jei prašomos atminties yra daugiau, nei mazgas gali pasiūlyti, Pod nebus suplanuotas. Svarbu tai atsiminti Requests.memory - ne mažiausia vertė. Tai yra atminties kiekio, kurio pakanka, kad konteineris veiktų nuolat, aprašymas.
Paprastai rekomenduojama nustatyti tą pačią reikšmę request.memory и limit.memory. Taip užtikrinama, kad „Kubernetes“ nesuplanuos „Pod“ mazge, kuriame yra pakankamai atminties „Pod“ paleisti, bet nepakanka jam paleisti. Atminkite: Kubernetes Pod planuojant atsižvelgiama tik į tai requests.memoryIr limits.memory neatsižvelgia.
CPU: prašymas ir apribojimas
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Su CPU viskas yra šiek tiek sudėtingiau. Grįžtant prie Kubernetes ir Docker santykių vaizdo, tai matosi request.cpu atitinka --cpu-shares, kadangi limit.cpu atitinka vėliavą cpus programoje Docker.
CPU, kurio reikalauja Kubernetes, padauginamas iš 1024, procesoriaus ciklų proporcijos. Jei norite paprašyti 1 viso branduolio, turite pridėti cpu: 1kaip parodyta aukščiau.
Viso branduolio užklausa (proporcija = 1024) nereiškia, kad jūsų sudėtinis rodinys jį gaus. Jei jūsų pagrindinis kompiuteris turi tik vieną branduolį ir naudojate daugiau nei vieną sudėtinį rodinį, visi konteineriai turi dalytis turimu CPU. Kaip tai atsitinka? Pažiūrėkime į paveikslėlį.
CPU užklausa – vieno branduolio sistema
Įsivaizduokime, kad turite vieno branduolio pagrindinio kompiuterio sistemą, kurioje veikia konteineriai. Mama (Kubernetes) iškepė pyragą (CPU) ir nori jį padalinti vaikams (indeliams). Trys vaikai nori viso pyrago (proporcija = 1024), kitas vaikas nori pusės pyrago (512). Mama nori būti teisinga ir atlieka paprastą skaičiavimą.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Remiantis skaičiavimais, trys vaikai gaus 28% pagrindo, o ne visą pagrindą. Ketvirtas vaikas gaus 14% viso branduolio, o ne pusę. Tačiau viskas bus kitaip, jei turėsite kelių branduolių sistemą.
CPU užklausa – kelių branduolių (4) sistema
Viršuje esančiame paveikslėlyje matote, kad trys vaikai nori viso pyrago, o vienas - pusės. Kadangi mama iškepė keturis pyragėlius, kiekvienas jos vaikas gaus tiek, kiek norės. Kelių branduolių sistemoje procesoriaus ištekliai paskirstomi visuose turimuose procesoriaus branduoliuose. Jei konteineryje yra mažiau nei vienas pilnas procesoriaus branduolys, jis vis tiek gali jį naudoti 100%.
Aukščiau pateikti skaičiavimai yra supaprastinti, kad suprastumėte, kaip CPU paskirstomas tarp konteinerių. Žinoma, be pačių konteinerių, yra ir kitų procesų, kurie taip pat naudoja procesoriaus išteklius. Kai procesai viename konteineryje yra neaktyvūs, kiti gali naudoti jo išteklius. CPU: "200m" atitinka CPU: 0,2, o tai reiškia maždaug 20 % vienos šerdies.
Dabar pakalbėkime apie limit.cpu. CPU, kurį Kubernetes riboja, padauginamas iš 100. Rezultatas yra laikas, kurį konteineris gali naudoti kas 100 µs (cpu-period).
limit.cpu atitinka Docker vėliavą --cpus. Tai naujas seno derinys --cpu-period и --cpu-quota. Jį nustatydami nurodome, kiek galimų procesoriaus resursų konteineris gali maksimaliai sunaudoti prieš pradedant ribojimą:
- CPU - derinys
cpu-periodиcpu-quota. cpus = 1.5lygiavertis nustatymuicpu-period = 100000иcpu-quota = 150000; - CPU laikotarpis - laikotarpis , numatytoji 100 mikrosekundžių;
- cpu kvota - viduje esančių mikrosekundžių skaičius
cpu-period, kurį riboja konteineris.
Kas atsitiks, jei įdiegsite nepakankamai prašomo procesoriaus?
Jei konteineriui reikia daugiau, nei jis įdiegtas, jis pavogs procesorių iš kitų procesų.
Kas atsitiks, jei nustatysite per žemą procesoriaus limitą?
Kadangi procesoriaus ištekliai yra reguliuojami, bus įjungtas droselis.
Kas atsitiks, jei nenurodysite CPU užklausos?
Kaip ir atmintyje, užklausos reikšmė yra lygi ribai.
Kas nutiks, jei nenurodysite procesoriaus limito?
Konteineris naudos tiek procesoriaus, kiek jam reikia. Jei vardų srityje apibrėžta numatytoji procesoriaus politika (LimitRange), ši riba taip pat naudojama sudėtiniam rodiniui.
Kas nutiks, jei nenurodysite nei užklausos, nei procesoriaus limito?
Kaip ir atmintis, tai yra blogiausias scenarijus. Planuotojas nežino, kiek išteklių reikia jūsų konteineriui, ir tai gali sukelti rimtų problemų mazge. Norėdami to išvengti, turite nustatyti numatytuosius vardų erdvių apribojimus (LimitRange).
Atminkite: jei paprašysite daugiau procesoriaus, nei gali pateikti mazgai, Pod nebus suplanuotas. Requests.cpu - ne mažiausia vertė, o pakankama Pod įjungti ir veikti be gedimų. Jei programa neatlieka sudėtingų skaičiavimų, geriausias pasirinkimas yra įdiegti request.cpu <= 1 ir paleiskite tiek kopijų, kiek reikia.
Idealus prašomų išteklių kiekis arba išteklių limitas
Sužinojome apie skaičiavimo išteklių ribotumą. Dabar atėjo laikas atsakyti į klausimą: „Kiek išteklių reikia mano „Pod“, kad programa būtų paleista be jokių problemų? Kokia yra ideali suma?
Deja, nėra aiškių atsakymų į šiuos klausimus. Jei nežinote, kaip veikia jūsų programa arba kiek jai reikia procesoriaus ar atminties, geriausias pasirinkimas yra suteikti programai daug atminties ir procesoriaus, o tada atlikti našumo testus.
Be našumo testų, savaitę stebėkite programos elgseną. Jei diagramos rodo, kad jūsų programa sunaudoja mažiau išteklių, nei prašėte, galite sumažinti reikalaujamą procesoriaus arba atminties kiekį.
Kaip pavyzdį žiūrėkite tai . Jis rodo skirtumą tarp prašomų išteklių arba išteklių limito ir dabartinio išteklių naudojimo.
išvada
Išteklių prašymas ir ribojimas padeda išlaikyti „Kubernetes“ klasterio sveikatą. Tinkama limito konfigūracija sumažina išlaidas, o programos veikia visą laiką.
Trumpai tariant, reikia atsiminti keletą dalykų:
- Prašomi ištekliai yra konfigūracija, į kurią atsižvelgiama paleidžiant (kai Kubernetes planuoja priglobti programą). Priešingai, riboti išteklius svarbu vykdymo metu – kai programa jau veikia mazge.
- Palyginti su atmintimi, CPU yra reguliuojamas išteklius. Jei nepakanka procesoriaus, jūsų Pod neišsijungs ir įsijungs droselio mechanizmas.
- Reikalingi ištekliai ir išteklių limitas nėra minimalios ir didžiausios vertės! Apibrėždami prašomus išteklius, užtikrinate, kad programa veiks be problemų.
- Gera praktika yra nustatyti atminties užklausą, lygią atminties limitui.
- Gerai, paprašė įdiegti
CPU <=1, jei programa neatlieka sudėtingų skaičiavimų. - Jei prašote daugiau išteklių, nei yra mazge, Pod niekada nebus suplanuotas tam mazgui.
- Norėdami nustatyti teisingą prašomų išteklių kiekį / išteklių limitus, naudokite apkrovos testavimą ir stebėjimą.
Tikiuosi, kad šis straipsnis padės suprasti pagrindinę išteklių ribojimo sąvoką. Ir šias žinias galėsite pritaikyti savo darbe.
Sėkmės!
Ką dar skaityti:
- .
- .
- .
Šaltinis: www.habr.com