Kiekvienam Kubernetes ištekliui galite sukonfigūruoti dviejų tipų reikalavimus – užklausas ir ribas. Pirmajame aprašomi minimalūs laisvų mazgo išteklių, reikalingų konteineriui ar rinkiniui paleisti, prieinamumo reikalavimai, antrasis griežtai riboja konteineriui prieinamus išteklius.
Kai „Kubernetes“ suplanuoja rinkinius, labai svarbu, kad konteineriai turėtų pakankamai išteklių tinkamai veikti. Jei planuojate diegti didelę programą ribotų išteklių mazge, gali būti, kad ji nebus paleista, nes mazge senka atmintis arba baigiasi procesoriaus galia. Šiame straipsnyje apžvelgsime, kaip galite išspręsti skaičiavimo galios trūkumą naudodami išteklių užklausas ir apribojimus.
Užklausos ir apribojimai yra mechanizmai, kuriuos Kubernetes naudoja tvarkydama tokius išteklius kaip CPU ir atmintis. Užklausos užtikrina, kad konteineris gautų prašomus išteklius. Jei konteineris prašo išteklių, Kubernetes suplanuos jį tik mazge, kuris gali jį pateikti. Riboja, kad konteinerio prašomi ištekliai niekada neviršytų tam tikros vertės.
Konteineris gali padidinti savo skaičiavimo galią tik iki tam tikros ribos, po kurios ji bus apribota. Pažiūrėkime, kaip tai veikia. Taigi, yra dviejų tipų ištekliai – procesorius ir atmintis. „Kubernetes“ planavimo priemonė naudoja duomenis apie šiuos išteklius, kad išsiaiškintų, kur paleisti rinkinius. Įprasta podėlio išteklių specifikacija atrodo taip.
Kiekvienas konteineris talpykloje gali nustatyti savo užklausas ir ribas, visa tai yra priedas. Procesoriaus ištekliai apibrėžti milicores. Jei konteineriui reikia dviejų pilnų branduolių, nustatykite vertę į 2000 m. Jei konteineriui reikia tik 1/4 šerdies galios, vertė bus 250 m. Atminkite, kad jei priskirsite procesoriaus resurso vertę, didesnę nei didžiausio mazgo branduolių skaičius, jūsų blokas iš viso nebus suplanuotas. Panaši situacija atsitiks, jei turite „Pod“, kuriam reikia keturių branduolių, o „Kubernetes“ klasterį sudaro tik dvi pagrindinės virtualios mašinos.
Nebent jūsų programa sukurta specialiai tam, kad išnaudotų kelių branduolių teikiamus privalumus (atsižvelgiant į tokias programas kaip sudėtingas mokslinis skaičiavimas ir duomenų bazių operacijos), geriausia praktika yra nustatyti procesoriaus užklausas į 1 arba mažesnę ir paleisti daugiau kopijų, kad būtų galima keisti mastelį. Šis sprendimas suteiks sistemai daugiau lankstumo ir patikimumo.
Kalbant apie procesoriaus apribojimus, viskas tampa įdomiau, nes jis laikomas suspaudžiamu šaltiniu. Jei jūsų programa pradeda artėti prie procesoriaus galios ribos, „Kubernetes“ pradės sulėtinti konteinerį naudodama procesoriaus ribojimą, sumažindama procesoriaus dažnį. Tai reiškia, kad centrinis procesorius bus dirbtinai pristabdytas, dėl ko programa gali būti prastesnė, tačiau procesas nebus nutrauktas ar pašalintas.
Atminties ištekliai apibrėžiami baitais. Paprastai reikšmė nustatymuose matuojama mebibaitais Mib, tačiau galite nustatyti bet kokią reikšmę nuo baitų iki petabaitų. Čia galioja ta pati situacija kaip ir su centriniu procesoriumi – jei pateiksite užklausą dėl didesnio atminties kiekio nei jūsų mazgų atminties kiekis, to podelio vykdymas nebus suplanuotas. Tačiau skirtingai nei procesoriaus ištekliai, atmintis nėra suspausta, nes nėra būdo apriboti jos naudojimą. Todėl konteinerio vykdymas bus sustabdytas, kai tik jis viršys jam skirtą atmintį.
Svarbu atsiminti, kad negalite konfigūruoti užklausų, viršijančių išteklius, kuriuos gali suteikti mazgai. GKE virtualiųjų mašinų bendrinamų išteklių specifikacijas rasite nuorodose po šiuo vaizdo įrašu.
Idealiame pasaulyje pakaktų numatytųjų sudėtinio rodinio nustatymų, kad darbo eigos veiktų sklandžiai. Tačiau realus pasaulis ne toks, žmonės gali lengvai pamiršti sukonfigūruoti išteklių naudojimą arba įsilaužėliai nustatys užklausas ir apribojimus, viršijančius realias infrastruktūros galimybes. Norėdami išvengti tokių scenarijų, galite sukonfigūruoti ResourceQuota ir LimitRange išteklių kvotas.
Sukūrus vardų erdvę, ją galima užblokuoti naudojant kvotas. Pavyzdžiui, jei turite prod ir dev vardų sritis, gamybos kvotų apskritai nėra ir labai griežtos kūrimo kvotos. Tai leidžia prod, esant staigiam srauto padidėjimui, perimti visus turimus išteklius ir visiškai blokuoti kūrėją.
Išteklių kvota gali atrodyti taip. Šiame pavyzdyje yra 4 skyriai – tai 4 apatinės kodo eilutės.
Pažvelkime į kiekvieną iš jų. Requests.cpu yra didžiausias kombinuotų procesoriaus užklausų skaičius, kuris gali būti gaunamas iš visų vardų erdvėje esančių konteinerių. Šiame pavyzdyje galite turėti 50 konteinerių su 10 m užklausomis, penkis konteinerius su 100 m užklausomis arba tik vieną konteinerį su 500 m užklausomis. Kol bendras nurodytos vardų erdvės užklausų.cpu skaičius yra mažesnis nei 500 m, viskas bus gerai.
Reikalingos atminties užklausos.memory yra didžiausias kombinuotų atminties užklausų kiekis, kurį gali turėti visi vardų erdvėje esantys konteineriai. Kaip ir ankstesniu atveju, galite turėti 50 2 mib konteinerių, penkis 20 mib konteinerius arba vieną 100 mib konteinerį, jei bendras prašomos atminties kiekis vardų srityje yra mažesnis nei 100 mebibaitų.
Limits.cpu yra didžiausias bendras procesoriaus galios kiekis, kurį gali naudoti visi vardų erdvėje esantys konteineriai. Tai galime laikyti procesoriaus galios užklausų riba.
Galiausiai limits.memory yra didžiausias bendrinamos atminties kiekis, kurį gali naudoti visi vardų erdvėje esantys konteineriai. Tai yra visų atminties užklausų apribojimas.
Taigi pagal numatytuosius nustatymus „Kubernetes“ klasterio konteineriai veikia su neribotais skaičiavimo ištekliais. Naudodami išteklių kvotas, grupių administratoriai gali apriboti išteklių naudojimą ir išteklių kūrimą pagal vardų erdvę. Vardų erdvėje blokas arba konteineris gali sunaudoti tiek procesoriaus galios ir atminties, kiek nustatyta vardų erdvės išteklių kvotoje. Tačiau nerimaujama, kad viena anga ar konteineris gali monopolizuoti visus turimus išteklius. Siekiant užkirsti kelią tokiai situacijai, naudojamas ribinis diapazonas – išteklių paskirstymo (podams ar konteineriams) ribojimo vardų erdvėje politika.
Ribinis diapazonas numato apribojimus, kurie gali:
- Užtikrinti minimalų ir maksimalų skaičiavimo išteklių naudojimą kiekvienam moduliui ar konteineriui vardų erdvėje;
- vykdyti mažiausią ir didžiausią „Starage Request“ saugojimo užklausą kiekvienai „PersistentVolumeClaim“ vardų erdvėje;
- užtikrinti ryšį tarp užklausos ir išteklių vardų erdvėje apribojimo;
- nustatyti numatytuosius užklausas / apribojimus skaičiavimo ištekliams vardų erdvėje ir automatiškai įterpti juos į konteinerius vykdymo metu.
Tokiu būdu savo vardų erdvėje galite sukurti ribinį diapazoną. Skirtingai nuo kvotos, kuri taikoma visai vardų erdvei, ribinis diapazonas naudojamas atskiriems konteineriams. Tai gali neleisti vartotojams sukurti labai mažų arba, atvirkščiai, milžiniškų konteinerių vardų erdvėje. Ribinis diapazonas gali atrodyti taip.
Kaip ir ankstesniu atveju, čia galima išskirti 4 skyrius. Pažvelkime į kiekvieną.
Numatytoji skiltyje nustatomi numatytieji konteinerio ribos. Jei nustatysite šias vertes į kraštutinį diapazoną, visi konteineriai, kuriems šios reikšmės nebuvo aiškiai nustatytos, laikysis numatytosios vertės.
Numatytoji užklausų sekcija defaultRequest konfigūruoja numatytąsias talpyklos užklausas grupėje. Vėlgi, jei nustatysite šias reikšmes į kraštutinį diapazoną, visi konteineriai, kurie aiškiai nenustato šių parinkčių, nustatys šias reikšmes.
Skiltyje „Max“ nurodomos didžiausios ribos, kurias galima nustatyti talpykloje. Numatytosios skilties verčių ir sudėtinių rodinių apribojimų negalima nustatyti viršijant šią ribą. Svarbu pažymėti, kad jei reikšmė nustatyta į max ir nėra numatytosios dalies, tada maksimali reikšmė tampa numatyta reikšme.
Skiltyje „Min“ nurodomas minimalus užklausų skaičius, kurį galima nustatyti talpykloje. Tačiau numatytosios skilties verčių ir sudėtinio rodinio užklausų negalima nustatyti žemiau šios ribos.
Vėlgi, svarbu pažymėti, kad jei ši reikšmė nustatyta, numatytoji reikšmė nėra nustatyta, tada minimali reikšmė tampa numatytoji raginimu.
Šias išteklių užklausas galiausiai naudoja Kubernetes planuoklis, kad atliktų jūsų darbo krūvius. Kad galėtumėte tinkamai sukonfigūruoti konteinerius, labai svarbu suprasti, kaip tai veikia. Tarkime, kad klasteryje norite paleisti kelias ankštis. Darant prielaidą, kad pod specifikacijos galioja, Kubernetes tvarkaraštis naudos apvalų balansavimą, kad pasirinktų mazgą darbo krūviui vykdyti.
„Kubernetes“ patikrins, ar 1 mazgas turi pakankamai išteklių, kad galėtų įvykdyti užklausas iš talpyklos konteinerių, o jei ne, pereis į kitą mazgą. Jei nė vienas sistemos mazgas negali patenkinti užklausų, ankštys pereis į Laukimo būseną. Naudodama Google Kubernetes variklio funkcijas, tokias kaip mazgų automatinis mastelio keitimas, GKE gali automatiškai aptikti laukimo būseną ir sukurti dar keletą papildomų mazgų.
Jei vėliau baigsis mazgo talpa, automatinis mastelio keitimas sumažins mazgų skaičių, kad sutaupytumėte pinigų. Štai kodėl „Kubernetes“ suplanuoja rinkinius pagal užklausas. Tačiau limitas gali būti didesnis nei užklausų, o kai kuriais atvejais mazgu iš tikrųjų gali pritrūkti išteklių. Šią būseną vadiname per didelio įsipareigojimo būsena.
Kaip jau sakiau, kai kalbama apie centrinį procesorių, „Kubernetes“ pradės riboti ankštis. Kiekvienas blokas gaus tiek, kiek paprašė, bet jei nepasieks ribos, bus pradėtas reguliavimas.
Kalbant apie atminties išteklius, „Kubernetes“ yra priversta priimti sprendimus, kuriuos blokus ištrinti, o kuriuos palikti, kol atlaisvinsite sistemos išteklių arba visa sistema suges.
Įsivaizduokime scenarijų, kai jūsų įrenginiui pritrūksta atminties – kaip „Kubernetes“ elgtųsi su tuo?
„Kubernetes“ ieškos rinkinių, naudojančių daugiau išteklių, nei prašė. Taigi, jei jūsų konteineriuose iš viso nėra užklausų, tai reiškia, kad jie pagal nutylėjimą naudoja daugiau, nei prašė, tiesiog todėl, kad iš viso nieko neprašė! Tokie konteineriai tampa pagrindiniais kandidatais išjungti. Kiti kandidatai yra konteineriai, kurie patenkino visus jų prašymus, bet vis dar nesiekia didžiausios ribos.
Taigi, jei „Kubernetes“ aptiks keletą grupių, kurios viršijo užklausų parametrus, ji surūšiuos juos pagal prioritetą ir pašalins žemiausio prioriteto rinkinius. Jei visos grupės turi tą patį prioritetą, „Kubernetes“ nutrauks tuos, kurie viršija jų užklausas daugiau nei kiti ankštys.
Labai retais atvejais Kubernetes gali nutraukti ankštis, kurios vis dar patenka į jų užklausų sritį. Taip gali nutikti, kai svarbūs sistemos komponentai, tokie kaip „Kubelet“ agentas arba „Docker“, pradeda vartoti daugiau išteklių, nei jiems buvo skirta.
Taigi ankstyvosiose mažų įmonių stadijose „Kubernetes“ klasteris gali gerai veikti nenustatant išteklių užklausų ir apribojimų, tačiau kai jūsų komandos ir projektai pradeda augti, rizikuojate susidurti su problemomis šioje srityje. Užklausų ir apribojimų įtraukimas į savo modulius ir vardų sritis reikalauja labai mažai papildomų pastangų ir gali sutaupyti daug rūpesčių.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com