Kur filloni me Kubernetes, është e zakonshme të harrosh vendosjen e burimeve të kontejnerëve. Në këtë pikë, mjafton të sigurohet që imazhi Docker të funksionojë dhe të mund të vendoset në grupin Kubernetes.
Por më vonë aplikacioni duhet të vendoset në një grup prodhimi së bashku me aplikacionet e tjera. Për ta bërë këtë, duhet të ndani burime për kontejnerin dhe të siguroheni që ka mjaft prej tyre për të vënë në funksion aplikacionin dhe që aplikacionet e tjera që funksionojnë nuk do të kenë probleme.
Ekip përktheu një artikull në lidhje me burimet e kontejnerëve (CPU & MEM), kërkesat dhe kufizimet e burimeve. Do të mësoni përfitimet e këtyre cilësimeve dhe çfarë ndodh nëse nuk i vendosni ato.
Burimet kompjuterike
Ne kemi dy lloje burimesh me njësitë e mëposhtme:
- Njësia qendrore e përpunimit (CPU) - bërthama;
- Kujtesa (MEM) - byte.
Burimet janë të specifikuara për çdo kontejner. Në skedarin e mëposhtëm Pod YAML, do të shihni një seksion burimesh që përmban burimet e kërkuara dhe të kufizuara:
- Resurset e kërkuara të pod = shuma e burimeve të kërkuara të të gjithë kontejnerëve;
- Kufiri i Burimeve Pod = Shuma e të gjithë Limiteve të Burimeve Pod.
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: 1GiShembull i burimeve të kërkuara dhe të kufizuara
Fushë resources.requested nga specifikimi Pod është një nga elementët që përdoret për të gjetur nyjen e dëshiruar. Ju tashmë mund të planifikoni vendosjen e Pod për të. Si të gjeni një nyje të përshtatshme?
Kubernetes përbëhet nga disa komponentë, duke përfshirë një nyje kryesore ose nyje kryesore (Ribri i Kontrollit të Kubernetes). Nyja master ka disa procese: kube-apiserver, kube-controller-manager dhe kube-scheduler.
Procesi kube-scheduler është përgjegjës për rishikimin e pod-ve të krijuara rishtazi dhe gjetjen e nyjeve të mundshme të punonjësve që përputhen me të gjitha kërkesat e pod, duke përfshirë numrin e burimeve të kërkuara. Lista e nyjeve të gjetura nga kube-scheduler renditet. Pozicioni është planifikuar në nyjen me rezultatet më të larta.
Ku do të vendoset Pod vjollcë?
Në foto mund të shihni se kube-scheduler duhet të planifikojë një Pod të ri vjollcë. Grupi Kubernetes përmban dy nyje: A dhe B. Siç mund ta shihni, kube-scheduler nuk mund të planifikojë një Pod në nyjen A - burimet e disponueshme (të pa kërkuara) nuk përputhen me kërkesat e Pod-it vjollcë. Pra, 1 GB memorie e kërkuar nga Pod vjollcë nuk do të përshtatet në nyjen A, pasi memoria e disponueshme është 0,5 GB. Por nyja B ka burime të mjaftueshme. Si rezultat, kube-scheduler vendos që destinacioni i Pod-it të purpurt të jetë nyja B.
Tani e dimë se si burimet e kërkuara ndikojnë në zgjedhjen e nyjes për të drejtuar Pod. Por cili është ndikimi i burimeve margjinale?
Kufiri i burimit është një kufi që CPU/MEM nuk mund ta kalojë. Megjithatë, burimi i CPU-së është fleksibël, kështu që kontejnerët që arrijnë kufijtë e CPU-së nuk do të shkaktojnë daljen e Pod-it. Në vend të kësaj, do të fillojë bllokimi i CPU-së. Nëse arrihet kufiri i përdorimit të MEM, kontejneri do të ndalet për shkak të OOM-Killer dhe do të rindizet nëse lejohet nga cilësimi RestartPolicy.
Resurset e kërkuara dhe maksimale në detaje
Komunikimi i burimeve midis Docker dhe Kubernetes
Mënyra më e mirë për të shpjeguar se si funksionojnë kërkesat për burime dhe kufizimet e burimeve është prezantimi i marrëdhënieve midis Kubernetes dhe Docker. Në imazhin e mësipërm mund të shihni se si lidhen fushat e Kubernetes dhe flamujt e fillimit të Docker.
Kujtesa: kërkesë dhe kufizim
containers:
...
resources:
requests:
memory: "0.5Gi"
limits:
memory: "1Gi"
Siç u përmend më lart, memoria matet në bajt. Bazuar në , ne mund të specifikojmë kujtesën si një numër. Zakonisht është një numër i plotë, për shembull 2678 - domethënë 2678 bajt. Ju gjithashtu mund të përdorni prapashtesa G и Gi, gjëja kryesore është të mbani mend se ato nuk janë ekuivalente. E para është dhjetore dhe e dyta është binar. Ashtu si shembulli i përmendur në dokumentacionin k8s: 128974848, 129e6, 129M, 123Mi - ato janë praktikisht ekuivalente.
Opsioni Kubernetes limits.memory përputhet me flamurin --memory nga Docker. Në rast se request.memory Nuk ka asnjë shigjetë për Docker sepse Docker nuk e përdor këtë fushë. Ju mund të pyesni, a është kjo e nevojshme? Po duhet. Siç thashë më parë, fusha ka rëndësi për Kubernetes. Bazuar në informacionin prej tij, kube-scheduler vendos se në cilën nyje të planifikojë Pod-in.
Çfarë ndodh nëse vendosni memorie të pamjaftueshme për një kërkesë?
Nëse kontejneri ka arritur kufijtë e memories së kërkuar, atëherë Pod vendoset në një grup Pods që ndalojnë kur nuk ka memorie të mjaftueshme në nyje.
Çfarë ndodh nëse e vendosni kufirin e kujtesës shumë të ulët?
Nëse kontejneri tejkalon kufirin e memories, ai do të ndërpritet për shkak të "OOM-Killed". Dhe do të riniset nëse është e mundur bazuar në RestartPolicy ku është vlera e paracaktuar Always.
Çfarë ndodh nëse nuk e specifikoni memorien e kërkuar?
Kubernetes do të marrë vlerën kufi dhe do ta vendosë atë si vlerën e paracaktuar.
Çfarë mund të ndodhë nëse nuk specifikoni një kufi memorie?
Kontejneri nuk ka kufizime; ai mund të përdorë sa më shumë memorie të dojë. Nëse ai fillon të përdorë të gjithë memorien e disponueshme të nyjës, atëherë OOM do ta vrasë atë. Kontejneri do të riniset më pas nëse është e mundur bazuar në RestartPolicy.
Çfarë ndodh nëse nuk specifikoni kufijtë e kujtesës?
Ky është skenari më i keq: planifikuesi nuk e di se sa burime kërkon kontejneri dhe kjo mund të shkaktojë probleme serioze në nyje. Në këtë rast, do të ishte mirë të kishim kufij të paracaktuar në hapësirën e emrave (të vendosur nga LimitRange). Nuk ka kufij të paracaktuar - Pod nuk ka kufij, ai mund të përdorë sa më shumë memorie të dojë.
Nëse memoria e kërkuar është më shumë sesa mund të ofrojë nyja, Pod nuk do të planifikohet. Është e rëndësishme të mbani mend këtë Requests.memory - jo vlera minimale. Ky është një përshkrim i sasisë së memories së mjaftueshme për të mbajtur kontejnerin të funksionojë vazhdimisht.
Zakonisht rekomandohet të vendosni të njëjtën vlerë për request.memory и limit.memory. Kjo siguron që Kubernetes nuk do të planifikojë një Pod në një nyje që ka memorie të mjaftueshme për të ekzekutuar Pod-in, por jo mjaftueshëm për ta ekzekutuar atë. Mbani në mend: Planifikimi i Kubernetes Pod merr vetëm parasysh requests.memoryDhe limits.memory nuk merr parasysh.
CPU: kërkesa dhe kufiri
containers:
...
resources:
requests:
cpu: 1
limits:
cpu: "1200m"
Me një CPU gjithçka është pak më e komplikuar. Duke iu rikthyer fotos së marrëdhënies midis Kubernetes dhe Docker, mund ta shihni këtë request.cpu korrespondon me --cpu-shares, ndërsa limit.cpu përputhet me flamurin cpus në Docker.
CPU që kërkon Kubernetes shumëzohet me 1024, përqindja e cikleve të CPU. Nëse dëshironi të kërkoni 1 bërthamë të plotë, duhet të shtoni cpu: 1siç tregohet më sipër.
Kërkimi i një kernel të plotë (proporcioni = 1024) nuk do të thotë se kontejneri juaj do ta marrë atë. Nëse kompjuteri juaj pritës ka vetëm një bërthamë dhe ju jeni duke drejtuar më shumë se një kontejnerë, atëherë të gjithë kontejnerët duhet të ndajnë CPU-në e disponueshme ndërmjet tyre. Si ndodh kjo? Le të shohim foton.
Kërkesë CPU - Sistem Single Core
Le të imagjinojmë se keni një sistem pritës me një bërthamë që drejton kontejnerët. Mami (Kubernetes) ka pjekur një byrek (CPU) dhe dëshiron ta ndajë atë midis fëmijëve (kontejnerëve). Tre fëmijë duan një byrek të plotë (proporcioni = 1024), një fëmijë tjetër dëshiron gjysmë byreku (512). Mami 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%Në bazë të llogaritjes, tre fëmijë do të marrin 28% të bërthamës, dhe jo të gjithë bërthamës. Fëmija i katërt do të marrë 14% të kernelit të plotë, jo gjysmën. Por gjërat do të jenë ndryshe nëse keni një sistem me shumë bërthama.
Kërkesë CPU - Sistemi Multi-Bërthamor (4).
Në imazhin e mësipërm mund të shihni se tre fëmijë duan një byrek të tërë, dhe njëri dëshiron gjysmën. Meqenëse mami ka pjekur katër byrekë, secili prej fëmijëve të saj do të marrë sa të dojë. Në një sistem me shumë bërthama, burimet e procesorit shpërndahen në të gjitha bërthamat e disponueshme të procesorit. Nëse një kontejner është i kufizuar në më pak se një bërthamë të plotë të CPU-së, ai mund ta përdorë përsëri në 100%.
Llogaritjet e mësipërme janë thjeshtuar për të kuptuar se si CPU shpërndahet midis kontejnerëve. Sigurisht, përveç vetë kontejnerëve, ka procese të tjera që përdorin gjithashtu burime CPU. Kur proceset në një kontejner janë të papunë, të tjerët mund të përdorin burimin e tij. CPU: "200m" korrespondon me CPU: 0,2, që do të thotë afërsisht 20% e një bërthame.
Tani le të flasim për limit.cpu. CPU që kufizon Kubernetes shumëzohet me 100. Rezultati është sasia e kohës që kontejneri mund të përdorë çdo 100 µs (cpu-period).
limit.cpu përputhet me flamurin Docker --cpus. Ky është një kombinim i ri i vjetër --cpu-period и --cpu-quota. Duke e vendosur atë, ne tregojmë se sa burime të disponueshme CPU mund të përdorë maksimalisht kontejneri përpara se të fillojë mbytja:
- CPU - kombinim
cpu-periodиcpu-quota. cpus = 1.5ekuivalente me vendosjencpu-period = 100000иcpu-quota = 150000; - CPU-periudha - periudha , e paracaktuar 100 mikrosekonda;
- cpu-kuota - numri i mikrosekondave brenda
cpu-period, i cili kufizohet nga kontejneri.
Çfarë ndodh nëse instaloni një CPU të pamjaftueshme të kërkuar?
Nëse kontejneri ka nevojë për më shumë sesa ka instaluar, ai do të vjedhë CPU nga proceset e tjera.
Çfarë ndodh nëse e vendosni kufirin e CPU-së shumë të ulët?
Meqenëse burimi i CPU-së është i rregullueshëm, mbytja do të aktivizohet.
Çfarë ndodh nëse nuk specifikoni një kërkesë CPU?
Ashtu si me kujtesën, vlera e kërkesës është e barabartë me kufirin.
Çfarë ndodh nëse nuk specifikoni një kufi të CPU-së?
Kontejneri do të përdorë aq CPU sa i nevojitet. Nëse një politikë e parazgjedhur e CPU-së (LimitRange) është përcaktuar në hapësirën e emrave, atëherë ky kufi përdoret gjithashtu për kontejnerin.
Çfarë ndodh nëse nuk specifikoni një kërkesë ose një kufi CPU?
Ashtu si me kujtesën, ky është skenari më i keq. Planifikuesi nuk e di se sa burime ka nevojë për kontejnerin tuaj dhe kjo mund të shkaktojë probleme serioze në nyje. Për të shmangur këtë, ju duhet të vendosni kufijtë e paracaktuar për hapësirat e emrave (LimitRange).
Mbani mend: nëse kërkoni më shumë CPU sesa mund të ofrojnë nyjet, Pod nuk do të planifikohet. Requests.cpu - jo vlera minimale, por një vlerë e mjaftueshme për të nisur Pod dhe për të punuar pa dështime. Nëse aplikacioni nuk kryen llogaritje komplekse, opsioni më i mirë është instalimi request.cpu <= 1 dhe lëshoni sa më shumë kopje të nevojshme.
Sasia ideale e burimeve të kërkuara ose kufiri i burimeve
Mësuam për kufizimin e burimeve kompjuterike. Tani është koha për t'iu përgjigjur pyetjes: "Sa burime kërkon Pod-i im për të ekzekutuar aplikacionin pa asnjë problem? Cila ë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 ose sa CPU ose memorie i nevojitet, alternativa më e mirë është t'i jepni aplikacionit shumë memorie dhe CPU dhe më pas të kryeni testet e performancës.
Përveç testeve të performancës, monitoroni sjelljen e aplikacionit në monitorim për një javë. Nëse grafikët tregojnë se aplikacioni juaj po konsumon më pak burime sesa keni kërkuar, mund të zvogëloni sasinë e CPU-së ose të memories së kërkuar.
Si shembull shikoni këtë . Ai shfaq ndryshimin midis burimeve të kërkuara ose kufirit të burimit dhe përdorimit aktual të burimit.
Përfundim
Kërkimi dhe kufizimi i burimeve ndihmon për ta mbajtur grupin tuaj Kubernetes të shëndetshëm. Konfigurimi i duhur i kufirit minimizon kostot dhe i mban aplikacionet të funksionojnë në çdo kohë.
Me pak fjalë, ka disa gjëra që duhen mbajtur parasysh:
- Burimet e kërkuara janë një konfigurim që merret parasysh në kohën e fillimit (kur Kubernetes planifikon të presë aplikacionin). Në të kundërt, kufizimi i burimeve është i rëndësishëm në kohën e ekzekutimit - kur aplikacioni tashmë po funksionon në nyje.
- Krahasuar me kujtesën, CPU është një burim i rregulluar. Nëse nuk ka mjaftueshëm CPU, Pod-i juaj nuk do të fiket dhe mekanizmi i mbytjes do të ndizet.
- Burimet e kërkuara dhe kufiri i burimeve nuk janë vlera minimale dhe maksimale! Duke përcaktuar burimet e kërkuara, ju siguroheni që aplikacioni të funksionojë pa probleme.
- Një praktikë e mirë është vendosja e kërkesës për memorie të barabartë me kufirin e memories.
- Kërkohet instalimi në rregull
CPU <=1, nëse aplikacioni nuk kryen llogaritje komplekse. - Nëse kërkoni më shumë burime sesa janë të disponueshme në një nyje, Pod nuk do të planifikohet kurrë në atë nyje.
- Për të përcaktuar sasinë e saktë të burimeve/kufizimeve të burimeve të kërkuara, përdorni testimin dhe monitorimin e ngarkesës.
Shpresoj që ky artikull t'ju ndihmojë të kuptoni konceptin bazë të kufizimit të burimeve. Dhe ju do të jeni në gjendje t'i zbatoni këto njohuri në punën tuaj.
Good Luck!
Çfarë tjetër për të lexuar:
- .
- .
- .
Burimi: www.habr.com