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