Reeglina on alati vaja anda rakendusele spetsiaalne ressursside kogum selle korrektseks ja stabiilseks tööks. Aga mis siis, kui mitu rakendust töötab samal vĂ”imsusel? Kuidas tagada igaĂŒhele neist minimaalselt vajalikke ressursse? Kuidas piirata ressursside tarbimist? Kuidas koormust sĂ”lmede vahel Ă”igesti jaotada? Kuidas tagada horisontaalse skaleerimismehhanismi toimimine, kui rakenduse koormus suureneb?
Peate alustama sellest, millised peamised ressursside tĂŒĂŒbid sĂŒsteemis on - see on loomulikult protsessori aeg ja RAM. K8s manifestides mÔÔdetakse neid ressursitĂŒĂŒpe jĂ€rgmistes ĂŒhikutes:
- CPU - tuumades
- RAM - baitides
Lisaks on iga ressursi jaoks vĂ”imalik seada kahte tĂŒĂŒpi nĂ”udeid - Taotlusi Đž piirid. PĂ€ringud â kirjeldab miinimumnĂ”udeid sĂ”lme vabade ressursside jaoks konteineri (ja kogu mahuti) kĂ€itamiseks, piirangud aga seavad konteinerile saadaolevatele ressurssidele range piirangu.
Oluline on mĂ”ista, et manifest ei pea selgelt mÀÀratlema mĂ”lemat tĂŒĂŒpi, kuid kĂ€itumine on jĂ€rgmine:
- Kui selgesÔnaliselt on mÀÀratud ainult ressursi piirangud, vÔtavad selle ressursi pÀringud automaatselt vÀÀrtuse, mis on vÔrdne piirangutega (saate seda kontrollida, kutsudes vÀlja kirjelduse olemite). Need. tegelikult on konteiner piiratud sama hulga ressurssidega, mida see kÀitamiseks vajab.
- Kui ressursile on selgesĂ”naliselt mÀÀratud ainult pĂ€ringud, siis sellele ressursile ĂŒlemisi piiranguid ei sea â st. konteinerit piiravad ainult sĂ”lme enda ressursid.
Samuti on vÔimalik konfigureerida ressursside haldust mitte ainult konkreetse konteineri tasemel, vaid ka nimeruumi tasemel, kasutades jÀrgmisi oleme:
- LimitRange â kirjeldab piirangupoliitikat konteineri/kauna tasemel ns-des ja on vajalik konteineri/kauna vaikepiirangute kirjeldamiseks, samuti ilmselgelt rasvamahutite/kaunade loomise vĂ€ltimiseks (vĂ”i vastupidi), nende arvu piiramiseks ning mÀÀrake piirangute ja taotluste vÀÀrtuste vĂ”imalik erinevus
- Ressursikvoodid â kirjeldage ĂŒldiselt piirangupoliitikat kĂ”igi ns-i konteinerite jaoks ja seda kasutatakse reeglina keskkondade vahel ressursside piiritlemiseks (kasulik, kui keskkonnad ei ole sĂ”lme tasemel rangelt piiritletud)
JÀrgmised nÀited manifestidest, mis seavad ressursipiirangud.
Konkreetse konteineri tasemel:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mNeed. sel juhul vajate nginxiga konteineri kÀitamiseks vÀhemalt 1 G vaba RAM-i ja sÔlmes 0.2 CPU-d, samas kui konteiner vÔib tarbida maksimaalselt 0.2 protsessorit ja kogu sÔlmes saadaolevat RAM-i.
TĂ€isarvu tasemel ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiNeed. kĂ”igi pĂ€ringukonteinerite summa vaikevÀÀrtuses ns ei tohi ĂŒletada 300 m CPU ja 1G OP puhul ning kĂ”igi piirangute summa on 700 m CPU ja 2G OP jaoks.
Konteineride vaikepiirangud ns-is:
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: 4GiNeed. kÔigi konteinerite vaikenimeruumis seatakse pÀringuks CPU jaoks 100 m ja OP jaoks 1G, piirang - 1 CPU ja 2G. Samal ajal on seatud limiit ka CPU (50m < x < 2) ja RAM (500M < x < 4G) pÀringu/limiidi vÔimalikele vÀÀrtustele.
Poditaseme piirangud ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiNeed. Iga vaikeseadete ns-i jaoks on limiit 4 vCPU ja 1G.
NĂŒĂŒd tahaksin teile öelda, milliseid eeliseid vĂ”ib nende piirangute seadmine meile anda.
Koormuse tasakaalustamise mehhanism sÔlmede vahel
Nagu teate, vastutab k8s komponent kaunade jaotamise eest sÔlmede vahel, nÀiteks planeerija, mis töötab kindla algoritmi jÀrgi. See algoritm lÀbib kÀivitamiseks optimaalse sÔlme valimisel kaks etappi:
- filtreerimine
- Ulatus
Need. vastavalt kirjeldatud poliitikale valitakse algselt sĂ”lmed, millel on vĂ”imalik komplekti alusel pod kĂ€ivitada predikaadid (sealhulgas kontrollimine, kas sĂ”lmel on podi kĂ€itamiseks piisavalt ressursse â PodFitsResources), ja seejĂ€rel kĂ”igi nende sĂ”lmede jaoks vastavalt prioriteedid antakse punkte (sealhulgas, mida rohkem vabu ressursse sĂ”lmel on, seda rohkem punkte talle mÀÀratakse - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ja pod kĂ€ivitatakse kĂ”ige rohkem punkte kogunud sĂ”lmes (kui mitu sĂ”lme vastavad sellele tingimusele korraga, siis valitakse juhuslik).
Samal ajal peate mÔistma, et planeerija juhindub sÔlme saadaolevate ressursside hindamisel andmetest, mis on salvestatud etcd-sse - st. iga selles sÔlmes töötava podi taotletud/limiitressursi kogusele, kuid mitte tegelikule ressursitarbimisele. Seda teavet saab kÀsu vÀljundist kubectl describe node $NODE, nÀiteks:
# 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%)Siin nÀeme kÔiki konkreetses sÔlmes töötavaid kaustasid ja ka ressursse, mida iga pod taotleb. Ja plaanija logid nÀevad vÀlja, kui kÀivitatakse cronjob-cron-events-1573793820-xt6q9 pod (see teave kuvatakse plaanija logis, kui mÀÀrate kÀivituskÀsu argumentides 10. logimistaseme):
logi
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-s10Siin nÀeme, et algselt filtreerib ja genereerib ajakava 3 sÔlme loendi, millel seda saab kÀivitada (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). SeejÀrel arvutab see iga sÔlme jaoks mitme parameetri (sh BalancedResourceAllocation, LeastResourceAllocation) pÔhjal hinded, et mÀÀrata kÔige sobivam sÔlm. LÔppkokkuvÔttes plaanitakse pod kÔige suurema punktide arvuga sÔlmele (siin on kahel sÔlmel korraga sama arv punkte 100037, seega valitakse juhuslik - nxs-k8s-s10).
VĂ€ljund: kui sĂ”lm kĂ€itab podisid, millele piiranguid pole seatud, siis k8-de puhul (ressursitarbimise seisukohalt) on see samavÀÀrne sellega, nagu sellel sĂ”lmel selliseid podeid ĂŒldse polekski. Seega, kui teil on tingimuslikult ahvatleva protsessiga pod (nĂ€iteks wowza) ja sellele pole seatud mingeid piiranguid, vĂ”ib tekkida olukord, kus see pod sĂ”i tegelikult Ă€ra kĂ”ik sĂ”lme ressursid, kuid k8s jaoks see sĂ”lm loetakse koormatuks ja sellele antakse sama arv punkte, kui jĂ€rjestatakse (tĂ€pselt olemasolevaid ressursse hindavate punktide kaupa) kui sĂ”lme, millel pole töötavaid kausid, mis vĂ”ib lĂ”ppkokkuvĂ”ttes viia koormuse ebaĂŒhtlase jaotumiseni sĂ”lmede vahel.
Podi vÀljatÔstmine
Nagu teate, on igale podile mÀÀratud ĂŒks kolmest QoS-klassist:
- garanteeritud â mÀÀratakse, kui iga podi konteineri jaoks on mÀÀratud pĂ€ring ja limiit mĂ€lu ja protsessori jaoks ning need vÀÀrtused peavad ĂŒhtima
- purunev â vĂ€hemalt ĂŒhel kaustas oleval konteineril on pĂ€ring ja limiit, nĂ”udega < limiit
- parim pingutus â kui kaustas pole ĂŒhegi konteineri ressursse piiratud
Samal ajal, kui sÔlmel tekib ressursside (ketas, mÀlu) nappus, hakkab kubelet podide jÀrjestamist ja vÀljatÔstmist vastavalt konkreetsele algoritmile, mis vÔtab arvesse podi prioriteeti ja selle QoS-klassi. NÀiteks kui me rÀÀgime RAM-ist, siis QoS-klassi alusel antakse punkte jÀrgmiselt:
- Tagatud: -998
- BestEffort: 1000
- Pursutav: min(max(2, 1000 - (1000 * mÀlutaotlusbaiti) / masina mÀlumaht, 999)
Need. sama prioriteediga tÔstab kubelet esmalt sÔlmest vÀlja parima QoS-klassiga podid.
VÀljund: kui soovite vÀhendada tÔenÀosust, et soovitud pod sÔlmest vÀlja tÔstetakse, kui sellel ressursse napib, siis peate lisaks prioriteedile hoolitsema ka selle taotluse/limiidi seadmise eest.
Rakendusmoodulite horisontaalse automaatskaleerimise mehhanism (HPA)
Kui ĂŒlesandeks on podide arvu automaatne suurendamine ja vĂ€hendamine sĂ”ltuvalt ressursside kasutamisest (sĂŒsteem - CPU/RAM vĂ”i kasutaja - rps), on selline k8s ĂŒksus nagu HPA (Horizontal Pod Autoscaler). Mille algoritm on jĂ€rgmine:
- MÀÀratakse vaadeldava ressursi praegused nÀidud (currentMetricValue)
- MÀÀratakse ressursi soovitud vÀÀrtused (desiredMetricValue), mis sĂŒsteemiressursside jaoks mÀÀratakse pĂ€ringu abil
- MÀÀratakse praegune koopiate arv (praegused koopiad)
- JĂ€rgmine valem arvutab soovitud arvu koopiaid (soovitud koopiad)
wishReplicas = [ currentReplicas * ( currentMetricValue / soovitudMetricValue )]
Sel juhul skaleerimist ei toimu, kui koefitsient (currentMetricValue / wishMetricValue) on 1 lÀhedal (sel juhul saame lubatava vea ise mÀÀrata; vaikimisi on see 0.1).
Vaatame, kuidas hpa töötab, kasutades rakenduste testimise rakendust (kirjeldatud kui Deployment), kus on vaja muuta koopiate arvu sÔltuvalt protsessori tarbimisest:
Rakenduse manifest
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-statusNeed. nĂ€eme, et rakenduste komplekt kĂ€ivitatakse algselt kahel juhul, millest igaĂŒks sisaldab kahte nginxi ja nginx-eksportija konteinerit, millest igaĂŒhe jaoks on mÀÀratud Taotlusi protsessori jaoks.
HPA manifest
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: 30Need. LÔime hpa, mis jÀlgib juurutamise rakenduse testi ja reguleerib rakendusega kabiinide arvu protsessori indikaatori alusel (eeldame, et pod peaks tarbima 30% nÔutavast protsessorist), kusjuures koopiate arv on vahemikus 2-10.
Vaatame nĂŒĂŒd hpa töömehhanismi, kui rakendame ĂŒhele koldele koormuse:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Kokku on meil jÀrgmised asjad:
- Soovitud vÀÀrtus (desiredMetricValue) - vastavalt hpa sÀtetele on meil 30%
- Praegune vÀÀrtus (currentMetricValue) - arvutamiseks arvutab kontroller-haldur ressursitarbimise keskmise vÀÀrtuse %, s.o. tingimuslikult teeb jÀrgmist:
- Saab mÔÔdikuserverist vastu pod-mÔÔdikute absoluutvÀÀrtused, st. 101m ja 4m
- Arvutab keskmise absoluutvÀÀrtuse, s.o. (101m + 4m) / 2 = 53m
- Saab soovitud ressursitarbimise absoluutvÀÀrtuse (selleks summeeritakse kÔigi konteinerite nÔuded) 60m + 30m = 90m
- Arvutab keskmise CPU tarbimise protsendi pÀringupodi suhtes, st. 53 m / 90 m * 100% = 59%
NĂŒĂŒd on meil kĂ”ik, mida vajame, et teha kindlaks, kas me peame koopiate arvu muutma; selleks arvutame koefitsiendi:
ratio = 59% / 30% = 1.96
Need. koopiate arvu tuleks suurendada ~2 korda ja see peaks olema [2 * 1.96] = 4.
JÀreldus: Nagu nÀete, on selle mehhanismi toimimiseks vajalik tingimus kÔigi vaadeldavas kaustas olevate konteinerite pÀringute olemasolu.
SÔlmede horisontaalse automaatse skaleerimise mehhanism (Cluster Autoscaler)
KoormustĂ”usu ajal sĂŒsteemi negatiivse mĂ”ju neutraliseerimiseks ei piisa konfigureeritud hpa-st. NĂ€iteks otsustab ta hpa kontrollerihalduri seadistuste jĂ€rgi, et koopiate arvu tuleb 2 korda suurendada, kuid sĂ”lmedel ei ole vabu ressursse sellise arvu podide kĂ€itamiseks (st sĂ”lm ei saa anda taotletud ressursid taotluste kaustasse) ja need kaustad lĂŒlituvad olekusse Ootel.
Sel juhul, kui pakkujal on vastav IaaS/PaaS (nÀiteks GKE/GCE, AKS, EKS vms), on selline tööriist nagu SÔlme automaatne skaleerija. See vÔimaldab teil mÀÀrata klastris maksimaalse ja minimaalse sÔlmede arvu ning kohandada automaatselt praegust sÔlmede arvu (helistades pilveteenuse pakkuja API-le sÔlme tellimiseks/eemaldamiseks), kui klastris ja kaustades on ressursside puudus. ei saa ajastada (on ootel olekus).
JÀreldus: SÔlmede automaatseks skaleerimiseks on vaja seada pÀringud pod-konteinerites, et k8-d saaksid Ôigesti hinnata sÔlmede koormust ja vastavalt teatada, et klastris pole ressursse jÀrgmise podi kÀivitamiseks.
JĂ€reldus
Tuleb mÀrkida, et konteineri ressursipiirangute mÀÀramine ei ole rakenduse edukaks tööks nÔue, kuid parem on seda teha jÀrgmistel pÔhjustel:
- Planeerija tÀpsemaks tööks k8s sÔlmede vahelise koormuse tasakaalustamise osas
- "Kauna vĂ€ljatĂ”stmise" sĂŒndmuse tĂ”enĂ€osuse vĂ€hendamiseks
- Rakendusmoodulite (HPA) horisontaalse automaatse skaleerimise jaoks
- SÔlmede horisontaalseks automaatseks skaleerimiseks (Cluster Autoscaling) pilveteenuse pakkujatele
Loe ka teisi meie ajaveebi artikleid:
Allikas: www.habr.com
