Në fillim të punës me Kubernetes, zakonisht harrohet konfigurimi i burimeve të konteinerëve. Në këtë fazë, mjafton të siguroheni që imazhi Docker funksionon dhe mund të vendoset në klasterin Kubernetes.
Por më vonë, aplikacioni duhet të vendoset në klasterin e prodhimit së bashku me aplikacione të tjera. Për këtë, duhet të alokoni burime për konteinerin dhe të siguroheni që ato janë të mjaftueshme për të ndihmuar në nisjen dhe funksionimin e aplikacionit, pa shkaktuar probleme në aplikacionet e tjera që po funksionojnë.
Ekipa përktheu artikullin mbi burimet e konteinerëve (CPU & MEM), kërkesat dhe kufizimet e burimeve. Do të mësoni për përfitimet që ofrojnë këto konfigurime dhe çfarë do të ndodhë nëse ato nuk caktohen.
Burimet kompjuterike
Ne kemi dy lloje burimesh me njësi të tjera:
- Procesori qendror (CPU) — bërthama;
- Memoria (MEM) — bajta.
Burimet përcaktohen për çdo kontenier. Në skedarin YAML të mëposhtëm për Pod, do të shihni një seksion burimesh që përmban burimet e kërkuara dhe ato të kufizuara:
- Burimet e kërkuara të Pod = shuma e burimeve të kërkuara për të gjitha kontenierët;
- Burimet e kufizuara të Pod = shuma e burimeve të kufizuara për të gjitha kontenierë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 KERKUAR: 200m bërthama
memory: "1Gi" # MEMORIA E KERKUAR: 1Gi
limits:
cpu: 1 # PËRDORIMI MAKSIMAL I CPU: 1 bërthamë
memory: "1Gi" # PËRDORIMI MAKSIMAL I MEMORISË: 1Gi
— name: other-container
image: other-app
tag: v1
ports:
— containerPort: 8000
resources:
requests:
cpu: "200m" # CPU E KERKUAR: 200m bërthama
memory: "0.5Gi" # MEMORIA E KERKUAR: 0.5Gi
limits:
cpu: 1 # PËRDORIMI MAKSIMAL I CPU: 1 bërthamë
memory: "1Gi" # PËRDORIMI MAKSIMAL I MEMORISË: 1GiShembuj të resurseve të kërkuar dhe kufizuar
Fusha resources.requested nga specifikimi i Pod — një nga elementet që përdoren për të gjetur nodin e duhur. Më pas mund të planifikohet një implementim i Pod-it. Si e gjejnë nodin e përshtatshëm?
Kubernetes përbëhet nga disa komponentë, duke përfshirë një nod të 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ë reja të krijuara dhe kërkimin e mundshëm të nyjeve punuese që përputhen me të gjitha kërkesat e moduleve, përfshirë sasinë e burimeve të kërkuara. Lista e nyjeve të gjetura nga kube-scheduler renditet. Pod-i planifikohet në nyjen me pikët më të larta.
Ku do të vendoset Pod-i i purpurt?
Në figurë shihet se kube-scheduler duhet të planifikojë një Pod të ri purpurt. Klasteri Kubernetes përmban dy nyje: A dhe B. Siç mund të vërehet, kube-scheduler nuk mund ta planifikojë Pod-in në nyjen A — burimet e disponueshme (të paproçmuara) nuk përputhen me kërkesat e Pod-it purpurt. Pra, 1 GB memorie e kërkuar nga Pod-i purpurt nuk do të ketë vend në nyjen A, pasi volumi i disponueshëm i memories është 0,5 GB. Por nyja B ka mjaft burime. Si përfundim, kube-scheduler vendos se vendi i destinacionit për Pod-in purpurt është nyja B.
Tani e dimë se si burimet e kërkuara ndikojnë në zgjedhjen e nyjës për të ekzekutuar Pod-in. Por si ndikojnë burimet kufizuese?
Kapacitetet maksimale janë kufiri që CPU/MEM nuk mund të kalojë. Megjithatë, burimi CPU është fleksibël, prandaj kontejnerët që arrijnë vlerat maksimale për CPU, nuk do të shkaktojnë rrëzimin e Pod-it. Në vend të kësaj, do të aktivizohet frenimi për CPU. Nëse arrijmë kufirin e përdorimit të MEM, kontejneri do të ndalet për shkak të OOM-Killer dhe do të rinishet nëse kjo lejohet nga konfigurimi i RestartPolicy.
Burimet e kërkuara dhe maksimale në detaje
Lidhja e burimeve mes Docker dhe Kubernetes
Mënyra më e mirë për të shpjeguar se si funksionojnë burimet e kërkuara dhe maksimale është të paraqesësh lidhjen midis Kubernetes dhe Docker. Në ilustrimin e mësipërm, mund të shihni se si janë të lidhura fushat e Kubernetes dhe flagat e nisjes së Docker.
Memoria: kërkesa dhe kufizim
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Siç u përmend më parë, memoria matet në bite. Duke u bazuar në , mund të specifikojmë memorien si një numër. Zakonisht është e plotë, për shembull 2678 — do të thotë 2678 bite. Mund të përdoren gjithashtu sufikse G dhe Gi, e rëndësishme është të mbani mend se ato nuk janë ekuivalente. E para është decimal, ndërsa e dyta është binare. Si një shembull, e përmendur në dokumentacionin e k8s: 128974848, 129e6, 129M, 123Mi — ato janë praktikisht ekuivalente.
Parametri Kubernetes limits.memory korrespondon me flamurin --memory nga Docker. Në rastin e request.memory shigjeta për Docker mungon, pasi Docker nuk e përdor këtë fushë. Mund të pyesni, a është kjo e nevojshme? Po, është e nevojshme. Siç e thashë, fusha ka rëndësi për Kubernetes. Në bazë të informacionit që merr nga ajo, kube-scheduler vendos se në cilin nod të programojë Pod-in.
Çfarë do të ndodhë nëse vendosni një kërkesë për memorie të pamjaftueshme?
Nëse konteneri arrin kufijtë e memorie së kërkuar, atëherë Pod-i do të vendoset në grupin e Pod-ve, të cilët ndalohen kur ka mungesë të memories në nod.
Çfarë do të ndodhë nëse vendosni një kufi të parakohshëm për memorien?
Nëse konteneri tejkalon kufirin e memorieve, ai do të mbyllet për shkak të OOM-Killed. Dhe do të ri-startohet, nëse është e mundur sipas RestartPolicy, ku vlera për parazgjedhje është Always.
Çfarë do të ndodhë nëse nuk specifikoni memorien e kërkuar?
Kubernetes do të marrë kufirin dhe do ta vendosë atë si vlerën e parazgjedhjes.
Çfarë mund të ndodhë nëse nuk specifikoni memorien e kufizuar?
Kontejneri nuk kanë kufizime; ai mund të përdorë aq memorie sa dëshiron. Megjithatë, nëse fillon të përdorë të gjithë memorjen e disponueshme të nodit, OOM do ta vrasë. Pastaj, kontejneri do të ribashkohet, nëse kjo është e mundur sipas RestartPolicy.
Çfarë ndodh nëse nuk përcaktohen kufij të memories?
Ky është skenari më i keq: planifikuesi nuk e di se sa burime i duhen kontejnerit, dhe kjo mund të shkaktojë probleme serioze në nodë. Në këtë rast, do të ishte mirë të kishte kufizime siç janë DefaultLimit (të vendosura nga LimitRange). Nuk ka kufizime të paracaktuara — Pod nuk ka kufizime dhe mund të përdorë aq memorie sa dëshiron.
Nëse memoria e kërkuar është më shumë se ajo që nodi mund të ofrojë — Pod nuk do të planifikohet. Është e rëndësishme të mbani mend se Requests.memory nuk është vlera minimale. Kjo është një përshkrim i sasisë së memories që është e mjaftueshme për funksionimin e vazhdueshëm të kontejnerit.
Vizita e zakonshme është të vendoset e njëjta vlerë për request.memory dhe limit.memory. Kështu, Kubernetes nuk do ta planifikojë Podin në një nodë të cilën ka mjaftueshëm memorie për të nisur Pod, por jo mjaftueshëm për të funksionuar. Mbani mend: kur planifikohet Pod, Kubernetes merr parasysh vetëm requests.memory, dhe limits.memory nuk merr parasysh.
CPU: kërkesë dhe kufizim
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
CPU në Kubernetes është pak më i komplikuar. Duke u kthyer në figurën që tregon lidhjen midis Kubernetes dhe Docker, mund të vëresh se request.cpu përputhet --cpu-shares, ndërsa limit.cpu korrespondon me flamurin cpus në Docker.
CPU që kërkon Kubernetes, shumëzohet me 1024 — proporcioni i cikleve të CPU. Nëse dëshiron të kërkosh 1 bërthamë të plotë, atëherë duhet të shtosh cpu: 1, siç tregohet më lart.
Kërkesa për një bërthamë të plotë (proporcioni = 1024) nuk nënkupton që kontejneri yt do ta marrë atë. Nëse kompjuteri yt pritës ka vetëm një bërthamë, dhe po përdor më shumë se një kontejner, të gjithë kontejnerët duhet të ndajnë kolektivisht CPU-në e disponueshme. Si ndodh kjo? Le të shikojmë figurën.
Kërkesa për CPU — sistem me një bërthamë
Le të imagjinojmë se ke një sistem pritës me një bërthamë, në të cilin janë aktivizuar kontejnerët. Nëna (Kubernetes) ka pjekur një tortë (CPU) dhe dëshiron ta ndajë atë midis fëmijëve (kontejnerëve). Tre fëmijë duan një tortë të plotë (proporcioni = 1024), një tjetër fëmijë dëshiron 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%Duke nga llogaritja, tre fëmijë do të marrin 28% të bërthamës, dhe jo një bërthamë të plotë. Fëmija i katërt do të marrë 14% të bërthamës së plotë, dhe jo gjysmën. Por gjithçka do të ishte ndryshe nëse do të keni një sistem me shumë bërthama.
Kërkesa për CPU — sistem me shumë bërthama (4)
Në imazhin më lart, shihet se tre fëmijë duan nga një tortë të plotë, dhe një — gjysmën. Meqenëse nëna ka pjekur katër torta, çdo fëmijë do të marrë aq sa dëshiron. Në një sistem me shumë bërthama, burimet e procesorit shpërndahen në të gjitha bërthamës që janë në dispozicion. Nëse një kontejner është i kufizuar në më pak se një bërthamë të plotë CPU, ai mund ta përdorë atë në 100%.
Llogaritjet e mësipërme janë thjeshtuar për të kuptuar se si shpërndahet CPU midis kontejnerëve. Sigurisht, përveç vetë kontejnerëve, ka edhe procese të tjera që gjithashtu përdorin burimet e CPU. Kur proceset në një kontejner janë në pritje, të tjerët mund të përdorin burimin e tij. CPU: "200m" përputhet CPU: 0,2, që do të thotë rreth 20% të një bërthame.
Tani le të flasim për limit.cpu. CPU, i cili është i kufizuar nga Kubernetes, shumëzohet me 100. Rezultati është sasia e kohës që një kontejner mund të përdorë çdo 100 µs (cpu-period).
limit.cpu përputhet me flagun Docker --cpus. Ky është një kombinim i ri i të vjetrave --cpu-period dhe --cpu-quota. Duke e vendosur, ne tregojmë se sa burime CPU mund të përdorë maksimalisht një konteiner deri sa të fillojë ngadalësimi:
- cpus — kombinim
cpu-perioddhecpu-quota. cpus = 1.5barazohet me vendosjen ecpu-period = 100000dhecpu-quota = 150000; - cpu-period — periudhë , me default 100 mikrosekonda;
- cpu-quota — numri i mikrosekondave brenda
cpu-period, me të cilat është i kufizuar konteineri.
Çfarë ndodh nëse vendosni një CPU të papërballueshëm?
Nëse konteineri ka nevojë për më shumë se sa është vendosur, ai do të vjedhë CPU nga proceset e tjera.
Çfarë ndodh nëse vendosni një kufi të pamjaftueshëm CPU?
Pasi burimi i CPU është i rregulluar, ngadalësimi do të aktivizohet.
Çfarë do të ndodhë nëse nuk caktoni kërkesën CPU?
Ashtu si në rastin e memories, vlera e kërkesës është e barabartë me kufirin.
Çfarë ndodh nëse nuk caktoni kufirin CPU?
Konteineri do të përdorë aq CPU sa i nevojitet. Nëse në hapësirën e emrave është caktuar një politikë CPU me defaut (LimitRange), atëherë ky kufi përdoret edhe për konteinerin.
Çfarë ndodh nëse nuk caktoni as kërkesën as kufirin CPU?
Si në rastin e memories, ky është skenari më i keq. Planifikuesi nuk e di sa burime i nevojiten kontejnerit tuaj, dhe kjo mund të shkaktojë probleme të rënda në nod. Për ta evituar këtë, duhet të vendosni kufizime të paracaktuara për hapësirat emri (LimitRange).
Kujtoni: nëse kërkoni më shumë CPU sesa mund të ofrojnë nodet, atëherë Pod-i nuk do të planifikohet. Requests.cpu nuk është vlera minimale, por një vlerë e mjaftueshme për të nisur Pod-in dhe për të funksionuar pa probleme. Nëse aplikacioni nuk bën llogaritje të ndërlikuara, opsioni më i mirë është të vendosni request.cpu <= 1 dhe të nisni aq shumë replika sa nevojitet.
Sasia ideale e burimeve të kërkuara ose kufizimeve të burimeve
Kemi mësuar për kufizimet e burimeve kompjuterike. Tani është koha të përgjigjemi në pyetjen: "Sa burime i nevojiten Pod-it tim për të funksionuar aplikacioni pa probleme? Çfarë sasia është ideale?".
Fatkeqësisht, nuk ka përgjigje të saktë për këto pyetje. Nëse nuk e dini si funksionon aplikacioni juaj, sa CPU ose memorie i nevojitet, opsioni më i mirë është të jepni aplikacionit shumë memorie dhe CPU, dhe pastaj të ecni me teste performancë.
Përveç testeve të performancës, gjatë javës ndiqni sjelljen e aplikacionit në monitorim. Nëse grafiket tregojnë se aplikacioni juaj konsumon më pak burime sesa keni kërkuar, mund të reduktoni numrin e CPU ose memorjes së kërkuar.
Si shembull, shikoni këtë . Ai tregon diferencën midis burimeve të kërkuara ose kufirit të burimeve dhe përdorimit aktual të burimeve.
Përfundimi
Kërkesa dhe kufizimi i burimeve ndihmojnë në mbështetje të funksionimit të klasterit Kubernetes. Konfigurimi i duhur i kufijve minimizon kostot dhe mban aplikacionet gjithmonë në funksion.
Në përmbledhje, duhet të mbani mend disa pika:
- Burimet e kërkuara janë konfigurimi që merret parasysh gjatë fillimit (kur Kubernetes planifikon vendosjen e aplikacionit). Në të kundërt, kufizimi i burimeve është i rëndësishëm gjatë funksionimit — kur aplikacioni është tashmë në njësinë.
- Në krahasim me memorinë, CPU është një burim i rregullueshëm. Në rast të mungesës së CPU, Pod-i juaj nuk do të mbyllet, do të aktivizohet mekanizmi i ngadalësimit.
- Kërkuar burimet dhe kufijtë e burimeve nuk janë vlera minimale dhe maksimale! Duke përcaktuar burimet e kërkuara, ju garantoni që aplikacionesh do të funksionojnë pa probleme.
- Një praktikë e mirë është të vendosni kërkesën për memorje, e cila është e barabartë me kufirin e memorjes.
- Është mirë të vendosni kërkesën për
CPU <=1, nëse aplikacioni nuk kryen llogaritje komplekse. - Nëse kërkoni më shumë burime se sa ka në nod, Pod kurrë nuk do të planifikohet në këtë nod.
- Për të përcaktuar numrin e saktë të burimeve të kërkuara/kufijve të burimeve, përdorni testimin e ngarkesës dhe monitorimin.
Shpresoj që ky artikull t'ju ndihmojë të kuptoni konceptin themelor të kufizimit të burimeve. Dhe do të jeni në gjendje të aplikoni këto njohuri në punën tuaj.
Suksese!
Çfarë tjetër mund të lexoni:
- .
- .
- .
Burimi: habr.com
