Për çdo burim Kubernetes, mund të konfiguroni dy lloje kërkesash - Kërkesat dhe Limitet. E para përshkruan kërkesat minimale për disponueshmërinë e burimeve të nyjeve të lira të nevojshme për të drejtuar një kontejner ose pod, e dyta kufizon rreptësisht burimet në dispozicion të kontejnerit.
Kur Kubernetes planifikon pods, është shumë e rëndësishme që kontejnerët të kenë burime të mjaftueshme për të funksionuar siç duhet. Nëse po planifikoni të vendosni një aplikacion të madh në një nyje me burime të kufizuara, është e mundur që ai të mos funksionojë sepse nyja po mbaron memorien ose po i mbaron fuqia e CPU-së. Në këtë artikull, ne do të shikojmë se si mund të zgjidhni mungesat e fuqisë kompjuterike duke përdorur kërkesat dhe kufijtë e burimeve.
Kërkesat dhe Limitet janë mekanizma që Kubernetes përdor për të menaxhuar burime të tilla si CPU dhe memorie. Kërkesat janë ato që sigurojnë që kontejneri të marrë burimin e kërkuar. Nëse një kontejner kërkon një burim, Kubernetes do ta planifikojë atë vetëm në një nyje që mund ta sigurojë atë. Limitet kontrollojnë që burimet e kërkuara nga kontejneri nuk do të kalojnë kurrë një vlerë të caktuar.
Një kontejner mund të rrisë fuqinë e tij llogaritëse vetëm deri në një kufi të caktuar, pas së cilës do të kufizohet. Le të shohim se si funksionon. Pra, ekzistojnë dy lloje burimesh - procesori dhe memoria. Planifikuesi Kubernetes përdor të dhëna në lidhje me këto burime për të kuptuar se ku të ekzekutoni podet tuaja. Një specifikim tipik i burimit për një pod duket kështu.
Çdo enë në një pod mund të vendosë pyetjet dhe kufizimet e veta, të gjitha janë shtesë. Burimet e procesorit përcaktohen në milikore. Nëse kontejneri juaj ka nevojë për dy bërthama të plota për të funksionuar, ju vendosni vlerën në 2000 m. Nëse kontejnerit i nevojitet vetëm fuqia e 1/4 e bërthamës, vlera do të jetë 250 m. Mbani në mend se nëse caktoni një vlerë burimi CPU më të madhe se numri i bërthamave të nyjës më të madhe, pod juaj nuk do të planifikohet të fillojë fare. Një situatë e ngjashme do të ndodhë nëse keni një Pod që ka nevojë për katër bërthama dhe grupi Kubernetes përbëhet nga vetëm dy makina kryesore virtuale.
Nëse aplikacioni juaj nuk është krijuar posaçërisht për të përfituar nga bërthama të shumta (programe si kompjuteri kompleks shkencor dhe operacionet e bazës së të dhënave vijnë në mendje), atëherë praktika më e mirë është të vendosni Kërkesat e CPU-së në 1 ose më të ulët dhe më pas të ekzekutoni më shumë kopje në shkallëzueshmëri. Kjo zgjidhje do t'i japë sistemit fleksibilitet dhe besueshmëri më të madhe.
Kur bëhet fjalë për kufizimet e CPU-së, gjërat bëhen më interesante pasi konsiderohet një burim i kompresueshëm. Nëse aplikacioni juaj fillon t'i afrohet kufirit të fuqisë së procesorit, Kubernetes do të fillojë të ngadalësojë kontejnerin tuaj duke përdorur CPU Throttling - duke ulur frekuencën e procesorit. Kjo do të thotë që CPU-ja do të mbytet artificialisht, duke i dhënë aplikacionit performancë më të keqe, por procesi nuk do të ndërpritet ose hiqet.
Burimet e memories përcaktohen në bajt. Zakonisht vlera në cilësimet matet në mebibajt Mib, por mund të vendosni çdo vlerë, nga bajt në petabajt. E njëjta situatë vlen edhe këtu si me CPU - nëse vendosni një kërkesë për një sasi memorie më të madhe se sasia e memories në nyjet tuaja, ajo pod nuk do të planifikohet të ekzekutohet. Por ndryshe nga burimet CPU, memoria nuk është e ngjeshur sepse nuk ka asnjë mënyrë për të kufizuar përdorimin e saj. Prandaj, ekzekutimi i kontejnerit do të ndalet sapo të shkojë përtej memories së caktuar për të.
Është e rëndësishme të mbani mend se nuk mund të konfiguroni kërkesat që tejkalojnë burimet që mund të ofrojnë nyjet tuaja. Specifikimet e burimeve të përbashkëta për makinat virtuale GKE mund të gjenden në lidhjet më poshtë kësaj video.
Në një botë ideale, cilësimet e paracaktuara të kontejnerit do të ishin të mjaftueshme për të mbajtur rrjedhat e punës të funksionojnë 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 kufizime që tejkalojnë aftësitë reale të infrastrukturës. Për të parandaluar që të ndodhin skenarë të tillë, mund të konfiguroni kuotat e burimeve ResourceQuota dhe LimitRange.
Pasi të jetë krijuar një hapësirë emri, ajo mund të bllokohet duke përdorur kuotat. Për shembull, nëse keni hapësirat e emrave prod dhe dev, modeli është se nuk ka fare kuota prodhimi dhe kuota shumë strikte zhvillimi. Kjo i lejon prod-it, në rast të një rritjeje të mprehtë të trafikut, të marrë përsipër të gjithë burimin e disponueshëm, duke bllokuar plotësisht dev.
Kuota e burimeve mund të duket kështu. Në këtë shembull ka 4 seksione - këto janë 4 rreshtat e fundit të kodit.
Le të shohim secilin prej tyre. Requests.cpu është numri maksimal i kërkesave të kombinuara të CPU-së që mund të vijnë nga të gjithë kontejnerët në hapësirën e emrave. Në këtë shembull, mund të keni 50 kontejnerë me 10 milion kërkesa, pesë kontejnerë me 100 milion kërkesa ose vetëm një kontejnerë me 500 milion kërkesa. Për sa kohë që numri total i kërkesave.cpu i një hapësire emri të caktuar është më pak se 500 m, gjithçka do të jetë mirë.
Kërkesat e kërkuara nga memoria.memory është sasia maksimale e kërkesave të kujtesës së kombinuar që mund të kenë të gjithë kontejnerët në hapësirën e emrave. Si në rastin e mëparshëm, mund të keni 50 kontejnerë 2 mib, pesë kontejnerë 20 mib ose një kontejner të vetëm 100 mib për sa kohë që sasia totale e memories së kërkuar në hapësirën e emrave është më pak se 100 mebibajt.
Limits.cpu është sasia maksimale e kombinuar e fuqisë së CPU-së që mund të përdorin të gjithë kontejnerët në hapësirën e emrave. Ne mund ta konsiderojmë këtë si kufirin e kërkesave për fuqi të procesorit.
Së fundi, limits.memory është sasia maksimale e memories së përbashkët që mund të përdorin të gjithë kontejnerët në hapësirën e emrave. Ky është një kufi në kërkesat totale të memories.
Pra, si parazgjedhje, kontejnerët në një grup Kubernetes funksionojnë me burime të pakufizuara llogaritëse. Me kuotat e burimeve, administratorët e grupimeve mund të kufizojnë konsumin e burimeve dhe krijimin e burimeve bazuar në hapësirën e emrave. Në një hapësirë emri, një pod ose kontejner mund të konsumojë aq fuqi dhe memorie të CPU-së sa përcaktohet nga kuota e burimit të hapësirës së emrave. Megjithatë, ekziston një shqetësim se një pod ose kontejner mund të monopolizojë të gjitha burimet e disponueshme. Për të parandaluar këtë situatë, përdoret një gamë kufiri - një politikë për kufizimin e shpërndarjes së burimeve (për pods ose kontejnerë) në hapësirën e emrave.
Gama e kufirit ofron kufizime që mund të:
- Siguroni përdorimin minimal dhe maksimal të burimeve llogaritëse për çdo modul ose kontejner në hapësirën e emrave;
- të zbatojë kërkesat e ruajtjes minimale dhe maksimale të Starage Request për çdo PresistentVolumeClaim në hapësirën e emrave;
- të zbatojë një marrëdhënie midis një kërkese dhe një kufiri për një burim në një hapësirë emri;
- vendosni Kërkesat/Limitet e paracaktuara për burimet llogaritëse në hapësirën e emrave dhe injektoni ato automatikisht në kontejnerë në kohën e ekzekutimit.
Në këtë mënyrë ju mund të krijoni një gamë kufiri në hapësirën tuaj të emrave. Ndryshe nga një kuotë, e cila zbatohet për të gjithë hapësirën e emrave, Limit Range përdoret për kontejnerë individualë. Kjo mund t'i parandalojë përdoruesit të krijojnë kontejnerë shumë të vegjël ose, anasjelltas, gjigantë brenda hapësirës së emrave. Gama e kufirit mund të duket kështu.
Ashtu si në rastin e mëparshëm, këtu mund të dallohen 4 seksione. Le të shohim secilin.
Seksioni i paracaktuar vendos kufijtë e paracaktuar për kontejnerin në pod. Nëse i vendosni këto vlera në intervalin ekstrem, atëherë çdo kontejner për të cilin këto vlera nuk janë vendosur në mënyrë eksplicite do të ndjekë vlerat e paracaktuara.
Seksioni i paracaktuar i kërkesës defaultRequest konfiguron kërkesat e paracaktuara për kontejnerin në pod. Përsëri, nëse i vendosni këto vlera në diapazonin ekstrem, atëherë çdo kontejner që nuk i vendos në mënyrë eksplicite këto opsione do të paracaktojë këto vlera.
Seksioni max specifikon kufijtë maksimalë që mund të vendosen për një kontejner në pod. Vlerat në seksionin e paracaktuar dhe kufijtë e kontejnerit nuk mund të vendosen mbi këtë kufi. Është e rëndësishme të theksohet se nëse vlera është vendosur në max dhe nuk ka seksion të paracaktuar, atëherë vlera maksimale bëhet vlera e paracaktuar.
Seksioni min specifikon kërkesat minimale që mund të vendosen për një kontejner në një pod. Sidoqoftë, vlerat në seksionin e paracaktuar dhe pyetjet për kontejnerin nuk mund të vendosen nën këtë kufi.
Përsëri, është e rëndësishme të theksohet se nëse kjo vlerë është vendosur, parazgjedhja nuk është, atëherë vlera minimale bëhet kërkesa e paracaktuar.
Këto kërkesa për burime përdoren përfundimisht nga programuesi Kubernetes për të ekzekutuar ngarkesat tuaja të punës. Në mënyrë që ju të konfiguroni saktë kontejnerët tuaj, është shumë e rëndësishme të kuptoni se si funksionon. Le të themi se dëshironi të ekzekutoni shumë pods në grupin tuaj. Duke supozuar se specifikimet e pod janë të vlefshme, orari i Kubernetes do të përdorë balancimin e rrumbullakët për të zgjedhur një nyje për të ekzekutuar ngarkesën e punës.
Kubernetes do të kontrollojë nëse Node 1 ka burime të mjaftueshme për të përmbushur kërkesat nga kontejnerët e pod, dhe nëse nuk ka, do të kalojë në nyjen tjetër. Nëse asnjë nga nyjet në sistem nuk është në gjendje të plotësojë kërkesat, pods do të kalojnë në gjendjen në pritje. Duke përdorur veçoritë e motorit të Google Kubernetes, të tilla si shkallëzimi automatik i nyjeve, GKE mund të zbulojë automatikisht gjendjen e pritjes dhe të krijojë disa nyje të tjera shtesë.
Nëse më pas ju mbaron kapaciteti i nyjeve, shkallëzimi automatik do të zvogëlojë numrin e nyjeve për t'ju kursyer para. Kjo është arsyeja pse Kubernetes planifikon pods bazuar në kërkesat. Megjithatë, kufiri mund të jetë më i lartë se kërkesat, dhe në disa raste nyja mund të mbarojë me burime. Ne e quajmë këtë gjendje të mbiangazhimit shtetëror.
Siç thashë, kur bëhet fjalë për CPU, Kubernetes do të fillojë të kufizojë pods. Çdo pod do të marrë aq sa ka kërkuar, por nëse nuk arrin kufirin, mbytja do të fillojë të zbatohet.
Kur bëhet fjalë për burimet e memories, Kubernetes është i detyruar të marrë vendime se cilat pod-e të fshihen dhe cilat të mbajnë derisa të lironi burimet e sistemit ose i gjithë sistemi do të rrëzohet.
Le të imagjinojmë një skenar ku ju keni një makinë që po mbaron memoria - si do ta trajtonte Kubernetes këtë?
Kubernetes do të kërkojë pods që përdorin më shumë burime sesa kërkuan. Pra, nëse kontejnerët tuaj nuk kanë fare Kërkesa, kjo do të thotë se ata nuk përdorin më shumë sesa kanë kërkuar, thjesht sepse nuk kanë kërkuar asgjë! Kontejnerë të tillë bëhen kandidatët kryesorë për mbyllje. Kandidatët e radhës janë kontejnerët që kanë plotësuar të gjitha kërkesat e tyre por janë ende nën kufirin maksimal.
Pra, nëse Kubernetes gjen disa pods që kanë tejkaluar parametrat e tyre të kërkesës, ai do t'i renditë ato sipas përparësisë dhe më pas do t'i heqë podet me përparësi më të ulët. Nëse të gjitha pods-et kanë të njëjtin prioritet, atëherë Kubernetes do t'i mbyllë ato pods që tejkalojnë kërkesat e tyre më shumë se pod-et e tjera.
Në raste shumë të rralla, Kubernetes mund të ndërpresë pods që janë ende brenda fushës së kërkesave të tyre. Kjo mund të ndodhë kur komponentët kritikë të sistemit si agjenti Kubelet ose Docker fillojnë të konsumojnë më shumë burime sesa ato që ishin rezervuar për ta.
Pra, në fazat e hershme të kompanive të vogla, një grup Kubernetes mund të funksionojë mirë pa vendosur kërkesa dhe kufizime për burime, por ndërsa ekipet dhe projektet tuaja fillojnë të rriten në madhësi, ju rrezikoni të hasni probleme në këtë fushë. Shtimi i pyetjeve dhe kufizimeve në modulet dhe hapësirat tuaja të emrave kërkon shumë pak përpjekje shtesë dhe mund të kursejë shumë telashe.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më 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 dollarë! Lexoni rreth
Burimi: www.habr.com