Por ĉiu rimedo de Kubernetes, vi povas agordi du specojn de postuloj - Petoj kaj Limoj. La unua priskribas la minimumajn postulojn por la havebleco de senpagaj nodaj rimedoj necesaj por funkciigi ujon aŭ balgon, la dua strikte limigas la disponeblajn rimedojn al la ujo.
Kiam Kubernetes planas podojn, estas tre grave, ke la ujoj havas sufiĉajn rimedojn por funkcii ĝuste. Se vi planas deploji grandan aplikaĵon sur rimedo-limigita nodo, estas eble ke ĝi ne funkcios ĉar la nodo mankas memoro aŭ elĉerpigas CPU-potencon. En ĉi tiu artikolo, ni rigardos kiel vi povas solvi komputikpotencan mankon uzante rimedojn kaj limojn.
Petoj kaj Limoj estas mekanismoj, kiujn Kubernetes uzas por administri rimedojn kiel CPU kaj memoro. Petoj estas kiuj certigas, ke la ujo ricevas la petitan rimedon. Se ujo petas rimedon, Kubernetes planos ĝin nur sur nodo, kiu povas provizi ĝin. Limoj kontrolas, ke la rimedoj petitaj de la ujo neniam superos certan valoron.
Ujo povas nur pliigi sian komputikan potencon ĝis certa limo, post kiu ĝi estos limigita. Ni vidu kiel ĝi funkcias. Do, ekzistas du specoj de rimedoj - procesoro kaj memoro. La planilo de Kubernetes uzas datumojn pri ĉi tiuj rimedoj por ekscii, kie ruli viajn podojn. Tipa rimeda specifo por pod aspektas tiel.
Ĉiu ujo en pod povas agordi siajn proprajn demandojn kaj limojn, ĉio estas aldonaĵo. Procesorresursoj estas difinitaj en milikoroj. Se via ujo bezonas du plenajn kernojn por funkcii, vi fiksas la valoron al 2000m. Se la ujo bezonas nur la potencon de 1/4 de la kerno, la valoro estos 250m. Memoru, ke se vi atribuas CPU-rimedan valoron pli grandan ol la nombron da kernoj de la plej granda nodo, via podo tute ne estos planita por komenci. Simila situacio okazos se vi havas Pod, kiu bezonas kvar kernojn, kaj la Kubernetes-areo konsistas el nur du ĉefaj virtualaj maŝinoj.
Krom se via aplikaĵo estas desegnita specife por utiligi plurajn kernojn (programoj kiel kompleksa scienca komputado kaj datumbazaj operacioj venas en la menso), tiam la plej bona praktiko estas agordi CPU-Petojn al 1 aŭ malpli kaj poste ruli pli da kopioj al skaleblo. Ĉi tiu solvo donos al la sistemo pli grandan flekseblecon kaj fidindecon.
Kiam temas pri CPU-limigoj, aferoj fariĝas pli interesaj, ĉar ĝi estas konsiderata kiel kunpremebla rimedo. Se via aplikaĵo komencas alproksimiĝi al la limo de potenco de procesoro, Kubernetes komencos malrapidigi vian ujon per CPU Throttling - reduktante la frekvencon de procesoro. Ĉi tio signifas, ke la CPU estos artefarite streĉita, donante al la aplikaĵo eble pli malbonan rendimenton, sed la procezo ne estos ĉesigita aŭ forigita.
Memorresursoj estas difinitaj en bajtoj. Kutime la valoro en la agordoj estas mezurita en mebibajtoj Mib, sed vi povas agordi ajnan valoron, de bajtoj ĝis petabajtoj. La sama situacio validas ĉi tie kiel ĉe la CPU - se vi metas peton por kvanto de memoro pli granda ol la kvanto de memoro sur viaj nodoj, tiu pod ne estos planita por ekzekuti. Sed male al CPU-resursoj, memoro ne estas kunpremita ĉar ekzistas neniu maniero limigi ĝian uzon. Tial, la ekzekuto de la ujo estos ĉesigita tuj kiam ĝi iras preter la memoro asignita al ĝi.
Gravas memori, ke vi ne povas agordi petojn, kiuj superas la rimedojn, kiujn viaj nodoj povas provizi. Specifoj de komunaj rimedoj por virtualaj maŝinoj de GKE troveblas en la ligiloj sub ĉi tiu video.
En ideala mondo, la defaŭltaj agordoj de la ujo sufiĉus por ke laborfluoj funkcias glate. Sed la reala mondo ne estas tia, homoj povas facile forgesi agordi la uzon de rimedoj, aŭ hackers starigos petojn kaj limigojn, kiuj superas la realajn kapablojn de la infrastrukturo. Por malhelpi tiajn scenarojn okazi, vi povas agordi rimedokvotojn de ResourceQuota kaj LimitRange.
Post kiam nomspaco estas kreita, ĝi povas esti blokita uzante kvotojn. Ekzemple, se vi havas la nomspacojn prod kaj dev, la ŝablono estas, ke tute ne ekzistas produktadkvotoj kaj tre striktaj disvolvaj kvotoj. Ĉi tio permesas al prod, en la okazo de akra kresko de trafiko, transpreni la tutan disponeblan rimedon, tute blokante dev.
La rimedkvoto povus aspekti tiel. En ĉi tiu ekzemplo estas 4 sekcioj - ĉi tiuj estas la 4 malsupraj linioj de kodo.
Ni rigardu ĉiun el ili. Requests.cpu estas la maksimuma nombro da kombinitaj CPU-petoj, kiuj povas veni de ĉiuj ujoj en la nomspaco. En ĉi tiu ekzemplo, vi povus havi 50 ujojn kun 10m petoj, kvin ujoj kun 100m petoj, aŭ nur unu ujon kun 500m petoj. Tiel longe kiel la totala nombro de requests.cpu de donita nomspaco estas malpli ol 500m, ĉio estos en ordo.
Memoro petita petoj.memoro estas la maksimuma kvanto de kombinitaj memorpetoj kiujn ĉiuj ujoj en la nomspaco povas havi. Kiel en la antaŭa kazo, vi povas havi 50 2 mib-ujojn, kvin 20-mib-ujojn aŭ ununuran 100-mib-ujon kondiĉe ke la totala kvanto de memoro petita en la nomspaco estas malpli ol 100 mebibajtoj.
Limits.cpu estas la maksimuma kombinita kvanto de CPU-potenco kiun ĉiuj ujoj en la nomspaco povas uzi. Ni povas konsideri ĉi tion kiel la limo de procesoraj potencopetoj.
Fine, limits.memory estas la maksimuma kvanto de komuna memoro kiun ĉiuj ujoj en la nomspaco povas uzi. Ĉi tio estas limo por totalaj memorpetoj.
Do, defaŭlte, ujoj en Kubernetes-areo funkcias per senlimaj komputikaj rimedoj. Kun rimedkvotoj, clusteradministrantoj povas limigi rimedkonsumon kaj rimedkreadon bazitan sur nomspaco. En nomspaco, pod aŭ ujo povas konsumi tiom da CPU-potenco kaj memoro kiel determinite per la nomspaca rimedkvoto. Tamen, estas zorgo, ke unu balgo aŭ ujo povas monopoligi ĉiujn disponeblajn rimedojn. Por malhelpi ĉi tiun situacion, limgamo estas uzata - politiko por limigi la asignon de rimedoj (por podoj aŭ ujoj) en la nomspaco.
La limintervalo disponigas restriktojn kiuj povas:
- Certigu minimuman kaj maksimuman uzadon de komputikaj rimedoj por ĉiu modulo aŭ ujo en la nomspaco;
- devigi minimumajn kaj maksimumajn Starage Request-stokadpetojn por ĉiu PersistentVolumeClaim en la nomspaco;
- devigi rilaton inter Peto kaj Limo por rimedo en nomspaco;
- starigu defaŭltajn Petojn/Limojn por komputikaj rimedoj en la nomspaco kaj aŭtomate injektu ilin en ujojn ĉe rultempo.
Tiel vi povas krei limgamon en via nomspaco. Male al kvoto, kiu validas por la tuta nomspaco, Limit Range estas uzata por individuaj ujoj. Ĉi tio povas malhelpi uzantojn krei tre etajn aŭ, male, gigantajn ujojn ene de la nomspaco. La Lima Gamo povus aspekti tiel.
Kiel en la antaŭa kazo, 4 sekcioj povas esti distingitaj ĉi tie. Ni rigardu ĉiun.
La defaŭlta sekcio fiksas la defaŭltajn limojn por la ujo en la pod. Se vi fiksas ĉi tiujn valorojn al la ekstrema gamo, tiam ĉiuj ujoj, por kiuj ĉi tiuj valoroj ne estis eksplicite fiksitaj, sekvos la defaŭltajn valorojn.
La defaŭlta petosekcio defaultRequest agordas la defaŭltajn petojn por la ujo en la pod. Denove, se vi fiksas ĉi tiujn valorojn al la ekstrema gamo, tiam ĉiuj ujoj, kiuj ne eksplicite fiksas ĉi tiujn opciojn, defaŭltos ĉi tiujn valorojn.
La maksimuma sekcio specifas la maksimumajn limojn, kiujn oni povas agordi por ujo en la pod. Valoroj en la defaŭlta sekcio kaj ujlimoj ne povas esti agorditaj super ĉi tiu limo. Gravas noti, ke se la valoro estas agordita al max kaj ne ekzistas defaŭlta sekcio, tiam la maksimuma valoro fariĝas la defaŭlta valoro.
La min-sekcio specifas la minimumajn petojn, kiujn oni povas agordi por ujo en pod. Tamen, la valoroj en la defaŭlta sekcio kaj demandoj por la ujo ne povas esti agordita sub ĉi tiu limo.
Denove, estas grave noti, ke se ĉi tiu valoro estas agordita, defaŭlta ne, tiam la minimuma valoro iĝas la defaŭlta prompto.
Ĉi tiuj rimedoj-petoj estas finfine uzataj de la planilo de Kubernetes por plenumi viajn laborŝarĝojn. Por ke vi agordu viajn ujojn ĝuste, estas tre grave kompreni kiel ĝi funkcias. Ni diru, ke vi volas ruli plurajn podojn en via areto. Supozante ke la podspecifoj estas validaj, la Kubernetes-horaro uzos rondan ekvilibron por elekti nodon por funkcii la laborkvanton.
Kubernetes kontrolos ĉu Nodo 1 havas sufiĉajn rimedojn por plenumi petojn de la podujoj, kaj se ĝi ne faras, ĝi transiros al la sekva nodo. Se neniu el la nodoj en la sistemo kapablas kontentigi la petojn, la balgoj iros en la staton de Pritraktata. Uzante Google Kubernetes-motorajn funkciojn kiel nodan aŭtoskalon, GKE povas aŭtomate detekti la atendan staton kaj krei plurajn pliajn pliajn nodojn.
Se vi poste elĉerpas kapaciton de nodoj, aŭtoskalado reduktos la nombron da nodoj por ŝpari monon al vi. Jen kial Kubernetes planas podojn surbaze de petoj. Tamen, la limo povas esti pli alta ol la petoj, kaj en iuj kazoj la nodo povas efektive elĉerpi rimedojn. Ni nomas ĉi tiun ŝtaton superengaĝiĝo ŝtato.
Kiel mi diris, kiam temas pri CPU, Kubernetes komencos limigi la podojn. Ĉiu balgo ricevos tiom, kiom ĝi petis, sed se ĝi ne atingas la limon, strekado komencos apliki.
Se temas pri memorrimedoj, Kubernetes estas devigita fari decidojn pri kiuj podoj forigi kaj kiujn konservi ĝis vi liberigos sistemajn rimedojn aŭ la tuta sistemo kraŝos.
Ni imagu scenaron kie vi havas maŝinon elĉerpita memoro - kiel Kubernetes pritraktus tion?
Kubernetes serĉos podojn, kiuj uzas pli da rimedoj ol ili petis. Do se viaj ujoj tute ne havas Petojn, tio signifas, ke ili defaŭlte uzas pli ol ili petis, simple ĉar ili tute ne petis ion! Tiaj ujoj iĝas ĉefaj kandidatoj por ĉesigo. La sekvaj kandidatoj estas ujoj kiuj kontentigis ĉiujn siajn petojn sed ankoraŭ estas sub la maksimuma limo.
Do se Kubernetes trovos plurajn podojn, kiuj superis siajn petajn parametrojn, ĝi ordigos ilin laŭ prioritato kaj poste forigos la plej malaltajn prioritatajn podojn. Se ĉiuj podoj havas la saman prioritaton, tiam Kubernetes finos tiujn podojn kiuj superas siajn petojn pli ol aliaj podoj.
En tre maloftaj kazoj, Kubernetes povas interrompi podojn kiuj ankoraŭ estas en la amplekso de siaj petoj. Ĉi tio povas okazi kiam kritikaj sistemaj komponantoj kiel la agento Kubelet aŭ Docker komencas konsumi pli da rimedoj ol tio, kio estis rezervita por ili.
Do, en la fruaj stadioj de malgrandaj kompanioj, Kubernetes-areo povas funkcii bone sen fiksi rimedojn kaj limigojn, sed kiam viaj teamoj kaj projektoj komencas kreski en grandeco, vi riskas renkonti problemojn en ĉi tiu areo. Aldoni demandojn kaj limojn al viaj moduloj kaj nomspacoj postulas tre malgrandan kroman penon kaj povas ŝpari multe da ĝeno.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com