Foar elke Kubernetes-boarne kinne jo twa soarten easken konfigurearje - Fersiken en Limits. De earste beskriuwt de minimale easken foar de beskikberens fan frije node-boarnen dy't nedich binne om in kontener of pod út te fieren, de twadde beheint de beskikbere boarnen foar de kontener strikt.
As Kubernetes pods plannen, is it heul wichtich dat de konteners genôch boarnen hawwe om goed te funksjonearjen. As jo it plannen fan in ynsette in grutte applikaasje op in boarne-beheinde knooppunt, it is mooglik dat it sil net rinne omdat de knooppunt rint leech op ûnthâld of rint út CPU macht. Yn dit artikel sille wy sjen nei hoe't jo tekoarten oan komputerkrêft kinne oplosse mei helpboarneoanfragen en grinzen.
Fersiken en limiten binne meganismen dy't Kubernetes brûkt om boarnen lykas CPU en ûnthâld te behearjen. Fersiken binne wat soargje dat de kontener de frege boarne ûntfangt. As in kontener in boarne freget, sil Kubernetes it allinich planne op in knooppunt dat it kin leverje. Beheint kontrôle dat de boarnen dy't troch de kontener oanfrege binne, noait in bepaalde wearde sille oerskriuwe.
In kontener kin syn rekkenkrêft allinich ferheegje oant in bepaalde limyt, wêrnei't it beheind wurdt. Litte wy sjen hoe't it wurket. Dat, d'r binne twa soarten boarnen - prosessor en ûnthâld. De Kubernetes-planner brûkt gegevens oer dizze boarnen om út te finen wêr't jo jo pods útfiere. In typyske boarne spesifikaasje foar in pod sjocht der sa út.
Elke kontener yn in pod kin syn eigen fragen en grinzen ynstelle, it is allegear additief. Prosessorboarnen wurde definieare yn millicores. As jo kontener twa folsleine kearnen nedich hat om te rinnen, sette jo de wearde op 2000m. As de kontener allinich de krêft fan 1/4 fan 'e kearn nedich is, sil de wearde 250m wêze. Hâld der rekken mei dat as jo in CPU-boarnewearde tawize dy't grutter is as it oantal kearnen fan 'e grutste knooppunt, sil jo pod hielendal net pland wêze om te begjinnen. In ferlykbere situaasje sil foarkomme as jo in Pod hawwe dy't fjouwer kearnen nedich is, en it Kubernetes-kluster bestiet út mar twa wichtichste firtuele masines.
Behalven as jo applikaasje spesifyk is ûntworpen om foardiel te meitsjen fan meardere kearnen (programma's lykas komplekse wittenskiplike komputer en databankoperaasjes komme yn 't sin), dan is de bêste praktyk om CPU-oanfragen op 1 of leger yn te stellen en dan mear replika's út te fieren nei skalberens. Dizze oplossing sil it systeem mear fleksibiliteit en betrouberens jaan.
As it giet om CPU-beheiningen, wurde dingen nijsgjirriger, om't it wurdt beskôge as in komprimerbere boarne. As jo applikaasje de limyt foar prosessorkrêft begjint te benaderjen, sil Kubernetes jo kontener begjinne te fertragen mei CPU Throttling - it ferminderjen fan de prosessorfrekwinsje. Dit betsjut dat de CPU keunstmjittich fersmoarge wurdt, wêrtroch't de applikaasje potinsjeel slimmer prestaasje jout, mar it proses sil net wurde beëinige of fuortsmiten.
Unthâld boarnen wurde definiearre yn bytes. Normaal wurdt de wearde yn 'e ynstellings mjitten yn mebibytes Mib, mar jo kinne elke wearde ynstelle, fan bytes oant petabytes. Deselde situaasje jildt hjir as mei de CPU - as jo in fersyk pleatse foar in hoemannichte ûnthâld grutter dan it bedrach fan ûnthâld op jo knopen, sil dy pod net wurde pland om út te fieren. Mar oars as CPU-boarnen, wurdt ûnthâld net komprimearre, om't d'r gjin manier is om it gebrûk te beheinen. Dêrom wurdt de útfiering fan 'e kontener stopset sa gau't it fierder giet as it dêroan tawiisde ûnthâld.
It is wichtich om te betinken dat jo oanfragen net kinne konfigurearje dy't de boarnen dy't jo knooppunten kinne leverje, oertreffe. Dielde boarne spesifikaasjes foar GKE firtuele masines kinne fûn wurde yn 'e keppelings ûnder dizze fideo.
Yn in ideale wrâld soene de standertynstellingen fan 'e kontener genôch wêze om workflows soepel te hâlden. Mar de echte wrâld is net sa, minsken kinne maklik ferjitte om it gebrûk fan boarnen te konfigurearjen, of hackers sille oanfragen en beheiningen ynstelle dy't de echte mooglikheden fan 'e ynfrastruktuer oertreffe. Om foar te kommen dat sokke senario's foarkomme, kinne jo ResourceQuota en LimitRange boarnekwota's ynstelle.
Sadree't in nammeromte is oanmakke, kin it blokkearre wurde mei help fan kwotas. As jo bygelyks de prod- en dev-nammeromten hawwe, is it patroan dat d'r hielendal gjin produksjekwota binne en heul strikte ûntwikkelingskwota's. Dit lit prod, yn it gefal fan in skerpe tanimming yn ferkear, de folsleine beskikbere boarne oernimme, folslein blokkearje dev.
De boarne kwota kin der sa útsjen. Yn dit foarbyld binne d'r 4 seksjes - dit binne de 4 ûnderste rigels fan koade.
Litte wy nei elk fan har sjen. Requests.cpu is it maksimum oantal kombinearre CPU fersiken dat kin komme út alle konteners yn de nammeromte. Yn dit foarbyld kinne jo 50 konteners hawwe mei 10m oanfragen, fiif konteners mei 100m oanfragen, of gewoan ien kontener mei 500m oanfragen. Salang't it totale oantal requests.cpu fan in opjûne nammeromte minder is as 500m, sil alles goed wêze.
Unthâld frege requests.memory is it maksimum oantal kombinearre ûnthâld fersiken dat alle konteners yn de nammeromte kinne hawwe. Lykas yn it foarige gefal, kinne jo hawwe 50 2 mib containers, fiif 20 mib containers, of in inkele 100 mib container sa lang as it totale bedrach fan ûnthâld frege yn de nammeromte is minder as 100 mebibytes.
Limits.cpu is de maksimale kombinearre hoemannichte CPU-krêft dat alle konteners yn 'e nammeromte brûke kinne. Wy kinne dit beskôgje as de limyt fan oanfragen foar prosessorkrêft.
Ta beslút, limits.memory is it maksimale bedrach fan dielde ûnthâld dat alle konteners yn de nammeromte kinne brûke. Dit is in limyt op totale ûnthâld fersiken.
Dat, standert, konteners yn in Kubernetes-kluster rinne mei ûnbeheinde berekkeningsboarnen. Mei boarnekwota's kinne klusterbehearders boarneferbrûk en oanmeitsjen fan boarnen beheine op basis fan nammeromte. Yn in nammeromte kin in pod of kontener safolle CPU-krêft en ûnthâld ferbrûke as bepaald troch it kwota foar boarnen foar nammeromte. D'r is lykwols in soarch dat ien pod of kontener alle beskikbere boarnen kin monopolisearje. Om dizze situaasje foar te kommen, wurdt in limytberik brûkt - in belied foar it beheinen fan de allocaasje fan boarnen (foar pods of konteners) yn 'e nammeromte.
It limytberik jout beheiningen dy't kinne:
- Soargje foar minimaal en maksimum gebrûk fan komputerboarnen foar elke module of kontener yn 'e nammeromte;
- hanthavenje minimum en maksimum Starage Request opslach fersiken foar eltse PersistentVolumeClaim yn de nammeromte;
- hanthavenje in relaasje tusken in fersyk en in limyt foar in boarne yn in nammeromte;
- set standert Fersiken / Limits foar berekkeningsboarnen yn 'e nammeromte en ynjeksje se automatysk yn konteners by runtime.
Op dizze manier kinne jo in limyt berik meitsje yn jo nammeromte. Oars as in kwota, dat jildt foar de hiele nammeromte, wurdt Limit Range brûkt foar yndividuele konteners. Dit kin foarkomme dat brûkers heul lytse of, oarsom, gigantyske konteners meitsje binnen de nammeromte. De Limit Range kin der sa útsjen.
Lykas yn it foarige gefal kinne hjir 4 seksjes ûnderskiede wurde. Litte wy nei elk sjen.
De standert seksje stelt de standertgrinzen yn foar de kontener yn 'e pod. As jo dizze wearden ynstelle op it ekstreme berik, dan sille alle konteners wêrfoar dizze wearden net eksplisyt binne ynsteld de standertwearden folgje.
De standert fersykseksje defaultRequest konfigurearret de standertoanfragen foar de kontener yn 'e pod. Nochris, as jo dizze wearden ynstelle op it ekstreme berik, dan sille alle konteners dy't dizze opsjes net eksplisyt ynstelle, standert wurde op dizze wearden.
De max seksje spesifisearret de maksimale grinzen dy't kinne wurde ynsteld foar in kontener yn 'e pod. Wearden yn 'e standert seksje en kontenergrinzen kinne net boppe dizze limyt ynsteld wurde. It is wichtich om te notearjen dat as de wearde is ynsteld op max en der is gjin standert seksje, dan wurdt de maksimale wearde de standertwearde.
De min seksje spesifisearret de minimale oanfragen dy't ynsteld wurde kinne foar in kontener yn in pod. De wearden yn 'e standertseksje en fragen foar de kontener kinne lykwols net ûnder dizze limyt ynsteld wurde.
Nochris is it wichtich om te notearjen dat as dizze wearde ynsteld is, standert is net, dan wurdt de minimale wearde de standert prompt.
Dizze boarne-oanfragen wurde úteinlik brûkt troch de Kubernetes-planner om jo workloads út te fieren. Om jo konteners goed te konfigurearjen, is it heul wichtich om te begripen hoe't it wurket. Litte wy sizze dat jo meardere pods yn jo kluster útfiere wolle. Oannommen dat de pod-spesifikaasjes jildich binne, sil it Kubernetes-skema round robin-balancing brûke om in knooppunt te selektearjen om de wurkdruk út te fieren.
Kubernetes sil kontrolearje oft Node 1 genôch boarnen hat om oanfragen fan 'e podcontainers te ferfoljen, en as it net docht, sil it trochgean nei it folgjende knooppunt. As gjin fan 'e knooppunten yn it systeem by steat is om te foldwaan oan de fersiken, de pods sille gean yn de Pending steat. Mei help fan Google Kubernetes-motorfunksjes lykas node autoscaling, kin GKE de wachtstatus automatysk detektearje en ferskate ekstra knooppunten oanmeitsje.
As jo nei knooppuntkapasiteit hawwe, sil autoskaal it oantal knooppunten ferminderje om jo jild te besparjen. Dit is de reden dat Kubernetes pods plant basearre op oanfragen. De limyt kin lykwols heger wêze as de oanfragen, en yn guon gefallen kin it knooppunt eins gjin boarnen hawwe. Wy neame dizze steat overcommitment steat.
As ik sei, as it giet om CPU, sil Kubernetes de pods begjinne te beheinen. Elke pod sil safolle ûntfange as it freget, mar as it de limyt net berikt, sil throttling begjinne te jilde.
As it giet om ûnthâldboarnen, wurdt Kubernetes twongen om besluten te nimmen oer hokker pods te wiskjen en hokker te hâlden oant jo systeemboarnen frijmeitsje as it heule systeem crasht.
Litte wy ús in senario foarstelle wêr't jo in masine sûnder ûnthâld hawwe - hoe soe Kubernetes dat behannelje?
Kubernetes sil sykje nei pods dy't mear boarnen brûke dan se fregen. Dus as jo konteners hielendal gjin oanfragen hawwe, betsjut dat dat se standert binne om mear te brûken dan se fregen, gewoan om't se hielendal neat hawwe frege! Sokke konteners wurde prime kandidaten foar shutdown. De folgjende kandidaten binne konteners dy't al har oanfragen foldien hawwe, mar noch ûnder de maksimale limyt binne.
Dus as Kubernetes ferskate pods fynt dy't har oanfraachparameters hawwe oertroffen, sil it se sortearje op prioriteit en dan de pods mei leechste prioriteit fuortsmite. As alle pods deselde prioriteit hawwe, dan sil Kubernetes dy pods beëinigje dy't har oanfragen mear dan oare pods oertreffe.
Yn heul seldsume gefallen kinne Kubernetes pods ôfbrekke dy't noch binnen it berik fan har oanfragen binne. Dit kin barre as krityske systeemkomponinten lykas de Kubelet-agint of Docker mear boarnen begjinne te konsumearjen dan wat foar har reservearre wie.
Dat, yn 'e iere stadia fan lytse bedriuwen, kin in Kubernetes-kluster goed wurkje sûnder boarneoanfragen en beheiningen yn te stellen, mar as jo teams en projekten begjinne te groeien yn grutte, rinst it risiko dat jo yn dit gebiet problemen krije. It tafoegjen fan fragen en beheiningen oan jo modules en nammeromten fereasket heul bytsje ekstra ynspanning en kin in protte gedoe besparje.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com