Kubernetes-ekin hastean, ohikoa da edukiontzien baliabideak konfiguratzeaz ahaztea. Une honetan, nahikoa da Docker irudiak funtzionatzen duela eta Kubernetes klusterean heda daitekeela ziurtatzea.
Baina geroago aplikazioa ekoizpen-kluster batean zabaldu behar da beste aplikazio batzuekin batera. Horretarako, edukiontzirako baliabideak esleitu behar dituzu eta ziurtatu nahikoa daudela aplikazioa martxan jartzeko, eta exekutatzen ari diren beste aplikazio batzuek ez dutela arazorik izango.
Team edukiontzien baliabideei (CPU eta MEM), eskaerei eta baliabideen mugei buruzko artikulu bat itzuli du. Ezarpen hauen abantailak eta ezartzen ez badituzu zer gertatzen den ikasiko duzu.
Baliabide informatikoak
Bi baliabide mota ditugu unitate hauekin:
- Prozesatzeko unitate zentrala (CPU) - nukleoak;
- Memoria (MEM) - byteak.
Edukiontzi bakoitzeko baliabideak zehazten dira. Ondorengo Pod YAML fitxategian, eskatutako eta mugatutako baliabideak dituen baliabideen atal bat ikusiko duzu:
- Requested Pod Resources = edukiontzi guztien eskatutako baliabideen batura;
- Pod Resource Limit = Pod baliabideen muga guztien batura.
apiVersion: v1
kind: Pod
metadata:
name: backend-pod-name
labels:
application: backend
spec:
containers:
β name: main-container
image: my-backend
tag: v1
ports:
β containerPort: 8080
resources:
requests:
cpu: 0.2 # REQUESTED CPU: 200m cores
memory: "1Gi" # REQUESTED MEM: 1Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1Gi
β name: other-container
image: other-app
tag: v1
ports:
β containerPort: 8000
resources:
requests:
cpu: "200m" # REQUESTED CPU: 200m cores
memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
limits:
cpu: 1 # MAX CPU USAGE: 1 core
memory: "1Gi" # MAX MEM USAGE: 1GiEskatutako eta mugatutako baliabideen adibidea
Field resources.requested zehaztapenetik Pod nahi den nodoa aurkitzeko erabiltzen den elementuetako bat da. Dagoeneko Pod inplementazioa planifikatu dezakezu horretarako. Nola aurkitzen duzu nodo egoki bat?
Kubernetes hainbat osagaiz osatuta dago, nodo nagusi bat edo nodo nagusi bat barne (Kubernetes Control Plane). Nodo maisuak hainbat prozesu ditu: kube-apiserver, kube-controller-manager eta kube-scheduler.
Kube-scheduler prozesuak sortu berri diren podak berrikusteaz eta pod eskaera guztiekin bat datozen langile-nodo posibleak aurkitzeaz arduratzen da, eskatutako baliabide kopurua barne. Kube-scheduler-ek aurkitutako nodoen zerrenda sailkatuta dago. Pod-a puntuazio altuenak dituen nodoan programatzen da.
Non jarriko da Pod morea?
Irudian kube-scheduler-ek Pod more berri bat antolatu behar duela ikus dezakezu. Kubernetes klusterrak bi nodo ditu: A eta B. Ikus dezakezunez, kube-scheduler-ek ezin du Pod bat programatu A nodoan - erabilgarri dauden (eskatu gabeko) baliabideak ez datoz bat Pod morearen eskaerekin. Beraz, Pod moreak eskatutako 1 GB memoria ez da A nodoan sartuko, memoria erabilgarria 0,5 GB delako. Baina B nodoak nahikoa baliabide ditu. Ondorioz, kube-scheduler-ek Pod morearen helmuga B nodoa dela erabakitzen du.
Orain badakigu nola eragiten duten eskatutako baliabideek Pod-a exekutatzeko nodoaren aukeran. Baina zein da baliabide marjinalek duten eragina?
Baliabideen muga CPU/MEMk gainditu ezin duen muga da. Hala ere, PUZaren baliabidea malgua da, beraz, PUZaren mugetara iristen diren edukiontziek ez dute Pod-a aterako. Horren ordez, CPU throttling hasiko da. MEM erabilera-mugara iristen bada, edukiontzia geldituko da OOM-Killer dela eta, eta berrabiaraziko da RestartPolicy ezarpenak baimentzen badu.
Eskatutako eta gehienezko baliabideak xehetasunez
Docker eta Kubernetes-en arteko baliabideen komunikazioa
Baliabideen eskaerak eta baliabideen mugek nola funtzionatzen duten azaltzeko modurik onena Kubernetes eta Dockerren arteko harremana sartzea da. Goiko irudian Kubernetes eremuak eta Docker abiarazteko banderak nola erlazionatzen diren ikus dezakezu.
Memoria: eskaera eta muga
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Goian esan bezala, memoria bytetan neurtzen da. Oinarrituta , memoria zenbaki gisa zehaztu dezakegu. Normalean zenbaki oso bat da, adibidez 2678 - hau da, 2678 byte. Atzizkiak ere erabil ditzakezu G ΠΈ Gi, gauza nagusia ez direla baliokideak gogoratzea da. Lehenengoa hamartarra da eta bigarrena bitarra. K8s dokumentazioan aipatutako adibidea bezala: 128974848, 129e6, 129M, 123Mi - Ia baliokideak dira.
Kubernetes aukera limits.memory banderarekin bat dator --memory Docker-etik. kasuan request.memory Dockerrentzat ez dago gezirik, Docker-ek ez duelako eremu hau erabiltzen. Galdetuko duzu, hau ere beharrezkoa al da? Bai behar. Lehen esan dudan bezala, eremuak garrantzia du Kubernetesentzat. Bertako informazioaren arabera, kube-scheduler-ek Pod-a zein nodo programatu erabakitzen du.
Zer gertatzen da eskaera baterako memoria nahikoa ez baduzu?
Edukiontzia eskatutako memoriaren mugetara iritsi bada, Pod-a nodoan nahikoa memoria ez dagoenean gelditzen den Pod talde batean jartzen da.
Zer gertatzen da memoria-muga baxuegia ezartzen baduzu?
Ontziak memoria-muga gainditzen badu, amaitu egingo da OOM-Killed dela eta. Eta ahal bada berrabiaraziko da balio lehenetsia dagoen RestartPolicy-n oinarrituta Always.
Zer gertatzen da eskatutako memoria zehazten ez baduzu?
Kubernetes-ek muga-balioa hartuko du eta balio lehenetsi gisa ezarriko du.
Zer gerta daiteke memoria mugarik zehazten ez baduzu?
Ontziak ez du mugarik; nahi adina memoria erabil dezake. Nodoaren memoria erabilgarri guztia erabiltzen hasten bada, orduan OOM-ek hil egingo du. Ondoren, edukiontzia berrabiaraziko da, ahal bada, RestartPolicy-n oinarrituta.
Zer gertatzen da memoria-mugak zehazten ez badituzu?
Hau da kasurik txarrena: programatzaileak ez daki zenbat baliabide behar dituen edukiontziak, eta horrek arazo larriak sor ditzake nodoan. Kasu honetan, ondo legoke izen-eremuan muga lehenetsiak izatea (LimitRange-k ezarrita). Ez dago muga lehenetsirik - Podak ez du mugarik, nahi adina memoria erabil dezake.
Eskatutako memoria nodoak eskain dezakeena baino gehiago bada, Pod-a ez da programatuko. Garrantzitsua da hori gogoratzea Requests.memory - ez gutxieneko balioa. Hau edukiontzia etengabe martxan mantentzeko nahikoa den memoria kopuruaren deskribapena da.
Normalean balio bera ezartzea gomendatzen da request.memory ΠΈ limit.memory. Honek bermatzen du Kubernetes-ek ez duela Pod bat programatuko Pod-a exekutatzeko nahikoa memoria duen nodo batean, baina exekutatzeko nahikoa ez duen nodo batean. Gogoan izan: Kubernetes Pod plangintzak bakarrik hartzen du kontuan requests.memoryEta limits.memory ez du kontuan hartzen.
CPU: eskaera eta muga
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU batekin dena pixka bat zailagoa da. Kubernetes eta Dockerren arteko harremanaren irudira itzuliz, hori ikus dezakezu request.cpu ΡΠΎΠΎΡΠ²Π΅ΡΡΡΠ²ΡΠ΅Ρ --cpu-shares, aldiz limit.cpu banderarekin bat dator cpus Docker-en.
Kubernetes-ek eskatzen duen CPUa 1024rekin biderkatzen da, PUZaren zikloen proportzioa. Nukleo osoa eskatu nahi baduzu, gehitu behar duzu cpu: 1goian erakusten den bezala.
Kernel osoa eskatzeak (proportzioa = 1024) ez du esan nahi zure edukiontziak jasoko duenik. Zure ostalari-makinak nukleo bakarra badu eta edukiontzi bat baino gehiago exekutatzen ari bazara, edukiontzi guztiek erabilgarri dagoen CPUa partekatu beharko dute haien artean. Nola gertatzen da hau? Ikus dezagun argazkia.
CPU eskaera - Nukleo bakarreko sistema
Imajina dezagun edukiontziak exekutatzen dituen nukleo bakarreko ostalari sistema bat duzula. Amak (Kubernetes) tarta bat (CPU) labean egin eta haurren artean (ontziak) banatu nahi du. Hiru haurrek tarta osoa nahi dute (proportzioa = 1024), beste ume batek tarta erdia nahi du (512). Amak bidezkoa izan nahi du eta kalkulu sinple bat egiten du.
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³ΠΎΠ² Ρ
ΠΎΡΡΡ Π΄Π΅ΡΠΈ?
# 3 ΡΠ΅Π±Π΅Π½ΠΊΠ° Ρ
ΠΎΡΡΡ ΠΏΠΎ ΡΠ΅Π»ΠΎΠΌΡ ΠΏΠΈΡΠΎΠ³Ρ ΠΈ Π΅ΡΠ΅ ΠΎΠ΄ΠΈΠ½ Ρ
ΠΎΡΠ΅Ρ ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Ρ ΠΏΠΈΡΠΎΠ³Π°
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# ΠΡΡΠ°ΠΆΠ΅Π½ΠΈΠ΅ ΠΏΠΎΠ»ΡΡΠ°Π΅ΡΡΡ ΡΠ°ΠΊ:
3 (ΡΠ΅Π±Π΅Π½ΠΊΠ°/ΠΊΠΎΠ½ΡΠ΅ΠΉΠ½Π΅ΡΠ°) * 1 (ΡΠ΅Π»ΡΠΉ ΠΏΠΈΡΠΎΠ³/ΠΏΠΎΠ»Π½ΠΎΠ΅ ΡΠ΄ΡΠΎ) + 1 (ΡΠ΅Π±Π΅Π½ΠΎΠΊ/ΠΊΠΎΠ½ΡΠ΅ΠΉΠ½Π΅Ρ) * 0.5 (ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Π° ΠΏΠΈΡΠΎΠ³Π°/ΠΏΠΎΠ»ΠΎΠ²ΠΈΠ½Π° ΡΠ΄ΡΠ°)
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³ΠΎΠ² ΠΈΡΠΏΠ΅ΡΠ΅Π½ΠΎ?
availableCakesNumber = 1
# Π‘ΠΊΠΎΠ»ΡΠΊΠΎ ΠΏΠΈΡΠΎΠ³Π° (ΠΌΠ°ΠΊΡΠΈΠΌΠ°Π»ΡΠ½ΠΎ) Π΄Π΅ΡΠΈ ΡΠ΅Π°Π»ΡΠ½ΠΎ ΠΌΠΎΠ³ΡΡ ΠΏΠΎΠ»ΡΡΠΈΡΡ?
newMaxRequest = 1 / 3.5 =~ 28%Kalkuluaren arabera, hiru haurrek muinaren %28 jasoko dute, eta ez muin osoa. Laugarren haurrak nukleo osoaren %14 jasoko du, ez erdia. Baina gauzak desberdinak izango dira nukleo anitzeko sistema bat baduzu.
CPU eskaera - Nukleo anitzeko (4) sistema
Goiko irudian ikusten da hiru haurrek pastel osoa nahi dutela, eta batek erdia. Amak lau tarta labean egin zituenez, bere seme-alaba bakoitzak nahi adina jasoko ditu. Nukleo anitzeko sistema batean, prozesadore-baliabideak eskuragarri dauden prozesadore-nukleo guztietan banatzen dira. Edukiontzi bat CPU-nukleo oso bat baino gutxiagora mugatuta badago, oraindik ere % 100ean erabil dezake.
Aurreko kalkuluak sinplifikatu egiten dira CPU edukiontzien artean nola banatzen den ulertzeko. Jakina, edukiontziez gain, CPU baliabideak ere erabiltzen dituzten beste prozesu batzuk daude. Edukiontzi bateko prozesuak inaktibo daudenean, besteek bere baliabidea erabil dezakete. CPU: "200m" ΡΠΎΠΎΡΠ²Π΅ΡΡΡΠ²ΡΠ΅Ρ CPU: 0,2, hau da, nukleo baten %20 gutxi gorabehera.
Orain hitz egin dezagun limit.cpu. Kubernetes-ek mugatzen duen CPUa 100ez biderkatzen da. Emaitza da edukiontziak 100 Β΅s behin erabil dezakeen denbora (cpu-period).
limit.cpu Docker banderarekin bat dator --cpus. Hau zaharraren konbinazio berria da --cpu-period ΠΈ --cpu-quota. Ezartzean, edukiontziak zenbat CPU baliabide erabilgarri erabil ditzakeen adieraziko dugu murrizketa hasi aurretik:
- cpus - konbinazioa
cpu-periodΠΈcpu-quota. cpus = 1.5ezarpenaren baliokideacpu-period = 100000ΠΈcpu-quota = 150000; - CPU-aldia - aldia , lehenetsia 100 mikrosegundo;
- cpu-kuota - barruan dauden mikrosegundo kopurua
cpu-period, edukiontziarekin mugatuta dagoena.
Zer gertatzen da eskatutako CPU nahikorik instalatzen baduzu?
Edukiontziak instalatuta duena baino gehiago behar badu, PUZa lapurtuko du beste prozesu batzuetatik.
Zer gertatzen da CPU muga baxuegia ezartzen baduzu?
PUZaren baliabidea erregulagarria denez, throttling aktibatuko da.
Zer gertatzen da CPU eskaerarik zehazten ez baduzu?
Memoriarekin gertatzen den bezala, eskaeraren balioa mugaren berdina da.
Zer gertatzen da CPU mugarik zehazten ez baduzu?
Edukiontzi horrek behar adina CPU erabiliko du. PUZaren gidalerro lehenetsi bat (LimitRange) izen-eremuan definitzen bada, muga hori edukiontzirako ere erabiltzen da.
Zer gertatzen da eskaera edo CPU mugarik ez baduzu zehazten?
Memoriarekin gertatzen den bezala, hau da kasurik txarrena. Antolatzaileak ez daki zure edukiontziak zenbat baliabide behar dituen, eta honek arazo larriak sor ditzake nodoan. Hori ekiditeko, izen-espazioetarako muga lehenetsiak ezarri behar dituzu (LimitRange).
Gogoratu: nodoek eman dezaketen baino CPU gehiago eskatzen baduzu, Pod-a ez da programatuko. Requests.cpu - ez gutxieneko balioa, Pod-a abiarazteko eta hutsegiterik gabe lan egiteko nahikoa baizik. Aplikazioak kalkulu konplexuak egiten ez baditu, aukerarik onena instalatzea da request.cpu <= 1 eta abiarazi behar adina erreplika.
Eskatutako baliabideen kopuru ideala edo baliabideen muga
Baliabide informatikoen mugak ezagutu genituen. Orain galderari erantzuteko garaia da: "Zenbat baliabide behar ditu nire Podak aplikazioa arazorik gabe exekutatzeko? Zein da kopuru ideala?
Zoritxarrez, ez dago galdera hauen erantzun argirik. Zure aplikazioak nola funtzionatzen duen edo zenbat CPU edo memoria behar duen ez badakizu, aukerarik onena aplikazioari memoria eta CPU asko ematea da eta gero errendimendu probak egitea.
Errendimendu probez gain, monitorizatu aplikazioaren portaera astebetez monitorizazioan. Grafikoek adierazten badute zure aplikazioak zuk eskatutakoa baino baliabide gutxiago kontsumitzen ari dela, eskatutako CPU edo memoria kopurua murriztu dezakezu.
Adibide gisa ikusi hau . Eskatutako baliabideen edo baliabideen mugaren eta uneko baliabideen erabileraren arteko aldea erakusten du.
Ondorioa
Baliabideak eskatzeak eta mugatzeak zure Kubernetes klusterrak osasuntsu mantentzen laguntzen du. Muga-konfigurazio egokiak kostuak gutxitzen ditu eta aplikazioak uneoro martxan mantentzen ditu.
Laburbilduz, kontuan hartu beharreko gauza batzuk daude:
- Eskatutako baliabideak abiaraztean kontuan hartzen den konfigurazio bat dira (Kubernetes-ek aplikazioa ostatatzeko asmoa duenean). Aitzitik, baliabideak mugatzea garrantzitsua da exekuzioan, aplikazioa dagoeneko nodoan exekutatzen ari denean.
- Memoriarekin alderatuta, CPU erregulatutako baliabidea da. PUZ nahikorik ez badago, zure Pod ez da itzaliko eta murrizketa mekanismoa piztuko da.
- Eskatutako baliabideak eta baliabideen muga ez dira gutxieneko eta gehienezko balioak! Eskatutako baliabideak zehaztuz, aplikazioa arazorik gabe abiaraziko dela ziurtatzen duzu.
- Praktika on bat memoria eskaera memoria mugaren berdina ezartzea da.
- Ados instalatzea eskatu da
CPU <=1, aplikazioak kalkulu konplexurik egiten ez badu. - Nodo batean erabilgarri dauden baino baliabide gehiago eskatzen badituzu, Pod-a ez da inoiz programatuko nodo horretan.
- Eskatutako baliabide/baliabideen muga kopuru zuzena zehazteko, erabili karga-probak eta jarraipena.
Artikulu honek baliabideen mugaren oinarrizko kontzeptua ulertzen lagunduko dizula espero dut. Eta ezagutza hori zure lanean aplikatzeko aukera izango duzu.
Good Luck!
Zer gehiago irakurri:
- .
- .
- .
Iturria: www.habr.com