Fyrir hverja Kubernetes tilföng er hægt að stilla tvenns konar kröfur - beiðnir og takmörk. Sú fyrri lýsir lágmarkskröfum um aðgengi að ókeypis hnútaauðlindum sem nauðsynlegar eru til að keyra gám eða belg, seinni takmarkar stranglega tilföng sem eru tiltæk fyrir gáminn.
Þegar Kubernetes tímasetur belg er mjög mikilvægt að ílátin hafi nægt fjármagn til að virka rétt. Ef þú ætlar að dreifa stóru forriti á hnút með takmarkaðan auðlind, er mögulegt að það gangi ekki vegna þess að hnúturinn er að klárast á minni eða klárast af örgjörvaafli. Í þessari grein munum við skoða hvernig þú getur leyst skort á tölvuorku með því að nota auðlindabeiðnir og takmarkanir.
Beiðnir og takmörk eru kerfi sem Kubernetes notar til að stjórna auðlindum eins og CPU og minni. Beiðnir eru það sem tryggja að ílátið fái umbeðna tilföng. Ef gámur biður um tilföng mun Kubernetes aðeins tímasetja það á hnút sem getur veitt það. Takmarkar stjórn á því að tilföngin sem gámurinn biður um fari aldrei yfir ákveðið gildi.
Gámur getur aðeins aukið tölvukraft sinn upp að ákveðnum mörkum, eftir það verður hann takmarkaður. Við skulum sjá hvernig það virkar. Svo, það eru tvær tegundir af auðlindum - örgjörvi og minni. Kubernetes tímaáætlunin notar gögn um þessi úrræði til að komast að því hvar á að keyra belgina þína. Dæmigerð auðlindaforskrift fyrir belg lítur svona út.
Hvert ílát í belg getur stillt sínar eigin fyrirspurnir og takmörk, það er allt aukið. Örgjörvaauðlindir eru skilgreindar í millikjarna. Ef ílátið þitt þarf tvo heila kjarna til að keyra, stillirðu gildið á 2000m. Ef ílátið þarf aðeins afl 1/4 af kjarnanum verður gildið 250m. Hafðu í huga að ef þú úthlutar örgjörvaforðagildi sem er stærra en kjarnafjölda stærsta hnútsins, mun belgurinn þinn alls ekki vera áætlaður til að byrja. Svipað ástand mun eiga sér stað ef þú ert með Pod sem þarf fjóra kjarna og Kubernetes þyrpingin samanstendur af aðeins tveimur helstu sýndarvélum.
Nema forritið þitt sé sérstaklega hannað til að nýta marga kjarna (forrit eins og flókin vísindatölvufræði og gagnagrunnsaðgerðir koma upp í hugann), þá er besta aðferðin að stilla CPU beiðnir á 1 eða lægri og keyra síðan fleiri eftirlíkingar til að sveigjanleika. Þessi lausn mun veita kerfinu meiri sveigjanleika og áreiðanleika.
Þegar kemur að örgjörvatakmörkunum verða hlutirnir áhugaverðari þar sem það er talið samþjappanleg auðlind. Ef forritið þitt fer að nálgast aflmörk örgjörva mun Kubernetes byrja að hægja á ílátinu þínu með því að nota CPU Throttling - sem dregur úr tíðni örgjörva. Þetta þýðir að örgjörvinn verður tilbúinn tilbúinn, sem gefur forritinu hugsanlega verri afköst, en ferlið verður ekki hætt eða tekið út.
Minnisauðlindir eru skilgreindar í bætum. Venjulega er gildið í stillingunum mælt í mebibytes Mib, en þú getur stillt hvaða gildi sem er, allt frá bætum til petabæta. Sama staða á við hér og með örgjörvann - ef þú leggur fram beiðni um meira minnismagn en minnismagnið á hnútunum þínum, þá verður ekki áætlað að keyra þann pod. En ólíkt CPU auðlindum er minni ekki þjappað því það er engin leið til að takmarka notkun þess. Því verður framkvæmd gámsins stöðvuð um leið og hún fer út fyrir minni sem honum er úthlutað.
Það er mikilvægt að muna að þú getur ekki stillt beiðnir sem fara yfir það fjármagn sem hnútarnir þínir geta veitt. Forskriftir um sameiginlega auðlind fyrir GKE sýndarvélar er að finna í tenglum fyrir neðan þetta myndband.
Í ákjósanlegum heimi myndu sjálfgefnar stillingar ílátsins nægja til að halda verkflæðinu gangandi. En raunheimurinn er ekki þannig, fólk getur auðveldlega gleymt að stilla notkun auðlinda, eða tölvuþrjótar setja beiðnir og takmarkanir sem fara yfir raunverulegan getu innviðanna. Til að koma í veg fyrir að slíkar aðstæður eigi sér stað er hægt að stilla tilfangakvóta ResourceQuota og LimitRange.
Þegar nafnrými hefur verið búið til er hægt að loka því með kvóta. Til dæmis, ef þú ert með vöru- og þróunarnafnarýmin, þá er mynsturið að það eru engir framleiðslukvótar og mjög strangir þróunarkvótar. Þetta gerir framleiðslugetu kleift, ef um er að ræða mikla aukningu í umferð, að taka yfir alla tiltæka auðlindina, sem lokar algjörlega þróun.
Auðlindakvótinn gæti litið svona út. Í þessu dæmi eru 4 hlutar - þetta eru 4 neðstu línurnar í kóðanum.
Við skulum líta á hvert þeirra. Requests.cpu er hámarksfjöldi samsettra örgjörvabeiðna sem geta komið frá öllum gámum í nafnrýminu. Í þessu dæmi gætirðu haft 50 gáma með 10m beiðnum, fimm gáma með 100m beiðnum, eða bara einn gám með 500m beiðnum. Svo lengi sem heildarfjöldi requests.cpu tiltekins nafnrýmis er innan við 500m, mun allt vera í lagi.
Memory requests.memory er hámarksmagn samsettra minnisbeiðna sem allir gámar í nafnarýminu geta haft. Eins og í fyrra tilvikinu geturðu haft 50 2 mib gáma, fimm 20 mib gáma eða einn 100 mib gáma svo framarlega sem heildarmagn minnis sem óskað er eftir í nafnrýminu er minna en 100 mebibæti.
Limits.cpu er hámarks samsetta magn örgjörvaafls sem allir gámar í nafnrýminu geta notað. Við getum litið á þetta sem takmörk beiðna um örgjörvaafl.
Að lokum er limits.memory hámarksmagn samnýtts minnis sem allir gámar í nafnrýminu geta notað. Þetta er takmörkun á heildar minnisbeiðnum.
Þannig að sjálfgefið er að gámar í Kubernetes klasa keyra með ótakmörkuðum tölvuauðlindum. Með auðlindakvóta geta klasastjórnendur takmarkað auðlindanotkun og auðlindasköpun byggt á nafnrými. Í nafnarými getur hólf eða gámur neytt eins mikils örgjörvaafls og minni og ákvarðast af heimildakvóta nafnrýmisins. Hins vegar eru áhyggjur af því að einn belg eða ílát geti einokað allar tiltækar auðlindir. Til að koma í veg fyrir þetta ástand er takmarkað svið notað - stefna til að takmarka úthlutun auðlinda (fyrir belg eða ílát) í nafnrýminu.
Takmarkasviðið veitir takmarkanir sem geta:
- Tryggja lágmarks- og hámarksnotkun á tölvuauðlindum fyrir hverja einingu eða ílát í nafnrýminu;
- framfylgja lágmarks- og hámarksgeymslubeiðnum fyrir Starage Request fyrir hvert PersistentVolumeClaim í nafnarýminu;
- framfylgja tengslum milli beiðni og takmörkunar fyrir tilföng í nafnrými;
- stilltu sjálfgefnar beiðnir/takmörk fyrir tölvuauðlindir í nafnrýminu og dældu þeim sjálfkrafa inn í gáma á keyrslutíma.
Þannig geturðu búið til takmörkunarsvið í nafnarýminu þínu. Ólíkt kvóta, sem gildir fyrir allt nafnrýmið, er Limit Range notað fyrir einstaka gáma. Þetta getur komið í veg fyrir að notendur búi til mjög örsmáa eða öfugt risastóra ílát innan nafnrýmisins. Limit Range gæti litið svona út.
Eins og í fyrra tilvikinu má greina hér 4 kafla. Við skulum líta á hvern og einn.
Sjálfgefinn hlutinn setur sjálfgefin mörk fyrir ílátið í belgnum. Ef þú stillir þessi gildi á öfgasviðið, þá munu allir gámar sem þessi gildi hafa ekki verið sérstaklega stillt fyrir fylgja sjálfgefna gildunum.
Sjálfgefin beiðnihluti defaultRequest stillir sjálfgefnar beiðnir fyrir ílátið í hólfinu. Aftur, ef þú stillir þessi gildi á öfgasviðið, þá munu allir gámar sem ekki stilla þessa valkosti beinlínis hafa þessi gildi.
Hámarkshlutinn tilgreinir hámarksmörk sem hægt er að setja fyrir ílát í belgnum. Ekki er hægt að setja gildi í sjálfgefnum hluta og gámamörkum yfir þessum mörkum. Það er mikilvægt að hafa í huga að ef gildið er stillt á max og það er enginn sjálfgefinn hluti, þá verður hámarksgildið sjálfgefið gildi.
Lágmarkshlutinn tilgreinir lágmarksbeiðnir sem hægt er að stilla fyrir ílát í belg. Hins vegar er ekki hægt að stilla gildin í sjálfgefna hlutanum og fyrirspurnum fyrir ílátið undir þessum mörkum.
Aftur, það er mikilvægt að hafa í huga að ef þetta gildi er stillt, er sjálfgefið það ekki, þá verður lágmarksgildið sjálfgefið hvetja.
Þessar auðlindabeiðnir eru að lokum notaðar af Kubernetes tímaáætlun til að framkvæma vinnuálag þitt. Til þess að þú getir stillt ílátin þín rétt er mjög mikilvægt að skilja hvernig það virkar. Segjum að þú viljir keyra marga belg í þyrpingunni þinni. Að því gefnu að belgforskriftirnar séu gildar mun Kubernetes áætlunin nota hringlaga jafnvægi til að velja hnút til að keyra vinnuálagið.
Kubernetes mun athuga hvort hnútur 1 hafi nægt fjármagn til að uppfylla beiðnir frá belgílátunum og ef svo er ekki mun það halda áfram á næsta hnút. Ef enginn af hnútunum í kerfinu er fær um að fullnægja beiðnum, fara belgirnir í biðstöðu. Með því að nota Google Kubernetes vélareiginleika eins og sjálfvirka hnútaskala getur GKE sjálfkrafa greint biðstöðu og búið til nokkra hnúta til viðbótar.
Ef þú verður uppiskroppa með hnútarýmið mun sjálfvirk stærð hnúta minnka fjölda hnúta til að spara þér peninga. Þetta er ástæðan fyrir því að Kubernetes skipuleggur belg byggt á beiðnum. Hins vegar geta mörkin verið hærri en beiðnirnar og í sumum tilfellum gæti hnúturinn í raun orðið uppiskroppa með fjármagn. Við köllum þetta ríki ofskuldbindingarríki.
Eins og ég sagði, þegar kemur að CPU, mun Kubernetes byrja að takmarka belg. Hver belg mun fá eins mikið og hann bað um, en ef hann nær ekki mörkunum mun inngjöf byrja að gilda.
Þegar kemur að minnisauðlindum neyðist Kubernetes til að taka ákvarðanir um hvaða belg á að eyða og hverjum á að geyma þar til þú losar um kerfisauðlindir eða allt kerfið mun hrynja.
Við skulum ímynda okkur atburðarás þar sem þú ert með vél að verða uppiskroppa með minni - hvernig myndi Kubernetes höndla það?
Kubernetes mun leita að belgjum sem nota meira fjármagn en þeir báðu um. Þannig að ef gámarnir þínir hafa alls engar beiðnir, þýðir það að þeir eru sjálfgefnir að nota meira en þeir báðu um, einfaldlega vegna þess að þeir báðu alls ekki um neitt! Slíkir gámar verða helsti kandídatar fyrir lokun. Næstu umsækjendur eru gámar sem hafa uppfyllt allar óskir þeirra en eru enn undir hámarksmörkum.
Þannig að ef Kubernetes finnur nokkra belg sem hafa farið fram úr beiðnarbreytum þeirra mun það raða þeim eftir forgangi og fjarlægja þá lægsta forgangsbelg. Ef allir belg hafa sama forgang, þá mun Kubernetes hætta þeim belgjum sem hafa farið fram úr beiðnum þeirra meira en önnur belg.
Í mjög sjaldgæfum tilfellum getur Kubernetes hætt við fræbelg sem eru enn innan umfangs beiðna þeirra. Þetta getur gerst þegar mikilvægir kerfishlutar eins og Kubelet umboðsmaðurinn eða Docker byrja að neyta meira fjármagns en það sem var frátekið fyrir þá.
Svo, á fyrstu stigum lítilla fyrirtækja, getur Kubernetes þyrping virkað vel án þess að setja tilföngsbeiðnir og takmarkanir, en þegar teymi þín og verkefni byrja að stækka að stærð, átt þú á hættu að lenda í vandræðum á þessu sviði. Að bæta fyrirspurnum og takmörkunum við einingarnar þínar og nafnarýmin krefst mjög lítillar fyrirhafnar og getur sparað mikið vesen.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com