Për çdo burim Kubernetes ka mundësinë për të konfiguracion dy lloje kërkesash — Requests dhe Limits. E para përshkruan kërkesat minimale për disponueshmërinë e burimeve në nodin e nevojshme për të nisur kontejnerin ose podin, e dyta kufizon në mënyrë strikte burimet e disponueshme për kontejnerin.
Kur Kubernetes planifikon një pod, është shumë e rëndësishme që kontejnerët të kenë mjaft burime për të funksionuar normalisht. Nëse planifikoni të shpalosni një aplikacion të madh në një nod me burime të kufizuara, është shumë e mundur që ai të mos funksionojë për shkak se nodi përfundon memorjen ose nuk ka mjaft kapacitet procesori. Në këtë artikull ne do të shohim se si mund të zgjidhim problemet e mungesës së kapacitetit kompjuterik me ndihmën e kërkesave për burime dhe kufizimeve.
Kërkesat dhe kufizimet janë mekanizma që Kubernetes përdor për të menaxhuar burime si CPU dhe memorie. Kërkesat e bëjnë të mundur që kontejneri të marrë burimin e kërkuar. Nëse një kontejner kërkon një burim, Kubernetes do ta planifikojë atë vetëm në nodin që mund ta ofrojë atë. Kufizimet kontrollojnë që burimet e kërkuara nga kontejneri kurrë të mos tejkalojnë një vlerë të caktuar.
Kontejneri mund të rrisë kapacitetet llogaritëse vetëm deri në një limit të caktuar, pas së cilës do të kufizohet. Le të shohim se si funksionon kjo. Pra, ekzistojnë dy lloje burimesh — CPU dhe memorie. Planifikuesi i Kubernetes përdor të dhënat rreth këtyre burimeve për të përcaktuar se ku të nisim pod-ët tuaj. Një specifikim tipik i burimeve për një pod duket kështu.
Çdo konteiner në pod mund të vendosë kërkesat dhe kufizimet e veta, e gjithë kjo është additive. Burimet e procesorit caktohen në milicore. Nëse konteineri juaj ka nevojë për dy bërthama të plota për të funksionuar, vendosni një vlerë prej 2000m. Nëse konteinerit i duhet vetëm fuqia e 1/4 të bërthamës, vlera do të jetë 250m. Kini parasysh që nëse caktoni një vlerë burimesh procesori më të madhe se numri i bërthamave të nodit më të madh, atëherë mbështjellja juaj nuk do të planifikohet për t'u nisur fare. Një situatë e ngjashme do të ndodhte nëse keni një mbështjellje që ka nevojë për katër bërthama, ndërsa klasteri Kubernetes përbëhet vetëm nga dy makina virtuale kryesore.
Nëse aplikacioni juaj nuk është zhvilluar posaçërisht për të shfrytëzuar përfitimet e shumë bërthamave (këtu e kemi fjalën për programe si llogaritjet komplekse shkencore dhe operacionet me databaza), praktika më e mirë është të vendosni Kërkesat e CPU-së në 1 ose më pak dhe t'i drejtoni më shumë replika për shkallëzim. Ky zgjidhje do t'i japë sistemit më shumë fleksibilitet dhe besueshmëri.
Kur bëhet fjalë për kufizimet e CPU-së, gjithçka bëhet më interesante, pasi ai konsiderohet një burim i comprimuar. Nëse aplikacioni juaj fillon të afrohet me kufirin e kapacitetit të procesorit, Kubernetes do të fillojë të ngadalësojë kontejnerin tuaj duke përdorur CPU Throttling — ulje të frekuencës së procesorit. Kjo do të thotë se procesori do të jetë artifialisht i kufizuar, duke i dhënë aplikacionit një performancë potencialisht më të keqe, megjithatë procesi nuk do të ndërpritet apo transferohet jashtë.
Burimet e kujtesës përcaktohen në byte. Zakonisht, vlera në cilësime matet në mebibyte (Mib), por ju mund të vendosni çdo vlerë, nga byte deri në petabyte. Këtu është e njëjta situatë si me CPU-në — nëse vendosni një kërkesë për sasi memorje që tejkalon kapacitetin e memories në nyjet tuaja, përfundimi i këtij pod-i nuk do të planifikohet. Por, ndryshe nga burimet e procesorëve, memoria nuk është e comprimuar, sepse nuk ka asnjë mënyrë për ta kufizuar përdorimin e saj. Prandaj, ekzekutimi i kontejnerit do të ndalet sapo të kalojë kufirin e memories së caktuar.
Është e rëndësishme të mbani mend se nuk mund të konfiguroni kërkesa që tejkalojnë madhësinë e burimeve që nodes tuaj mund të ofrojnë. Karakteristikat e burimeve të zakonshme për makinat virtuale GKE mund të gjenden në lidhjet e vendosura nën këtë video.
Në një botë ideale, konfigurimet e containerit do të ishin mjaftueshëm për të siguruar që proceset të kalojnë pa probleme. Por bota reale është ndryshe; njerëzit mund të harrojnë lehtë të konfigurojnë përdorimin e burimeve, ose hakerët mund të vendosin kërkesa dhe kufizime që tejkalojnë mundësitë reale të infrastrukturës. Për të parandaluar zhvillimin e skenarëve të tillë, mund të konfiguroni kuota burimesh ResourceQuota dhe gamat e kufizimeve LimitRange.
Pas krijimit të hapësirave të emrave, ato mund të bllokohen me anë të kuotave. Për shembull, nëse keni hapësira emrash prodhimi dhe zhvillimi, një model përdoret ku kuotat për prodhim nuk ekzistojnë fare, ndërsa kuotat për zhvillim janë shumë të rrepta. Kjo i lejon prodhimit, në rast të një rritjeje të papritur të trafik, të marrë të gjithë burimin e disponueshëm, duke bllokuar krejtësisht zhvillimin.
Kuota e burimeve mund të duket kështu. Në këtë shembull, ka 4 kategori – këto janë 4 rreshta të poshtëm të kodit.
Le të shqyrtojmë secilën prej tyre. Requests.cpu është numri maksimal i kërkesave të kombinuara të fuqisë procesorike që mund të vijnë nga të gjitha enët (containers) e hapësirës emri. Në këtë shembull, mund të keni 50 enë me kërkesa prej 10m, pesë enë me kërkesa prej 100m ose thjesht një enë me kërkesë 500m. Deri sa shuma e përgjithshme e requests.cpu për këtë hapësirë emri të jetë më pak se 500m, gjithçka do të jetë në rregull.
Kërkesa për memorie requests.memory është sasia maksimale e kërkesave të kombinuara për memorie që mund të kenë të gjitha enët në hapësirën emri. Ashtu si në rastin e mëparshëm, mund të keni 50 enë me 2 MiB, pesë enë me 20 MiB ose një enë të vetme me 100 MiB, derisa shuma e përgjithshme e memories së kërkuar në hapësirën emri të jetë më pak se 100 mebibajt.
Limits.cpu — është vlera maksimale e kombinuar e fuqisë procesorike që mund të përdorin të gjitha kontejnerët në hapësirën emërtuese. Mund të mendohet si kufiri i kërkesave të fuqisë së procesorit.
Më në fund, limits.memory – është sasia maksimale e përgjithshme e memories që mund të përdorin të gjithë kontejnerët në hapësirën emërtuese. Ky është kufiri i kërkesave të përgjithshme për memory.
Pra, me njësinë e parazgjedhur, kontejnerët në grumbullin Kubernetes punojnë me burime llogaritur pa kufizime. Me ndihmën e kuotave të burimeve, administratorët e grumbullit mund të kufizojnë konsumin e burimeve dhe krijimin e saj në bazë të hapësirave emërtuese. Në hapësirën emërtuese, moduli pod ose kontejneri mund të konsumojë aq fuqi CPU dhe memorie sa është e përcaktuar nga kuota e burimeve të hapësirave emërtuese. Megjithatë, ka shqetësime se një pod ose kontejner mund të monopolizojë të gjitha burimet e disponueshme. Për të parandaluar një situatë të tillë, përdoret kufiri i gamës limit Range – politika e kufizimit të shpërndarjes së burimeve (për podët ose kontejnerët) në hapësirën emërtuese.
Kufiri i gamës ofron kufizime që mund të:
- të sigurojë përdorimin minimal dhe maksimal të burimeve kompjuterike për çdo modul ose kontejner në hapësirën emërtimore;
- të detyrojë ekzekutimin e kërkesës minimale dhe maksimale për ruajtjen Storage Request për çdo PersistentVolumeClaim në hapësirën emërtimore;
- të vendosë me forcë raportin ndërmjet kërkesës Request dhe kufizimit Limit për burimin në hapësirën emërtimore;
- të vendosë Requests/Limits si parametra të paracaktuar për burimet kompjuterike në hapësirën emërtimore dhe t'i fusë ato automatikisht në kontejnerët gjatë ekzekutimit.
Në këtë mënyrë, mund të krijoni një kufi të caktuar në hapësirën tuaj emërtimore. Ndryshe nga kuota, e cila zgjerohet në të gjithë hapësirën emërtimore, Limit Range përdoret për kontejnerët e veçantë. Kjo mund të parandalojë krijimin e kontejnerëve shumë të vegjël ose të tjera, të gjigantëve brenda hapësirës emërtimore. Limit Range mund të duket kështu.
Ashtu si në rastin e mëparshëm, këtu mund të identifikoni 4 seksione. Le të shqyrtojmë secilin.
Në seksionin default, janë vendosur kufizime të paracaktuara për kontejnerin në pod. Nëse i vendosni këto vlera brenda kufijve të paracaktuar, atëherë çdo kontejner për të cilin këto vlera nuk janë vendosur qartë do të udhëhiqet nga vlerat e paracaktuara.
Në seksionin defaultRequest, janë konfiguruar kërkesat e paracaktuara për kontejnerin në pod. Po ashtu, nëse i vendosni këto vlera brenda kufijve të paracaktuar, atëherë çdo kontejner për të cilin këto parametra nuk janë vendosur qartë do të përdorë këto vlera si të paracaktuara.
Në seksionin max, janë caktuar kufizimet maksimale që mund të vendosen për konteinera në pod. Vlerat në seksionin default dhe kufizimet për kontejnerin nuk mund të vendosen më lart se ky kufi. Është e rëndësishme të theksohet se, nëse vendoset një vlerë max dhe seksi i default-it nuk ekziston, atëherë vlera maksimale bëhet vlera e paracaktuar.
Në seksionin min, janë caktuar kërkesat minimale që mund të vendosen për kontejnerin në pod. Në këtë rast, vlerat në seksionin default dhe kërkesat për kontejnerin nuk mund të vendosen më poshtë se ky kufi.
E rëndësishme të theksohet se nëse kjo vlerë është përcaktuar, vlera e parazgjedhur - jo, atëherë vlera minimale bëhet kërkesë parazgjedhje.
Në përfundim, këto kërkesa burimesh përdoren nga planifikuesi i Kubernetes për të ekzekutuar ngarkesat tuaja të punës. Është shumë e rëndësishme të kuptoni se si funksionon kjo, për të cilën duhet të konfiguroni saktë kontejnerët tuaj. Supozoni se dëshironi të drejtoni disa module në klasterin tuaj. Duke supozuar se specifikimet e pod-it janë të vlefshme, plani i Kubernetes do të përdorë balancimin rotativ për të zgjedhur një nyje për të ekzekutuar ngarkesën e punës.
Kubernetes do të kontrollojë nëse nyja Node 1 ka burimet e nevojshme për të përmbushur kërkesat e kontejnerëve të pod-it dhe nëse jo, do të kalojë te nyja tjetër. Nëse asnjë nga nyjat në sistem nuk është në gjendje të përmbushë kërkesat, pods do të kalojnë në gjendjen e pritjes Pending state. Me funksione të tilla si automatikisht përmasos, Google Kubernetes Engine (GKE) mund të përcaktojë automatikisht gjendjen e pritjes dhe të krijojë disa nyje shtesë.
Nëse në të ardhmen ndodhin kapacitete të tepruara në nyje, funksioni i automatikës do të reduktojë numrin e tyre për të kursyer para. Kjo është arsyeja pse Kubernetes planifikon pod-ët në bazë të kërkesave. Megjithatë, kufiri mund të jetë më i lartë se kërkesat, dhe në disa raste, një nyje mund në të vërtetë të harxhojë burimet. Ne e quajmë këtë gjendje "overcommitment state".
Ashtu siç e thashë, kur bëhet fjalë për procesorin, Kubernetes do të fillojë të kufizojë pod-ët. Çdo pod do të marrë aq sa ka kërkuar, por nëse nuk arrin kufirin, do të fillojë të aplikohet rregulla e ndaljes.
Sa i përket burimeve të memories, Kubernetes është i detyruar të marrë vendime se cilët pod-e të fshijë dhe cilët të mbajë derisa të lirosh burimet e sistemit, përndryshe i gjithë sistemi do të shembet.
Le të imagjinomë një skenar ku keni një makinë që ka eklipsuar kufirin e memories – si do të veprojë Kubernetes në këtë rast?
Kubernetes do të kërkojë pod-e që po përdorin më shumë burime se sa kanë kërkuar. Kështu që nëse kontenjerët tuaj nuk kanë asnjë kërkesë, do të thotë se ata përdorin më shumë se ç'kanë kërkuar, thjesht sepse nuk kanë kërkuar asgjë! Këta kontenjerë bëhen kandidatët kryesorë për të u çaktivizuar. Kandidatët e ardhshëm janë kontenjerë që përmbushën të gjitha kërkesat e tyre, por ende janë nën kufirin maksimal.
Kështu që nëse Kubernetes gjen disa pod-e që kanë tejkaluar parametrat e kërkesave të tyre, atëherë do t'i renditë ato sipas prioritetit dhe më pas do të heqë modulat me prioritetin më të ulët. Nëse të gjitha modulet kanë të njëjtin prioritet, Kubernetes do të ndalojë ato pod-e që kanë tejkaluar kërkesat e tyre më shumë se pod-et e tjera.
Në raste shumë të rralla, Kubernetes mund të ndalojë pod-e që ende janë brenda kërkesave të tyre. Kjo mund të ndodhë kur komponente të tilla kritike të sistemit si agjenti Kubelet ose Docker fillojnë të konumojnë më shumë burime se sa ishin rezervuar për ta.
Pra ndaj, në fazat fillestare të punës së kompanive të vogla, klasteri Kubernetes mund të funksionojë shkëlqyer pa instaluar kërkesa për burime dhe kufizime, por ndërsa ekipet dhe projektet tuaja fillojnë të rriten në madhësi, rrezikoni të përballeni me probleme në këtë fushë. Shtimi i kërkesave dhe kufizimeve në modulët dhe hapësirat tuaja të emrave kërkon shumë pak përpjekje shtesë dhe mund të parandalojë shumë shqetësime.
Pak reklamë 🙂
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish më i lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
