Vir elke Kubernetes-hulpbron is dit moontlik om twee tipes vereistes op te stel - Versoeke en Limiete. Die eerste beskryf die minimum vereistes vir gratis nodushulpbronne wat nodig is om 'n houer of peul te bestuur, die tweede beperk die hulpbronne wat tot die houer beskikbaar is, ernstig.
Wanneer Kubernetes peule beplan, is dit baie belangrik dat die houers genoeg hulpbronne het om normaal te werk. As jy van plan is om 'n groot toepassing na 'n gasheer met beperkte hulpbronne te ontplooi, is dit moontlik dat dit nie sal loop nie omdat die gasheer se geheue opraak of met verwerkerkrag opraak. In hierdie artikel sal ons kyk hoe u die probleme van 'n gebrek aan rekenaarkrag kan oplos deur hulpbronversoeke en -limiete te gebruik.
Versoeke en limiete is meganismes wat Kubernetes gebruik om hulpbronne soos SVE en geheue te bestuur. Versoeke is wat seker maak dat die houer die gevraagde hulpbron kry. As 'n houer 'n hulpbron versoek, sal Kubernetes dit slegs skeduleer op 'n nodus wat dit kan verskaf. Beperk beheer dat die hulpbronne wat deur die houer versoek word, nooit 'n sekere waarde oorskry nie.
Die houer kan rekenaarkrag net tot 'n sekere limiet laat groei, waarna dit beperk sal word. Kom ons kyk hoe dit werk. Dus, daar is twee tipes hulpbronne - verwerker en geheue. Die Kubernetes skeduleerder gebruik hierdie hulpbronne om uit te vind waar om jou peule te laat loop. 'n Tipiese hulpbronspesifikasie vir 'n peul lyk so.
Elke houer in 'n peul kan sy eie versoeke en limiete stel, dit is alles toevoeging. Verwerkerhulpbronne word in millicores gedefinieer. As jou houer twee volle kerne nodig het om te loop, stel jy die waarde op 2000m. As die houer slegs 1/4 kernkrag benodig, sal die waarde 250m wees. Wees bewus daarvan dat as jy 'n SVE-hulpbronwaarde groter as die aantal kerne van die grootste nodus toewys, jou peul glad nie geskeduleer sal wees om te begin nie. 'n Soortgelyke situasie sal voorkom as jy 'n peul het wat vier kerns benodig, en die Kubernetes-kluster bestaan uit slegs twee hoof virtuele masjiene.
Tensy jou toepassing spesifiek ontwerp is om voordeel te trek uit veelvuldige kerns (dus kom programme soos komplekse wetenskaplike berekeninge en databasisbewerkings in gedagte), dan is die beste praktyk om SVE-versoeke op 1 of laer te stel en dan meer replikas na skaalbaarheid uit te voer. Hierdie oplossing sal die stelsel groter buigsaamheid en betroubaarheid gee.
As dit by SVE-beperkings kom, word dinge interessanter aangesien dit as 'n saamdrukbare hulpbron beskou word. As jou toepassing die SVE-limiet begin nader, sal Kubernetes jou houer met SVE-versnelling begin versmoor. Dit beteken dat die verwerker kunsmatig beperk sal word, wat die toepassing moontlik swakker werkverrigting gee, maar die proses sal nie beëindig of gelewer word nie.
Geheuehulpbronne word in grepe gedefinieer. Gewoonlik word die waarde in die instellings gemeet in Mib mebigrepe, maar jy kan dit op enige waarde stel, van grepe tot petagrepe. Die situasie hier is dieselfde as met die SVE - as jy 'n versoek plaas vir 'n hoeveelheid geheue wat die hoeveelheid geheue op jou nodusse oorskry, sal die uitvoering van hierdie peul nie geskeduleer word nie. Maar anders as SVE-hulpbronne, word geheue nie saamgepers nie, want daar is geen manier om die gebruik daarvan te beperk nie. Daarom sal die uitvoering van die houer gestop word sodra die geheue wat daaraan toegeken is, opraak.
Dit is belangrik om te onthou dat jy nie versoeke kan opstel wat die hoeveelheid hulpbronne wat jou nodusse kan verskaf, oorskry nie. Deelspesifikasies vir GKE VM's kan gevind word in die skakels onder hierdie video.
In 'n ideale wêreld sal die verstekhouerinstellings genoeg wees om werkvloei glad te laat verloop. Maar die werklike wêreld is nie so nie, mense kan maklik vergeet om hulpbrongebruik aan te pas, of kuberkrakers sal versoeke en limiete stel wat die werklike vermoëns van die infrastruktuur oorskry. Om sulke scenario's te voorkom, kan jy ResourceQuota-hulpbronkwotas en LimitRange-reekse opstel.
Sodra 'n naamspasie geskep is, kan hulle gesluit word deur kwotas te gebruik. As jy byvoorbeeld die prod- en dev-naamruimtes het, is die patroon dat daar glad nie produksiekwotas is nie, en ontwikkelingskwotas is baie streng. Dit laat prod toe om al die beskikbare hulpbron te neem in die geval van 'n skerp toename in verkeer, wat dev heeltemal blokkeer.
'n Hulpbronkwota kan so lyk. In hierdie voorbeeld is daar 4 afdelings - dit is die 4 onderste reëls van kode.
Kom ons kyk na elkeen van hulle. Requests.cpu is die maksimum aantal gekombineerde versoeke vir SVE-krag wat van alle naamruimtehouers kan kom. In hierdie voorbeeld kan jy 50 houers met 10m versoeke hê, vyf houers met 100m versoeke, of net een houer met 500m versoeke. Solank as wat die totale aantal requests.cpu van 'n gegewe naamruimte minder as 500m is, sal alles reg wees.
Gevrade geheue versoeke.geheue is die maksimum hoeveelheid gekombineerde geheue versoeke wat alle houers in die naamruimte kan hê. Soos in die vorige geval, kan jy 50 2 mib-houers, vyf 20 mib-houers, of 'n enkele 100 mib-houer hê, solank die totale hoeveelheid geheue wat in die naamruimte versoek word, minder as 100 mebigrepe is.
Limits.cpu is die maksimum gekombineerde hoeveelheid verwerkerkrag wat alle naamruimtehouers kan gebruik. Ons kan aanvaar dat dit die limiet van verwerkerkragversoeke is.
Ten slotte, limits.memory is die maksimum hoeveelheid gedeelde geheue wat alle houers in die naamruimte kan gebruik. Dit is die limiet op totale geheueversoeke.
Dus, houers in 'n Kubernetes-kluster loop by verstek met onbeperkte rekenaarhulpbronne. Met hulpbronkwotas kan groepadministrateurs hulpbronverbruik en hulpbronskepping beperk op grond van die naamruimte. In 'n naamruimte kan 'n peul of houer soveel SVE en geheuekrag verbruik soos gedefinieer deur die naamruimtehulpbronkwota. Daar is egter kommer dat een peul of houer alle beskikbare hulpbronne kan monopoliseer. Om hierdie situasie te voorkom, word die limiet Range gebruik - die beleid om die toewysing van hulpbronne (vir peule of houers) in die naamruimte te beperk.
Die limietreeks bied limiete wat kan:
- verseker die minimum en maksimum gebruik van rekenaarhulpbronne vir elke module of houer in die naamruimte;
- 'n minimum en maksimum Starage-versoek afdwing vir elke PersistentVolumeClaim in die naamruimte;
- 'n verhouding tussen 'n Versoek en 'n Limiet vir 'n hulpbron in 'n naamruimte afdwing;
- stel verstekversoeke/limiete vir rekenaarhulpbronne in die naamruimte en spuit dit outomaties in houers tydens looptyd.
U kan dus 'n limietreeks in u naamruimte skep. Anders as die kwota, wat op die hele naamruimte van toepassing is, word die Limietreeks vir individuele houers gebruik. Dit kan gebruikers verhoed om klein of reusagtige houers binne 'n naamruimte te skep. Die Limiet Range kan dalk so lyk.
Soos in die vorige geval, kan 4 afdelings hier onderskei word. Kom ons kyk na elkeen.
Die verstekafdeling stel die verstekbeperkings vir die houer in die peul. As jy hierdie waardes in die uiterste reeks stel, sal enige houers waarvoor hierdie waardes nie uitdruklik gestel is nie, die verstekwaardes volg.
In die verstekversoek-afdeling word verstekversoeke vir die houer in die peul gekonfigureer. Weereens, as u hierdie waardes tot die uiterste reeks stel, sal enige houers waarvoor hierdie parameters nie eksplisiet gestel is nie, hierdie waardes by verstek gebruik.
Die maksimum afdeling spesifiseer die maksimum limiete wat gestel kan word vir 'n houer in 'n Pod. Waardes in die verstekafdeling en houerlimiete kan nie bo hierdie limiet gestel word nie. Dit is belangrik om daarop te let dat as maksimum gestel is en daar geen verstekafdeling is nie, die maksimum waarde die verstekwaarde word.
Die min afdeling spesifiseer die minimum versoeke wat vir 'n houer in 'n peul gestel kan word. Waardes in die verstekafdeling en versoeke vir 'n houer kan egter nie onder hierdie limiet gestel word nie.
Weereens, dit is belangrik om daarop te let dat as hierdie waarde gestel is en verstek nie, die minimum waarde die versteknavraag word.
Uiteindelik word hierdie hulpbronversoeke deur die Kubernetes-skeduleerder gebruik om u werkladings uit te voer. Om jou houers behoorlik op te stel, is dit baie belangrik om te verstaan hoe dit werk. Kom ons sê jy wil veelvuldige peule op jou cluster laat loop. Met die veronderstelling dat die peulspesifikasies geldig is, sal die Kubernetes-skedule round robin gebruik om die nodus te kies om die werklading uit te voer.
Kubernetes sal kyk of Node 1 genoeg hulpbronne het om aan die versoeke van die peulhouers te voldoen, en indien nie, sal dit aanbeweeg na die volgende node. As nie een van die nodusse in die stelsel aan die versoeke kan voldoen nie, sal die peule in die hangende toestand gaan. Met behulp van kenmerke van die Google Kubernetes-enjin soos node-outoskaal, kan GKE outomaties die hangende toestand opspoor en nog 'n paar bykomende nodusse skep.
As daar later 'n oorkapasiteit van nodusse is, sal outoskaal die aantal nodusse verminder om jou geld te bespaar. Dit is hoekom Kubernetes Pods skeduleer op grond van versoeke. Die limiet kan egter hoër wees as versoeke, en in sommige gevalle kan die gasheer eintlik nie meer hulpbronne hê nie. Ons noem hierdie toestand die oorverbintenisstaat.
Soos ek gesê het, as dit by SVE kom, sal Kubernetes Pods begin beperk. Elke peul sal soveel ontvang as waarvoor dit gevra het, maar as dit nie die limiet bereik nie, sal verswakking begin geld.
Wat geheuebronne betref, hier moet Kubernetes besluite neem oor watter peule om uit te vee en watter om te hou totdat jy stelselhulpbronne vrystel, anders sal die hele stelsel in duie stort.
Kom ons stel ons 'n scenario voor waar 'n masjien se geheue opraak - hoe sal Kubernetes dit hanteer?
Kubernetes sal soek na peule wat meer hulpbronne gebruik as wat versoek is. So as jou houers glad nie Versoeke het nie, beteken dit dat hulle by verstek meer gebruik as waarvoor hulle gevra het, bloot omdat hulle vir niks gevra het nie! Sulke houers word die belangrikste kandidate vir sluiting. Die volgende kandidate is houers wat aan al hul versoeke voldoen het, maar steeds onder die maksimum limiet is.
As Kubernetes dus 'n paar peule vind wat hul versoekparameters oorskry het, sal dit hulle volgens prioriteit sorteer en dan die peule met die laagste prioriteit verwyder. As alle peule dieselfde prioriteit het, sal Kubernetes daardie peule afskakel wat hul versoeke met meer as die res van die peule oorskry het.
In baie seldsame gevalle kan Kubernetes Pods beëindig wat steeds binne hul versoeke is. Dit kan gebeur wanneer kritieke stelselkomponente soos die Kubelet-agent of Docker meer hulpbronne begin verbruik as wat vir hulle gereserveer is.
Dus, in die vroeë stadiums van klein besighede, kan 'n Kubernetes-kluster goed werk sonder om hulpbronversoeke en -limiete te stel, maar namate jou spanne en projekte in grootte begin groei, loop jy die risiko om probleme op hierdie gebied te ondervind. Om navrae en beperkings by jou modules en naamruimtes by te voeg, verg baie min ekstra moeite en kan jou baie moeite bespaar.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com