Að jafnaði er alltaf þörf á að útvega sérstakan hóp af auðlindum til umsóknar fyrir réttan og stöðugan rekstur hennar. En hvað ef mörg forrit keyra á sama krafti? Hvernig á að veita hverjum þeirra lágmarks nauðsynleg úrræði? Hvernig er hægt að takmarka auðlindanotkun? Hvernig á að dreifa álaginu rétt á milli hnúta? Hvernig á að tryggja að lárétt stærðarbúnaður virki ef álag á forrit eykst?
Þú þarft að byrja á því hvaða helstu auðlindir eru til í kerfinu - þetta er auðvitað örgjörvatími og vinnsluminni. Í k8s birtingarmyndum eru þessar auðlindagerðir mældar í eftirfarandi einingum:
- CPU - í kjarna
- RAM - í bætum
Þar að auki, fyrir hverja auðlind er hægt að setja tvenns konar kröfur - beiðnir и mörk. Beiðnir - lýsir lágmarkskröfum fyrir ókeypis auðlindir hnúts til að keyra gám (og belg í heild), en takmarkanir setja hörð takmörk á auðlindir sem eru í boði fyrir gáminn.
Mikilvægt er að skilja að upplýsingaskráin þarf ekki að skilgreina báðar tegundir skýrt, heldur verður hegðunin sem hér segir:
- Ef aðeins mörk auðlindar eru sérstaklega tilgreind, þá taka beiðnir um þessa auðlind sjálfkrafa gildi sem jafngildir mörkum (þú getur staðfest þetta með því að kalla lýsa einingar). Þeir. í raun verður gámurinn takmarkaður við sama magn af auðlindum og það þarf til að keyra.
- Ef aðeins beiðnir eru sérstaklega tilgreindar fyrir auðlind, þá eru engar efri takmarkanir settar á þessa auðlind - þ.e. ílátið er aðeins takmarkað af auðlindum hnútsins sjálfs.
Það er líka mögulegt að stilla auðlindastjórnun, ekki aðeins á stigi tiltekins gáms, heldur einnig á nafnrýmisstigi með því að nota eftirfarandi einingar:
- LimitRange — lýsir takmörkunarstefnunni á stigi íláts/belgs í ns og er þörf til að lýsa sjálfgefna takmörkunum á ílátinu/belgnum, sem og koma í veg fyrir að augljóslega feitir ílát/belgur verði til (eða öfugt), takmarka fjölda þeirra og ákvarða mögulegan mun á gildum í takmörkunum og beiðnum
- Auðlindakvótar — lýstu takmörkunarstefnunni almennt fyrir alla gáma í ns og er að jafnaði notuð til að afmarka auðlindir á milli umhverfi (gagnlegt þegar umhverfi er ekki stranglega afmarkað á hnútastigi)
Eftirfarandi eru dæmi um upplýsingaskrá sem setja auðlindatakmörk:
-
Á tilteknu gámastigi:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mÞeir. í þessu tilfelli, til að keyra gám með nginx, þarftu að minnsta kosti 1G af lausu vinnsluminni og 0.2 CPU á hnútnum, en í mesta lagi getur ílátið neytt 0.2 CPU og allt tiltækt vinnsluminni á hnútnum.
-
Á heiltölustigi ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiÞeir. summan af öllum beiðnigámum í sjálfgefna ns getur ekki farið yfir 300m fyrir CPU og 1G fyrir OP, og summan af öllum mörkum er 700m fyrir CPU og 2G fyrir OP.
-
Sjálfgefin mörk fyrir gáma í ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-per-container spec: limits: - type: Container defaultRequest: cpu: 100m memory: 1Gi default: cpu: 1 memory: 2Gi min: cpu: 50m memory: 500Mi max: cpu: 2 memory: 4GiÞeir. í sjálfgefnu nafnrými fyrir alla gáma, beiðni verður stillt á 100m fyrir CPU og 1G fyrir OP, takmörk - 1 CPU og 2G. Á sama tíma eru einnig sett takmörk á mögulegum gildum í beiðni/takmörkum fyrir CPU (50m < x < 2) og vinnsluminni (500M < x < 4G).
-
Takmarkanir á pod-stigi ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiÞeir. fyrir hvern fræbelg í sjálfgefna ns verður hámark 4 vCPU og 1G.
Nú langar mig að segja þér hvaða kosti það getur veitt okkur að setja þessar takmarkanir.
Álagsjafnvægi milli hnúta
Eins og þú veist er k8s hluti ábyrgur fyrir dreifingu fræbelgja á milli hnúta, svo sem tímaáætlun, sem virkar samkvæmt ákveðnum reiknirit. Þetta reiknirit fer í gegnum tvö stig þegar besti hnúturinn er valinn til að ræsa:
- sía
- Fjarlægð
Þeir. Samkvæmt þeirri stefnu sem lýst er eru hnútar upphaflega valdir þar sem hægt er að ræsa belg byggt á setti fordæmi (þar á meðal að athuga hvort hnúturinn hafi nægt fjármagn til að keyra pod - PodFitsResources), og síðan fyrir hvern þessara hnúta, skv. forgangsröðun stig eru veitt (þar á meðal, því fleiri ókeypis auðlindir sem hnútur hefur, því fleiri stig er honum úthlutað - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) og hólfið er ræst á hnútnum með flest stig (ef nokkrir hnútar uppfylla þetta skilyrði í einu, þá er valinn tilviljunarkenndur).
Á sama tíma þarftu að skilja að tímaáætlunarmaðurinn, við mat á tiltækum tilföngum hnúts, er stýrt af gögnunum sem eru geymd í etcd - þ.e. fyrir magn umbeðinnar/takmarka auðlindar hvers fræbelgs sem keyrir á þessum hnút, en ekki fyrir raunverulega auðlindanotkun. Þessar upplýsingar er hægt að fá úr skipunarúttakinu kubectl describe node $NODE, til dæmis:
# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods: (9 in total)
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
ingress-nginx nginx-ingress-controller-754b85bf44-qkt2t 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-flannel-26bl4 150m (0%) 300m (1%) 64M (0%) 500M (1%) 233d
kube-system kube-proxy-exporter-cb629 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system kube-proxy-x9fsc 0 (0%) 0 (0%) 0 (0%) 0 (0%) 233d
kube-system nginx-proxy-k8s-worker-s1 25m (0%) 300m (1%) 32M (0%) 512M (1%) 233d
nxs-monitoring alertmanager-main-1 100m (0%) 100m (0%) 425Mi (1%) 25Mi (0%) 233d
nxs-logging filebeat-lmsmp 100m (0%) 0 (0%) 100Mi (0%) 200Mi (0%) 233d
nxs-monitoring node-exporter-v4gdq 112m (0%) 122m (0%) 200Mi (0%) 220Mi (0%) 233d
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 487m (3%) 822m (5%)
memory 15856217600 (2%) 749976320 (3%)
ephemeral-storage 0 (0%) 0 (0%)Hér sjáum við alla belg sem keyra á tilteknum hnút, sem og tilföngin sem hver belg biður um. Og hér er hvernig tímaáætlunarskrárnar líta út þegar cronjob-cron-events-1573793820-xt6q9 hólfið er ræst (þessar upplýsingar munu birtast í tímaáætlunarskránni þegar þú stillir 10. skráningarstigið í upphafsskipuninni -v=10):
log
I1115 07:57:21.637791 1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.637804 1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9
I1115 07:57:21.638285 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638300 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.
I1115 07:57:21.638322 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638365 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.
I1115 07:57:21.638334 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.
I1115 07:57:21.638385 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.
I1115 07:57:21.638402 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.
I1115 07:57:21.638383 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.
I1115 07:57:21.638335 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.
I1115 07:57:21.638408 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.
I1115 07:57:21.638478 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638505 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638577 1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.
I1115 07:57:21.638583 1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.
I1115 07:57:21.638932 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9
I1115 07:57:21.638946 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8
I1115 07:57:21.638961 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9
I1115 07:57:21.638971 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.638975 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8
I1115 07:57:21.638990 1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7
I1115 07:57:21.639022 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639030 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639034 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)
I1115 07:57:21.639041 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639053 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639059 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)
I1115 07:57:21.639061 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639063 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639073 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639077 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639085 1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)
I1115 07:57:21.639088 1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639103 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639109 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639114 1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)
I1115 07:57:21.639127 1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037
I1115 07:57:21.639150 1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034
I1115 07:57:21.639154 1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037
I1115 07:57:21.639267 1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"
I1115 07:57:21.639286 1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do
I1115 07:57:21.639333 1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10Hér sjáum við að upphaflega síar tímaáætlunarmaðurinn og býr til lista yfir 3 hnúta sem hægt er að ræsa hann á (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Síðan reiknar það út stig út frá nokkrum breytum (þar á meðal BalancedResourceAllocation, LeastResourceAllocation) fyrir hvern þessara hnúta til að ákvarða heppilegasta hnútinn. Að lokum er belgurinn áætlaður á hnútnum með hæsta fjölda punkta (hér eru tveir hnútar í einu með sama fjölda punkta 100037, þannig að valinn er af handahófi - nxs-k8s-s10).
Output: ef hnútur keyrir pods sem engar takmarkanir eru settar fyrir, þá fyrir k8s (frá sjónarhóli auðlindanotkunar) mun þetta jafngilda því að það væru engir slíkir pods á þessum hnút. Þess vegna, ef þú, með skilyrðum, ert með fræbelgur með mathált ferli (til dæmis wowza) og engar takmarkanir eru settar á það, þá getur komið upp sú staða að þessi fræbelgur hafi í raun át allar auðlindir hnútsins, en fyrir k8s þessi hnút. telst óhlaðinn og hann mun hljóta sama fjölda stiga við röðun (nákvæmlega í stigum með mat á tiltækum auðlindum) sem hnút sem hefur ekki vinnubelg, sem á endanum getur leitt til ójafnrar dreifingar álags milli hnúta.
Brottrekstur Pod
Eins og þú veist er hverjum belg úthlutað einum af 3 QoS flokkum:
- tryggð - er úthlutað þegar beiðni og takmörk eru tilgreind fyrir hvern ílát í belgnum fyrir minni og örgjörva og þessi gildi verða að passa saman
- springanlegur — að minnsta kosti einn ílát í belgnum hefur beiðni og takmörk, með beiðni < takmörk
- besta fyrirhöfn — þegar ekki einn einasti ílát í belgnum er takmarkaður auðlind
Á sama tíma, þegar hnút upplifir skort á auðlindum (diskur, minni), byrjar kubelet að raða og reka fræbelg í samræmi við ákveðna reiknirit sem tekur mið af forgangi fræbelgs og QoS flokks hans. Til dæmis, ef við erum að tala um vinnsluminni, þá er miðað við QoS flokkinn, stig veitt samkvæmt eftirfarandi meginreglu:
- Guaranteed: -998
- Besta tilraun: 1000
- Sprengjanlegt: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Þeir. með sama forgangi mun kubelet fyrst útrýma fræbelgjum með besta QoS flokki úr hnútnum.
Output: ef þú vilt draga úr líkunum á því að æskilegur belg sé rekinn úr hnútnum ef það vantar fjármagn á hann, þá ásamt forganginum þarftu líka að sjá um að setja beiðni/takmörk fyrir það.
Vélbúnaður fyrir lárétta sjálfsstærðingu á notkunarbelgjum (HPA)
Þegar verkefnið er að auka og fækka sjálfkrafa fjölda fræbelgja eftir notkun auðlinda (kerfi - CPU/RAM eða notandi - rps), eins og k8s eining eins og HPA (Láréttur Pod Autoscaler). Reikniritið sem er sem hér segir:
- Núverandi aflestur auðlindarinnar sem sést er ákvörðuð (currentMetricValue)
- Æskileg gildi fyrir auðlindina eru ákvörðuð (desiredMetricValue), sem fyrir kerfisauðlindir eru stillt með beiðni
- Núverandi fjöldi eftirmynda er ákvarðaður (núverandi eftirmyndir)
- Eftirfarandi formúla reiknar út æskilegan fjölda eftirmynda (æskilegar eftirmyndir)
óskað eftirmyndir = [ núverandiReplicas * ( núverandiMetricValue / wantedMetricValue )]
Í þessu tilviki mun mælikvarði ekki eiga sér stað þegar stuðullinn (currentMetricValue / wantedMetricValue) er nálægt 1 (í þessu tilfelli getum við stillt leyfilegu villuna sjálf; sjálfgefið er það 0.1).
Við skulum skoða hvernig hpa virkar með því að nota dæmið um app-prófunarforritið (lýst sem Deployment), þar sem nauðsynlegt er að breyta fjölda eftirmynda eftir örgjörvanotkun:
-
Umsóknarskrá
kind: Deployment apiVersion: apps/v1beta2 metadata: name: app-test spec: selector: matchLabels: app: app-test replicas: 2 template: metadata: labels: app: app-test spec: containers: - name: nginx image: registry.nixys.ru/generic-images/nginx imagePullPolicy: Always resources: requests: cpu: 60m ports: - name: http containerPort: 80 - name: nginx-exporter image: nginx/nginx-prometheus-exporter resources: requests: cpu: 30m ports: - name: nginx-exporter containerPort: 9113 args: - -nginx.scrape-uri - http://127.0.0.1:80/nginx-statusÞeir. við sjáum að forritabelgurinn er upphaflega ræstur í tveimur tilfellum, sem hvert um sig inniheldur tvo nginx og nginx-útflytjanda ílát, fyrir hvert þeirra er tilgreint beiðnir fyrir CPU.
-
HPA yfirlýsing
apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: app-test-hpa spec: maxReplicas: 10 minReplicas: 2 scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: app-test metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 30Þeir. Við bjuggum til hpa sem mun fylgjast með Deployment app-prófinu og stilla fjölda pods með forritinu út frá örgjörvavísinum (við gerum ráð fyrir að podinn ætti að eyða 30% af örgjörvanum sem hann biður um), þar sem fjöldi eftirmynda er í á bilinu 2-10.
Nú skulum við líta á gangverk hpa-aðgerða ef við beitum álagi á einn af aflinn:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Alls höfum við eftirfarandi:
- Æskilegt gildi (desiredMetricValue) - samkvæmt hpa stillingunum höfum við 30%
- Núverandi gildi (currentMetricValue) - til útreiknings reiknar stjórnandi-stjórnandi meðalgildi auðlindanotkunar í %, þ.e. skilyrt gerir eftirfarandi:
- Tekur á móti algildum pod-mælingum frá metraþjóninum, þ.e. 101m og 4m
- Reiknar meðalalgildi, þ.e. (101m + 4m) / 2 = 53m
- Fær algildi fyrir æskilega auðlindanotkun (fyrir þetta eru beiðnir allra gáma teknar saman) 60m + 30m = 90m
- Reiknar meðalhlutfall CPU neyslu miðað við beiðni pod, þ.e. 53m / 90m * 100% = 59%
Nú höfum við allt sem við þurfum til að ákvarða hvort við þurfum að breyta fjölda eftirmynda; til að gera þetta reiknum við stuðulinn:
ratio = 59% / 30% = 1.96
Þeir. Fjöldi eftirmynda ætti að aukast um ~2 sinnum og nema [2 * 1.96] = 4.
Ályktun: Eins og þú sérð, til þess að þetta kerfi virki, er nauðsynlegt skilyrði að beiðnir séu fyrir alla ílát í belgnum sem sést.
Vélbúnaður fyrir lárétta sjálfsstærð hnúta (Cluster Autoscaler)
Til þess að óvirkja neikvæð áhrif á kerfið meðan á álagi stendur er ekki nóg að hafa stillt hpa. Til dæmis, samkvæmt stillingum í stjórnanda hpa stjórnanda, ákveður það að fjölga þurfi eftirlíkingum um 2 sinnum, en hnútarnir hafa ekki ókeypis úrræði til að keyra slíkan fjölda belg (þ.e.a.s. hnúturinn getur ekki veitt umbeðnar tilföng í beiðnasafnið) og þessir hólf skipta yfir í biðstöðu.
Í þessu tilviki, ef veitandinn er með samsvarandi IaaS/PaaS (til dæmis GKE/GCE, AKS, EKS, osfrv.), er tæki eins og Node Autoscaler. Það gerir þér kleift að stilla hámarks- og lágmarksfjölda hnúta í þyrpingunni og stilla sjálfkrafa núverandi fjölda hnúta (með því að hringja í API skýjaveitunnar til að panta/fjarlægja hnút) þegar skortur er á fjármagni í þyrpingunni og belgjunum ekki hægt að tímasetja (eru í biðstöðu).
Ályktun: Til að geta sjálfkvörðuð hnúta er nauðsynlegt að stilla beiðnir í belgílátunum þannig að k8s geti metið álagið á hnútana rétt og í samræmi við það tilkynnt að engin úrræði séu í þyrpingunni til að ræsa næsta belg.
Ályktun
Það skal tekið fram að það að setja gámaauðlindamörk er ekki skilyrði til að forritið gangi vel, en það er samt betra að gera það af eftirfarandi ástæðum:
- Fyrir nákvæmari notkun tímaáætlunarbúnaðarins hvað varðar álagsjafnvægi milli k8s hnúta
- Til að draga úr líkum á að „pod eviction“ atburður eigi sér stað
- Til að lárétt sjálfkvörðun á forritabelgjum (HPA) virki
- Fyrir lárétta sjálfstýringu hnúta (Cluster Autoscaling) fyrir skýjaveitur
Lestu einnig aðrar greinar á blogginu okkar:
Heimild: www.habr.com