Në fillim të punës me Kubernetes, zakonisht harrohet për konfigurimin e burimeve të konteinerëve. Në këtë stad mjafton të sigurohemi që imazhi Docker funksionon dhe mund të vendoset në grupin Kubernetes.
Por më vonë, aplikacioni kërkohet të vendoset në grupin e prodhimit së bashku me aplikacione të tjera. Për këtë, është e nevojshme të shkëputen burime për konteinerin dhe të sigurohemi se ato janë të mjaftueshme për të nisur dhe operuar aplikacionin, dhe që aplikacionet e tjera të përfshira nuk kanë të papriturat.
Ekipa përktheu artikullin mbi burimet e konteinerëve (CPU & MEM), kërkesat dhe kufizimet e burimeve. Do të mësoni se cilat janë avantazhet e këtyre konfigurimeve dhe çfarë do ndodhë nëse nuk i vendosni.
Burimet llogaritëse
Ne kemi dy lloje burimesh me njësitë e mëposhtme:
- Procesori Qendror (CPU) — bërthamat;
- Memoria (MEM) — bajtët.
Burimet përcaktohen për secilin konteiner. Në skedarin YAML të Podit do të shihni seksionin e burimeve, i cili përmban burimet e kërkuara dhe kufizuese:
- Burimet e kërkuara të Podit = shuma e burimeve të kërkuara nga të gjithë konteinerët;
- Burimet e kufizuara të Podit = shuma e burimeve të kufizuara nga të gjithë konteinerët.
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 # CPU E KËRQYER: 200m bërthama
memory: "1Gi" # MEM E KËRQYER: 1Gi
limits:
cpu: 1 # PËRDORIMI MAXIMAL I CPU: 1 bërthamë
memory: "1Gi" # PËRDORIMI MAXIMAL I MEM: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # CPU E KËRQYER: 200m bërthama
memory: "0.5Gi" # MEM E KËRQYER: 0.5Gi
limits:
cpu: 1 # PËRDORIMI MAXIMAL I CPU: 1 bërthamë
memory: "1Gi" # PËRDORIMI MAXIMAL I MEM: 1GiShembulli i burimeve të kërkuara dhe të kufizuara
Fusha resources.requested nga specifikimi i Pod — një nga elementët, që përdoren për të gjetur nodin e duhur. Aty mund të planifikohet vendosja e Podit. Si gjejnë nodin e përshtatshëm?
Kubernetes përbëhet nga disa komponente, duke përfshirë një nod kryesor ose master-nod (Kubernetes Control Plane). Në master-nod ka disa procese: kube-apiserver, kube-controller-manager dhe kube-scheduler.
Procesi kube-scheduler është përgjegjës për shqyrtimin e moduleve të sapo krijuara dhe gjetjen e mundshmeve të nodëve të punës që i përmbushin të gjitha kërkesat e moduleve, përfshirë numrin e burimeve të kërkuara. Lista e nodëve, e gjetur nga kube-scheduler, renditet. Pod planifikohet në nodin me pikët më të larta.
Ku do të vendoset Pod-i purpurt?
Në imazh, duket se kube-scheduler duhet të planifikojë një Pod të ri purpurt. Klusteri Kubernetes përmban dy nyje: A dhe B. Siç mund të vini re, kube-scheduler nuk mund ta planifikojë Pod-in në nyjen A — burimet e disponueshme (të paplota) nuk përputhen me kërkesat e Pod-it purpurt. Kështu, 1 GB memorie e kërkuar nga Pod-i purpurt nuk do të përshtatet në nyjen A, pasi vëllimi i disponueshëm i memories është 0,5 GB. Por nyja B ka burime të mjaftueshme. Në fund, kube-scheduler vendos se vendi i destinacionit të Pod-it purpurt është nyja B.
Tani e dimë se si kërkesat për burime ndikojnë në zgjedhjen e nyjes për ekzekutimin e Pod-it. Por si ndikon kufiri i burimeve?
Kufijtë e burimeve janë kufiri që CPU/MEM nuk mund të kalojë. Megjithatë, burimi CPU është fleksibël, prandaj kontejnerët që arrijnë kufijtë e CPU-së nuk do të çojnë në ndalimin e Pod-it. Në vend të kësaj, do të nisë ngadalësimi i CPU-së. Nëse arrihet kufiri i përdorimit të MEM, atëherë kontejneri do të ndalet për shkak të OOM-Killer dhe do të rinishet, nëse kjo lejohet nga konfigurimi i RestartPolicy.
Kërkesat dhe kufijtë për burime në detaje
Lidhja e burimeve midis Docker dhe Kubernetes
Mënyra më e mirë për të shpjeguar se si funksionojnë kërkesat dhe kufijtë për burime është të paraqesësh lidhjen midis Kubernetes dhe Docker. Në figurën e mësipërme mund të shihni se si janë të lidhura fushat e Kubernetesit dhe flagat e nisjes së Docker.
Memoria: kërkesë dhe kufizim
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Siç u përmend më lart, memoria matet në byte. Duke u bazuar në , ne mund ta shprehim memory-n si një numër. Zakonisht është e plotë, për shembull 2678 — do të thotë 2678 byte. Mund të përdorim gjithashtu sufiksat G dhe Gi, e rëndësishme është të kujtojmë se ato nuk janë ekuivalente. E para është dekadale, ndërsa e dyta është binare. Si shembull, i përmendur në dokumentacionin e k8s: 128974848, 129e6, 129M, 123Mi — ato janë praktikisht ekuivalente.
Parametri i Kubernetes limits.memory përputhet me flamurin --memory nga Docker. Në rastin e request.memory nuk ka një arrow për Docker, pasi Docker nuk e përdor këtë fushë. Mund të pyesni, a është e nevojshme kjo? Po, është e nevojshme. Siç e thashë, fusha ka rëndësi për Kubernetes. Bazuar në informacionin nga ajo, kube-scheduler vendos se në cilën nyjë të planifikojë Pod-in.
Çfarë do ndodhë nëse vendosni një kërkesë për memorie të pamjaftueshme?
Nëse kontejneri arrin kufijtë e memories së kërkuar, atëherë Pod-i vendoset në grupin e Pod-eve që ndalen kur nuk ka mjaftueshëm memorie në nod.
Çfarë ndodh nëse vendosni një kufi shumë të vogël për memorien?
Nëse kontejneri e kalon kufirin e memorien, ai do të mbyllet për shkak të OOM-Killed. Dhe do të rinstalohet nëse është e mundur sipas RestartPolicy, ku vlera e paracaktuar është Gjithmonë.
Çfarë do të ndodhë nëse nuk specifikoni memorien e kërkuar?
Kubernetes do të marrë kufirin e memorien dhe do ta vendosë atë si vlerën e paracaktuar.
Çfarë mund të ndodhi nëse nuk specifikoni kufirin e memorisë?
Kontejneri nuk ka kufij, mund të përdorë sa më shumë memorie që dëshiron. Nëse fillon të përdorë gjithë memorien e disponueshme të nodit, do të vritet nga OOM. Pas kësaj, kontejneri do të rinstalohet, nëse është e mundur sipas RestartPolicy.
Çfarë do të ndodhë nëse nuk specifikoni kufijtë e memorisë?
Kjo është skenari më i keq: planifikuesi nuk e di sa burime i duhen kontejnerit, dhe kjo mund të shkaktojë probleme të mëdha në nod. Në këtë rast, do të ishte mirë të keni kufij të paracaktuar në hapësirën emërore (të vendosura nga LimitRange). Nuk ka kufij të paracaktuar — Pod-i nuk ka kufij, ai mund të përdorë sa më shumë memorie që dëshiron.
Nëse memoria e kërkuar është më e madhe se sa mund të ofrojë nodi — Pod-i nuk do të planifikohet. Është e rëndësishme të mbani mend se Requests.memory nuk është vlera minimale. Ky është përshkrimi i sasisë së memorisë e cila është e mjaftueshme për funksionimin e vazhdueshëm të kontejnerit.
Në përgjithësi, rekomandohet të vendosni të njëjtën vlerë për request.memory dhe limit.memory. Me këtë, Kubernetes nuk do të planifikojë Pod-in në një nod që ka mjaftueshëm memorie për të ekzekutuar Pod-in, por jo mjaft për ta mbajtur atë në punë. Mbani mend: gjatë planifikimit të Pod-it, Kubernetes merr parasysh vetëm requests.memory, ndërsa limits.memory nuk përfshin.
CPU: kërkesë dhe kufizim
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Për CPU-në është pak më e komplikuar. Duke u rikthyer tek figura që tregon ndërveprimin midis Kubernetes dhe Docker, mund të vini re se request.cpu përputhet me --cpu-shares, ndërsa limit.cpu përputhet me flamurin cpus në Docker.
CPU që kërkon Kubernetes, shumëzohet me 1024 - proporcioni i cikleve të CPU. Nëse dëshironi të kërkoni 1 bërthamë të plotë, duhet të shtoni cpu: 1, siç është treguar më lart.
Kërkesa për një bërthamë të plotë (proporcioni = 1024) nuk do të thotë se konteineri juaj do ta marrë atë. Nëse sistemi juaj pritës ka vetëm një bërthamë dhe po përdorni më shumë se një konteiner, atëherë të gjitha kontenierët duhet të ndajnë CPU-në e disponueshme midis tyre. Si ndodh kjo? Le të shohim pamjen.
Kërkesa e CPU-së — sistem i një bërthame
Imagjinoni se keni një sistem pritës me një bërthamë, në të cilin janë aktivizuar kontenierët. Nëna (Kubernetes) bëri një tortë (CPU) dhe dëshiron ta ndajë atë midis fëmijëve (kontenierëve). Tre fëmijë duan një tortë të plotë (proporcioni = 1024), një fëmijë tjetër do gjysmën e tortës (512). Nëna dëshiron të jetë e drejtë dhe bën një llogaritje të thjeshtë.
# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%Sipas llogaritjes, tre fëmijë do të marrin nga 28% e bërthamës, e jo nga një bërthamë e plotë. Fëmija i katërt do të marrë 14% nga bërthama e plotë, e jo gjysmën. Por gjithçka do të jetë ndryshe nëse keni një sistem me shumë bërthama.
Kërkesa e CPU-së — sistem me shumë bërthama (4)
Në figurën lart, shihet se tre fëmijë duan një tortë të plotë, ndërsa një fëmijë tjetër dëshiron gjysmën. Për shkak se nëna bëri katër torta, çdo fëmijë do të marrë aq sa dëshiron. Në një sistem me shumë bërthama, burimet e procesorit ndahen në të gjitha bërthamat e disponueshme. Nëse një konteiner është i kufizuar me më pak se një bërthamë të plotë të CPU-së, ai mund ta përdorë atë gjithsesi në 100%.
Llogaritjet e mësipërme janë thjeshtuar për të kuptuar se si shpërndahen CPU-në midis konteinerëve. Sigurisht, përveç kontenierëve vetë, ka edhe procese të tjera që gjithashtu përdorin burimet e CPU-së. Kur proceset në një konteiner janë në pritje, të tjerët mund t'i përdorin burimet e tij. CPU: "200m" përputhet me CPU: 0,2, që do të thotë rreth 20% e një bërthame.
Tani le të flasim për limit.cpu. CPU, që kufizohet nga Kubernetes, shumëzohet me 100. Rezultati është sasia e kohës që konteineri mund të përdorë çdo 100 mikros dhe (cpu-period).
limit.cpu përputhet me flamurin e Docker-it --cpus. Kjo është një kombinim i ri i të vjetrave --cpu-period dhe --cpu-quota. Duke e vendosur, ne tregojmë se sa burime të disponueshme të CPU-së një konteiner mund të përdorë maksimalisht deri sa të fillojë kufizimi:
- cpus — kombinimi
cpu-perioddhecpu-quota. cpus = 1.5është ekvivalente me vendosjencpu-period = 100000dhecpu-quota = 150000; - cpu-period — periudha , sipas parazgjedhjes 100 mikrosekonda;
- cpu-quota — numri i mikrosekondave brenda
cpu-period, të cilit i është kufizuar konteineri.
Çfarë do të ndodhte nëse vendosni një CPU të pamjaftueshëm?
Nëse konteineri ka nevojë për më shumë se sa është vendosur, ai do të vjedhë CPU nga procese të tjera.
Çfarë do të ndodhte nëse vendosni një kufi të pamjaftueshëm për CPU?
Duke qenë se burimi i CPU është i rregullueshëm, do të aktivizohet throttling.
Çfarë do të ndodhte nëse nuk specifikoni kërkesën për CPU?
Siç ndodh me kujtesën, vlera e kërkesës është e barabartë me kufirin.
Çfarë do të ndodhte nëse nuk specifikoni kufirin për CPU?
Konteineri do të përdorë aq CPU sa i nevojitet. Nëse në hapësirën e emrave është përcaktuar një politikë e parazgjedhur për CPU (LimitRange), atëherë ky kufi përdoret gjithashtu për konteinerin.
Çfarë do të ndodhte nëse nuk specifikoni as kërkesën dhe as kufirin për CPU?
Siç ndodh me kujtesën, ky është skenari më i keq. Planifikuesi nuk e di se sa burime i duhen konteinerit tuaj dhe kjo mund të shkaktojë probleme serioze në nodë. Për ta shmangur këtë, duhet të vendosni kufij të parazgjedhur për hapësirat e emrave (LimitRange).
Mbani mend: nëse kërkoni më shumë CPU se sa nodet mund të ofrojnë, atëherë Pod-i nuk do të planifikohet. Requests.cpu — nuk është një vlerë minimale, por një vlerë e mjaftueshme për të funksionuar Pod-i pa ndërprerje. Nëse aplikacioni nuk bën llogaritje të komplikuara, opsioni më i mirë është të vendosni request.cpu <= 1 dhe të lancioni sa më shumë replika sa është e nevojshme.
Sasia ideale e burimeve të kërkuara ose kufirit të burimeve
Ne mësuam rreth kufizimeve të burimeve kompjuterike. Tani është koha për të përgjigjur në pyetjen: "Sa burime i nevojiten Pod-it tim për të funksionuar aplikacioni pa probleme? Sa është sasia ideale?".
Fatkeqësisht, nuk ka përgjigje të qarta për këto pyetje. Nëse nuk e dini se si funksionon aplikacioni juaj, sa CPU ose kujtesë i nevojitet, opsioni më i mirë është t'i jepni aplikacionit shumë kujtesë dhe CPU dhe pastaj të bëni testime të performancës.
Përveç testeve të performancës, gjatë një jave monitoroni sjelljen e aplikacionit në monitorim. Nëse grafiket tregojnë se aplikacioni juaj konsumon më pak burime se sa keni kërkuar, atëherë mund të reduktoni numrin e CPU ose kujtesës të kërkuar.
Si një shembull, shihni këtë . Ai tregon diferencën midis burimeve të kërkuara ose kufirit të burimeve dhe përdorimit aktual të burimeve.
Përfundim
Kërkesa dhe kufizimi i burimeve ndihmojnë në mbajtjen e funksionimit të Kubernetes klaster. Konfigurimi i saktë i limiteve minimizon shpenzimet dhe mban vazhdimisht aplikacionet në punë.
Në përmbledhje, duhet të mbani mend disa pika:
- Burimet e kërkuara janë konfigurimi që merret parasysh gjatë nisjes (kur Kubernetes planifikon vendosjen e aplikacionit). Në anën tjetër, kufizimi i burimeve është i rëndësishëm gjatë funksionimit — kur aplikacioni tashmë është nisur në nyjë.
- Në krahasim me memorjen, CPU është një burim i rregullueshëm. Në rast se ka mungesë CPU, Pod-i juaj nuk do të ndalojë punën, do të aktivizohet mekanizmi i kontrollit të kapacitetit.
- Burimet e kërkuara dhe kufizimi i burimeve nuk janë vlera minimale dhe maksimale! Duke caktuar burimet e kërkuara, ju garantoni që aplikacioni do të funksionojë pa probleme.
- Një praktikë e mirë është të vendosni kërkesën për memorje të barabartë me kufizimin e memorjes.
- Është mirë të vendosni kërkesën
CPU <=1, nëse aplikacioni nuk kryen llogaritje komplekse. - Nëse kërkoni më shumë burime se sa ka në nyjë, Pod-i nuk do të planifikohet kurrë në këtë nyjë.
- Për të përcaktuar sasinë e saktë të burimeve të kërkuara/kufizimeve të burimeve, përdorni testimin e ngarkesës dhe monitorimin.
Shpresoj se ky artikull do t'ju ndihmojë të kuptoni konceptin e përgjithshëm të kufizimit të burimeve. Dhe ju do të jeni në gjendje të aplikoni këto njohuri në punën tuaj.
Suksese!
Çfarë tjetër mund të lexoni:
- .
- .
- .
Burimi: habr.com
