Za vsak vir Kubernetes lahko konfigurirate dve vrsti zahtev – zahteve in omejitve. Prvi opisuje minimalne zahteve za razpoložljivost prostih virov vozlišča, ki so potrebni za zagon vsebnika ali sklopa, drugi pa strogo omejuje vire, ki so na voljo vsebniku.
Ko Kubernetes načrtuje pode, je zelo pomembno, da imajo vsebniki dovolj sredstev za pravilno delovanje. Če nameravate razmestiti veliko aplikacijo na vozlišču z omejenimi viri, je možno, da se ne bo zagnala, ker vozlišču primanjkuje pomnilnika ali pa mu zmanjkuje moči CPE. V tem članku si bomo ogledali, kako lahko rešite pomanjkanje računalniške moči z uporabo zahtev in omejitev virov.
Zahteve in omejitve so mehanizmi, ki jih Kubernetes uporablja za upravljanje virov, kot sta CPE in pomnilnik. Zahteve so tisto, kar zagotavlja, da vsebnik prejme zahtevani vir. Če vsebnik zahteva vir, ga bo Kubernetes načrtoval samo v vozlišču, ki ga lahko zagotovi. Omejitve nadzorujejo, da viri, ki jih zahteva vsebnik, ne bodo nikoli presegli določene vrednosti.
Vsebnik lahko poveča svojo računalniško moč le do določene meje, po kateri bo omejena. Poglejmo, kako deluje. Torej obstajata dve vrsti virov - procesor in pomnilnik. Razporejevalnik Kubernetes uporablja podatke o teh virih, da ugotovi, kje zagnati vaše pode. Tipična specifikacija vira za pod je videti takole.
Vsak vsebnik v podu lahko nastavi lastne poizvedbe in omejitve, vse je aditivno. Viri procesorja so definirani v milijedrih. Če vaš vsebnik za delovanje potrebuje dve polni jedri, nastavite vrednost na 2000 m. Če posoda potrebuje le moč 1/4 jedra, bo vrednost 250 m. Upoštevajte, da če dodelite vrednost vira CPE, ki je večja od števila jeder največjega vozlišča, vaš pod sploh ne bo načrtovan za zagon. Podobna situacija se bo zgodila, če imate Pod, ki potrebuje štiri jedra, gručo Kubernetes pa sestavljata samo dva glavna virtualna stroja.
Razen če je vaša aplikacija zasnovana posebej za izkoriščanje prednosti več jeder (na misel pridejo programi, kot so zapleteno znanstveno računalništvo in operacije baze podatkov), je najboljša praksa, da zahteve CPU nastavite na 1 ali nižje in nato zaženete več replik do razširljivosti. Ta rešitev bo dala sistemu večjo prilagodljivost in zanesljivost.
Ko gre za omejitve procesorja, postanejo stvari bolj zanimive, saj velja za stisljiv vir. Če se vaša aplikacija začne približevati omejitvi moči procesorja, bo Kubernetes začel upočasnjevati vaš vsebnik z dušenjem procesorja – zmanjšal bo frekvenco procesorja. To pomeni, da bo CPE umetno dušen, kar bo aplikaciji omogočilo morebitno slabše delovanje, vendar postopek ne bo prekinjen ali odstranjen.
Pomnilniški viri so definirani v bajtih. Običajno se vrednost v nastavitvah meri v mebibajtih Mib, lahko pa nastavite poljubno vrednost, od bajtov do petabajtov. Tukaj velja enaka situacija kot pri CPE - če postavite zahtevo za količino pomnilnika, ki je večja od količine pomnilnika na vaših vozliščih, ta pod ne bo načrtovan za izvedbo. Toda v nasprotju z viri procesorja pomnilnik ni stisnjen, ker njegove uporabe ni mogoče omejiti. Zato se bo izvajanje vsebnika ustavilo takoj, ko bo presegel pomnilnik, ki mu je dodeljen.
Pomembno si je zapomniti, da ne morete konfigurirati zahtev, ki presegajo vire, ki jih lahko zagotovijo vaša vozlišča. Specifikacije virov v skupni rabi za virtualne stroje GKE najdete na povezavah pod tem videoposnetkom.
V idealnem svetu bi privzete nastavitve vsebnika zadostovale za nemoteno delovanje delovnih tokov. Toda v realnem svetu ni tako, ljudje zlahka pozabijo konfigurirati uporabo virov ali pa bodo hekerji postavili zahteve in omejitve, ki presegajo realne zmogljivosti infrastrukture. Če želite preprečiti takšne scenarije, lahko konfigurirate kvote virov ResourceQuota in LimitRange.
Ko je imenski prostor ustvarjen, ga je mogoče blokirati s kvotami. Na primer, če imate imenska prostora prod in dev, je vzorec tak, da proizvodnih kvot sploh ni in so zelo stroge razvojne kvote. To omogoča prod, da v primeru močnega porasta prometa prevzame celoten razpoložljivi vir in popolnoma blokira dev.
Kvota virov bi lahko izgledala takole. V tem primeru so 4 razdelki - to so 4 spodnje vrstice kode.
Oglejmo si vsakega od njih. Requests.cpu je največje število združenih zahtev CPE, ki lahko prihajajo iz vseh vsebnikov v imenskem prostoru. V tem primeru bi lahko imeli 50 vsebnikov z 10 milijoni zahtev, pet vsebnikov s 100 milijoni zahtev ali samo en vsebnik s 500 milijoni zahtev. Dokler je skupno število requests.cpu danega imenskega prostora manjše od 500 m, bo vse v redu.
Memory requested requests.memory je največja količina združenih pomnilniških zahtev, ki jih lahko imajo vsi vsebniki v imenskem prostoru. Kot v prejšnjem primeru imate lahko 50 vsebnikov 2 mib, pet vsebnikov 20 mib ali en vsebnik 100 mib, če je skupna zahtevana količina pomnilnika v imenskem prostoru manjša od 100 mebibajtov.
Limits.cpu je največja skupna količina moči procesorja, ki jo lahko uporabljajo vsi vsebniki v imenskem prostoru. To lahko štejemo za omejitev zahtev po moči procesorja.
Končno je limits.memory največja količina skupnega pomnilnika, ki ga lahko uporabljajo vsi vsebniki v imenskem prostoru. To je omejitev skupnih zahtev za pomnilnik.
Tako vsebniki v gruči Kubernetes privzeto delujejo z neomejenimi računalniškimi viri. S kvotami virov lahko skrbniki gruče omejijo porabo virov in ustvarjanje virov na podlagi imenskega prostora. V imenskem prostoru lahko pod ali vsebnik porabi toliko moči procesorja in pomnilnika, kot je določeno s kvoto sredstev imenskega prostora. Vendar pa obstaja skrb, da lahko en pod ali vsebnik monopolizira vse razpoložljive vire. Da bi preprečili to situacijo, se uporablja mejni obseg – pravilnik za omejevanje dodeljevanja virov (za sklope ali vsebnike) v imenskem prostoru.
Mejno območje zagotavlja omejitve, ki lahko:
- Zagotovite najmanjšo in največjo uporabo računalniških virov za vsak modul ali vsebnik v imenskem prostoru;
- uveljavi minimalne in največje zahteve za shranjevanje Starage Request za vsak PersistentVolumeClaim v imenskem prostoru;
- uveljavi razmerje med zahtevo in omejitvijo za vir v imenskem prostoru;
- nastavite privzete zahteve/omejitve za računalniške vire v imenskem prostoru in jih samodejno vstavite v vsebnike med izvajanjem.
Na ta način lahko ustvarite omejitveni obseg v svojem imenskem prostoru. Za razliko od kvote, ki velja za celoten imenski prostor, se Limit Range uporablja za posamezne vsebnike. To lahko uporabnikom prepreči ustvarjanje zelo majhnih ali, nasprotno, ogromnih vsebnikov znotraj imenskega prostora. Mejni obseg bi lahko izgledal takole.
Kot v prejšnjem primeru lahko tudi tukaj ločimo 4 razdelke. Poglejmo vsakega posebej.
Privzeti razdelek nastavi privzete omejitve za vsebnik v sklopu. Če te vrednosti nastavite na skrajno območje, bodo vsi vsebniki, za katere te vrednosti niso bile izrecno nastavljene, sledili privzetim vrednostim.
Razdelek privzete zahteve defaultRequest konfigurira privzete zahteve za vsebnik v sklopu. Še enkrat, če nastavite te vrednosti na skrajno območje, bodo vsi vsebniki, ki ne nastavite izrecno teh možnosti, privzeto uporabili te vrednosti.
Razdelek max določa največje omejitve, ki jih je mogoče nastaviti za vsebnik v sklopu. Vrednosti v privzetem razdelku in omejitve vsebnika ni mogoče nastaviti nad to omejitvijo. Pomembno je upoštevati, da če je vrednost nastavljena na največ in ni privzetega odseka, največja vrednost postane privzeta vrednost.
Razdelek min določa minimalne zahteve, ki jih je mogoče nastaviti za vsebnik v skupini. Vendar pa vrednosti v privzetem razdelku in poizvedbe za vsebnik ni mogoče nastaviti pod to mejo.
Ponovno je pomembno omeniti, da če je ta vrednost nastavljena, privzeta ni, potem najmanjša vrednost postane privzeti poziv.
Te zahteve za sredstva na koncu uporabi razporejevalnik Kubernetes za izvajanje vaših delovnih obremenitev. Da lahko pravilno konfigurirate vsebnike, je zelo pomembno razumeti, kako deluje. Recimo, da želite zagnati več podov v svoji gruči. Ob predpostavki, da so specifikacije sklopa veljavne, bo urnik Kubernetes uporabil krožno uravnoteženje za izbiro vozlišča za izvajanje delovne obremenitve.
Kubernetes bo preveril, ali ima vozlišče 1 dovolj virov za izpolnitev zahtev iz vsebnikov pod, in če jih nima, se bo premaknil na naslednje vozlišče. Če nobeno od vozlišč v sistemu ne more zadovoljiti zahtev, bodo sklopi prešli v stanje čakanja. Z uporabo funkcij mehanizma Google Kubernetes, kot je samodejno skaliranje vozlišč, lahko GKE samodejno zazna stanje čakanja in ustvari več dodatnih vozlišč.
Če vam nato zmanjka zmogljivosti vozlišča, bo samodejno skaliranje zmanjšalo število vozlišč in tako prihranilo denar. Zato Kubernetes načrtuje pode na podlagi zahtev. Vendar je lahko omejitev višja od zahtev in v nekaterih primerih lahko vozlišču dejansko zmanjka virov. To stanje imenujemo stanje prevelike obveznosti.
Kot sem rekel, ko gre za CPE, bo Kubernetes začel omejevati pode. Vsaka enota bo prejela toliko, kot je zahtevala, če pa ne doseže omejitve, bo začelo veljati dušenje.
Ko gre za pomnilniške vire, je Kubernetes prisiljen sprejemati odločitve o tem, katere pode izbrisati in katere obdržati, dokler ne sprostite sistemskih virov ali pa se celoten sistem zruši.
Predstavljajmo si scenarij, ko vam stroj zmanjkuje pomnilnika – kako bi Kubernetes to rešil?
Kubernetes bo iskal sklope, ki uporabljajo več virov, kot so zahtevali. Torej, če vaši vsebniki sploh nimajo zahtev, to pomeni, da privzeto uporabljajo več, kot so zahtevali, preprosto zato, ker sploh niso zahtevali ničesar! Takšni zabojniki postanejo glavni kandidati za zaustavitev. Naslednji kandidati so kontejnerji, ki so zadovoljili vse svoje zahteve, vendar so še vedno pod maksimalno mejo.
Torej, če Kubernetes najde več podov, ki so presegli svoje parametre zahteve, jih bo razvrstil po prioriteti in nato odstranil pode z najnižjo prioriteto. Če imajo vsi podi enako prednost, bo Kubernetes prekinil tiste pode, ki presegajo svoje zahteve bolj kot drugi podi.
V zelo redkih primerih lahko Kubernetes prekine sklope, ki so še v obsegu njihovih zahtev. To se lahko zgodi, ko kritične komponente sistema, kot sta agent Kubelet ali Docker, začnejo porabljati več virov, kot je bilo rezervirano zanje.
Torej lahko v zgodnjih fazah majhnih podjetij gruča Kubernetes dobro deluje brez nastavljanja zahtev za vire in omejitev, toda ko se vaše ekipe in projekti začnejo povečevati, tvegate, da boste naleteli na težave na tem področju. Dodajanje poizvedb in omejitev vašim modulom in imenskim prostorom zahteva zelo malo dodatnega truda in lahko prihrani veliko težav.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com