Për çdo burim Kubernetes, ka mundësinë për të vendosur dy lloje të kërkesave — Requests dhe Limits. E para përshkruan kërkesat minimale për disponueshmërinë e burimeve të lira në nod, të nevojshme për të nisur një kontejner ose pod, e dyta kufizon rreptësisht 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ë implementoni 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 e mbaron memorien ose i mungon fuqia e procesorit. Në këtë artikull do të shqyrtojmë se si mund të zgjidhni problemet e mungesës së fuqisë kompjuterike nëpërmjet kërkesave për burime dhe kufizimeve.
Kërkesat Requests dhe kufizimet Limits janë mekanizma që Kubernetes përdor për të menaxhuar burime të tilla si procesori dhe memoria. Kërkesat janë ato, për shkak të të cilave kontejneri merr garanci për burimin e kërkuar. Nëse një kontejner kërkon një burim, Kubernetes do ta planifikojë atë vetëm në nodin që është në gjendje ta ofrojë. Kufizimet Limits kontrollojnë që burimet e kërkuara nga kontejneri të mos tejkalojnë kurrë një vlerë të caktuar.
Kontejneri mund të rrisë fuqitë kompjuterike vetëm deri në një kufi të caktuar, pas së cilës do të kufizohet. Le të shohim se si funksionon kjo. Pra, ka dy lloje burimesh — procesori dhe memoria. Planifikuesi i Kubernetes përdor të dhënat për këto burime për të zbuluar se ku të nisë pod-et tuaja. Specifikimi tipik i burimeve për një pod duket kështu.
Çdo kontejner në pod mund të vendosë kërkesat dhe kufizimet e tij të veta, dhe të gjitha këto janë aditive. Burimet e CPU-së përcaktohen në milikra. Nëse kontejneri juaj ka nevojë për dy bërthama të plota për ekzekutimin, vendosni vlerën 2000m. Nëse kontejneri ka nevojë vetëm për fuqinë e 1/4 bërthame, vlera do të jetë 250m. Mbani parasysh se nëse caktoni një vlerë për burimet e CPU-së më të madhe se numri i bërthamave të nodit më të madh, atëherë ekzekutimi i pod-it tuaj nuk do të planifikohet fare. Një situatë e ngjashme do të ndodhi nëse keni një pod që ka nevojë për katër bërthama, ndërsa klasteri Kubernetes përbëhet vetëm nga dy makineri virtuale kryesore.
Nëse aplikacioni juaj nuk është zhvilluar posaçërisht për të shfrytëzuar përfitimet e shumë bërthamave (duke pasur parasysh aplikacione si llogaritjet shkencore komplekse dhe operacionet me databaza), praktikën më të mirë është të vendosni Kërkesat e CPU-së në 1 ose më pak, duke vazhduar me ekzekutimin e një numri më të madh replikash për ndryshueshmëri. Ky zgjidhje i ofron sistemit fleksibilitet dhe besueshmëri më të madhe.
Kur bëhet fjalë për kufizimet e CPU-së, gjithçka bëhet më interesante, pasi ajo konsiderohet një burim shtypës. Nëse aplikacioni juaj fillon të afrojë kufirin e fuqisë së CPU-së, Kubernetes do të fillojë të ngadalësojë kontejnerin tuaj duke përdorur CPU Throttling — uljen e frekuencës së procesorit. Kjo do të thotë se CPU do të jetë artificialisht e kufizuar, duke i ofruar aplikacionit potencialisht një performancë më të dobët, megjithatë procesi nuk do të ndalet ose të dështojë.
Burimet e memorjes përcaktohen në byte. Në përgjithësi, vlera në cilësimet matet në mebibyte (MiB), por mund të caktoni çdo vlerë, nga byte deri në petabyte. Këtu ka ndodhi e njëjtë si me CPU-në — nëse vendosni një kërkesë për sasi memorjeje që tejkalon kapacitetin e memorjes në nodet tuaja, ekzekutimi i këtij pod-i nuk do të planifikohet. Por ndryshe nga burimet e CPU-së, memoria nuk është e kompresueshme, sepse nuk ka asnjë mënyrë për të kufizuar përdorimin e saj. Prandaj, ekzekutimi i kontejnerit do të ndalet, sapo ai të kalojë kufirin e memorjes së caktuar.
Është e rëndësishme të mbani mend se nuk mund të konfiguroni kërkesa që tejkalojnë madhësinë e burimeve që nodet tuaja mund të ofrojnë. Karakteristikat e burimeve të përbashkëta për makinat virtuale GKE mund të gjenden në lidhjet e vendosura nën këtë video.
Në një botë ideale, konfigurimet e kontenierëve nën default do të ishin mjaft të mjaftueshme që punët të zhvilloheshin pa probleme. Por bota reale nuk është e tillë, njerëzit mund të harrojnë lehtësisht të konfigurojnë përdorimin e burimeve ose hakerët do të vendosin kërkesa dhe kufij që tejkalojnë kapacitetet reale të infrastrukturës. Për të parandaluar zhvillimin e skenarëve të tillë, mund të konfigurohen kuota burimesh ResourceQuota dhe intervalet e kufijve LimitRange.
Pas krijimit të hapësirave të emrave, ato mund të bllokohen përmes kuotave. Për shembull, nëse keni hapësira emrash prodhimi dhe zhvillimi, përdoret një model ku kuotat për prodhimin nuk ekzistojnë fare, ndërsa kuotat për zhvillimin janë shumë strikte. Kjo lejon që prodhimi, në rast të një rritjeje të papritur të trafikut, të marrë të gjithë burimin e kaluar, duke bllokuar plotësisht zhvillimin.
Kuota e burimeve mund të duket ashtu. Në këtë shembull, ka 4 sekcione – këto janë 4 rreshta të poshtëm të kodit.
Le të shqyrtojmë secilin prej tyre. Requests.cpu është maksimalja e numrit të kombinuar të kërkesave të fuqisë procesorit që mund të vijnë nga të gjithë kontenierët e hapësirës së emrave. Në këtë shembull, mund të keni 50 kontenierë me kërkesa prej 10m, pesë kontenierë me kërkesa prej 100m ose thjesht një kontenier me kërkesë 500m. Pavarësisht se sa shumë është shuma e requests.cpu të kësaj hapësire emri, do të jetë në rregull derisa ajo të jetë më pak se 500m.
Kërkesa e memories requests.memory është sasia maksimale e kërkesave të kombinuara të memories që mund të kenë të gjithë kontenierët në hapësirën e emrave. Si në rastin e mëparshëm, mund të keni 50 kontenierë të 2 mib, pesë kontenierë të 20 Mib ose një të vetëm me 100 Mib, derisa shuma totale e memories së kërkuar në hapësirën e emrave të mbetet nën 100 mebibajtë.
Limits.cpu është vlera maksimale e kombinuar e fuqisë procesorit që mund të përdorin të gjithë kontenierët e hapësirës së emrave. Mund të mendohet si kufiri i kërkesave të fuqisë procesorit.
Finalmente, limits.memory është sasia maksimale e memories totale që mund të përdorin të gjitha kontejnerët në hapësirën e emrave. Ky kufizim është për kërkesat totale të memories.
Pra, me parazgjedhje, kontejnerët në klusterin Kubernetes funksionojnë me burime kompjuterike të papërcaktuar. Me anë të kuotave të burimeve, adminstratorët e klusterit mund të kufizojnë konsumimin e burimeve dhe krijimin e tyre bazuar në hapësirat e emrave. Në hapësirën e emrave, moduli pod ose kontejneri mund të konsumojnë aq kapacitet CPU dhe memorje sa përcaktohet nga kuota e burimeve të hapësirave të emrave. Sidoqoftë, ekziston shqetësimi se një pod ose kontejner mund të monopolizojë të gjitha burimet në dispozicion. Për të parandaluar një situatë të tillë, përdoret kufiri i gamës limit Range – një politikë kufizuese për shpërndarjen e burimeve (për podet ose kontejnerët) në hapësirën e emrave.
Gama e limitit ofron kufizime që mund të:
- sigurojnë përdorimin minimal dhe maksimal të burimeve kompjuterike për çdo modul ose kontejner në hapësirën e emrave;
- kufizojnë kërkesat minimale dhe maksimale për ruajtje Storage Request për çdo PersistentVolumeClaim në hapësirën e emrave;
- kufizojnë në mënyrë të detyruar raportin midis kërkesës Request dhe kufizimeve Limit për burimin në hapësirën e emrave;
- vendosin Requests/Limits si parazgjedhje për burimet kompjuterike në hapësirën e emrave dhe i aplikojnë ato automatikisht në kontejnerët gjatë ekzekutimit.
Kështu, ju mund të krijoni një gamë kufizimi në hapësirën tuaj të emrave. Ndryshe nga kuota, e cila shtrihen në të gjithë hapësirën e emrave, Limit Range përdoret për kontejnerë të veçantë. Kjo mund të parandalojë krijimin e kontejnerëve shumë të vegjël ose, nga ana tjetër, shumë të mëdhenj brenda hapësirës së emrave. Gama e kufizimit Limit Range mund të dukej kështu.
Ashtu siç kemi parë në rastin e mëparshëm, këtu mund të dallojmë 4 seksione. Le të shqyrtojmë secilën.
Në seksionin default, vendosen kufizimet si parazgjedhje për kontejnerin në pod. Nëse i jepni këto vlera në gamën e kufizimit, çdo kontejner për të cilin këto vlera nuk janë vendosur shprehimisht do të udhëhiqet nga vlerat si parazgjedhje.
Në seksionin e kërkesës për parazgjedhje defaultRequest janë të konfiguruara kërkesat e parazgjedhura për kontejnerin në pod. Po ashtu, në qoftë se i vendosni këto vlera brenda kufijve të lejuar, çdo kontejner për të cilin këto parametra nuk janë emërtuar qartë, do të përdorë këto vlera si parazgjedhje.
Në seksionin max janë përcaktuar kufijtë maksimale që mund të vendosen për kontejnerin në pod. Vlerat në seksionin default dhe kufijtë për kontejnerin nuk mund të vendosen më lart se ky kufi. Është e rëndësishme të theksohet se nëse është vendosur një vlerë max dhe seksioni default mungon, atëherë vlera maksimale bëhet vlera e parazgjedhur.
Në seksionin min janë përcaktuar 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.
Po ashtu, është e rëndësishme të theksohet se nëse kjo vlerë është vendosur, vlera default – jo, atëherë vlera minimale bëhet kërkesa e parazgjedhur.
Në përfundim, këto kërkesa burimesh përdoren nga planifikuesi Kubernetes për të realizuar ngarkesat tuaja të punës. Për t'i konfiguruar saktësisht kontejnerët tuaj, është shumë e rëndësishme të kuptoni si funksionon kjo. Le të supozojmë se doni të nisni disa modul në klasterin tuaj. Duke supozuar se specifikimet e podit janë valide, në planifikimin Kubernetes do të përdoret balancimi ciklik për të zgjedhur nodin për të realizuar ngarkesën e punës.
Kubernetes do të kontrollojë nëse ka mjaft burime në nodin Node 1 për të përmbushur kërkesat e kontejnerëve të podit, dhe nëse jo, do të kalojë në nodin tjetër. Nëse asnjë nga nodet në sistem nuk është në gjendje të përmbushë kërkesat, podet do të kalojnë në gjendjen e pritjes Pending state. Me funksione të tilla si autoskalimi i nodëve, GKE mund të identifikojë automatikisht gjendjen e pritjes dhe të krijojë disa nodë shtesë.
Nëse më vonë ndodhin kapacitete të tepërta në nodë, funksioni i autoskalimit do të reduktojë numrin e tyre për t'ju kursyer para. Kjo është arsyeja pse Kubernetes planifikon podet mbi bazën e kërkesave. Megjithatë, kufiri mund të jetë më i lartë se kërkesat, dhe në disa raste, nodi mund të shterojë faktikisht burimet. Ne e quajmë këtë gjendje gjendje të shfrytëzimit të tepërt overcommitment state.
Si duhet, nëse flasim për procesorin, Kubernetes do të fillojë të kufizojë pod-ët. Çdo pod do të marrë sa i ka kërkuar, por nëse nuk arrin limitin, atëherë do të fillojë aplikimi i tronditjes.
Sa i përket burimeve të memories, këtu Kubernetes është i detyruar të marrë vendime në lidhje me cilët pod-ë të fshijë dhe cilët të ruajë, derisa të lirojë burimet e sistemit, përndryshe e gjithë sistemi do të përfundojë.
Le të imagjinojmë një skenar ku keni një makinë që ka shpenzuar limitin e memories – si do të veprojë Kubernetes në këtë rast?
Kubernetes do të kërkojë pod-ët që përdorin më shumë burime se sa kanë kërkuar. Pra, nëse kontejnerët tuaj s'kanë asnjë kërkesë Requests, kjo do të thotë se për shkak se ata nuk kanë kërkuar asgjë, ata po përdorin më shumë se sa kanë kërkuar! Këta kontejnerë bëhen kandidatët kryesorë për deaktivizim. Kandidatët e ardhshëm janë kontejnerët që kanë përmbushur të gjitha kërkesat e tyre, por që ende janë nën limitin maksimal.
Prandaj, nëse Kubernetes gjen disa pod-ë që kanë tejkaluar parametrat e kërkesave të tyre, ai do t'i renditë ato sipas prioritetit dhe pastaj do të fshijë modulet me prioritet më të ulët. Nëse të gjithë modulat kanë të njëjtin prioritet, Kubernetes do të ndërpresë punën e pod-ëve që kanë tejkaluar kërkesat e tyre më shumë se të tjerët.
Në raste shumë të rralla, Kubernetes mund të ndërpresë punën e pod-ëve që ende janë brenda kërkesave të tyre. Kjo mund të ndodhë kur komponentë kritikë të sistemit si agjenti Kubelet ose Docker fillojnë të konsumohet më shumë burime se sa ishin rezervuar për ta.
Pra, në fazat e para të funksionimit të kompanive të vogla, klasteri Kubernetes mund të funksionojë mirë pa instaluar kërkesat e burimeve dhe kufizimet, por ndërsa ekipet dhe projektet tuaja fillojnë të rriten në përmasa, ju rrezikoni të përballeni me probleme në këtë fushë. Shtimi i kërkesave dhe kufizimeve në modulet dhe hapësirat tuaja emrore kërkon pak më shumë përpjekje dhe mund të shpëtojë nga shumë shqetësime.
Pak reklamë 🙂
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish më i lirë në qendër të të dhënave Equinix Tier IV në Amsterdam? Vetëm te ne në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
