Oro har, beti dago aplikazio bati baliabide dedikatu bat eskaintzea bere funtzionamendu zuzen eta egonkorra izan dadin. Baina zer gertatzen da hainbat aplikazio potentzia berean exekutatzen ari badira? Nola eman horietako bakoitzari beharrezko gutxieneko baliabideak? Nola mugatu dezakezu baliabideen kontsumoa? Nola banatu karga behar bezala nodoen artean? Nola ziurtatu eskalatze horizontaleko mekanismoak funtzionatzen duela aplikazioaren karga handitzen bada?
Sisteman zer baliabide mota nagusi dauden hasi behar duzu - hau, noski, prozesadorearen denbora eta RAM da. k8s manifestetan baliabide mota hauek unitate hauetan neurtzen dira:
- CPU - nukleoetan
- RAM - bytetan
Gainera, baliabide bakoitzeko bi baldintza mota ezar daitezke - eskaerak ΠΈ mugak. Eskaerak - edukiontzi bat exekutatzeko nodo baten doako baliabideen gutxieneko baldintzak deskribatzen ditu (eta poda oro har), mugak, berriz, edukiontziaren eskura dauden baliabideen muga gogorra ezartzen du.
Garrantzitsua da ulertzea manifestuak ez dituela bi motak esplizituki definitu behar, baina portaera hau izango da:
- Baliabide baten mugak soilik esplizituki zehazten badira, baliabide honen eskaerek automatikoki mugen balio berdina hartzen dute (deskribatzeko entitateei deituz egiazta dezakezu hori). Horiek. izan ere, edukiontzia martxan jartzeko behar duen baliabide kopuru berdinera mugatuko da.
- Baliabide baterako eskaerak esplizituki zehazten badira soilik, orduan ez da goiko murrizketarik ezartzen baliabide honetan, hau da. edukiontzia nodoaren beraren baliabideek soilik mugatzen dute.
Baliabideen kudeaketa edukiontzi zehatz baten mailan ez ezik, izen-espazio mailan ere konfiguratu daiteke, entitate hauek erabiliz:
- Limit Range β edukiontzi/pod mailan murrizketa-politika deskribatzen du ns-tan eta beharrezkoa da edukiontzi/pod-en muga lehenetsiak deskribatzeko, baita argi eta garbi ontzi/podak sortzea saihesteko (edo alderantziz), haien kopurua mugatzeko. eta muga eta eskaeren balioetan izan daitekeen aldea zehaztu
- Baliabide-kuotak β ns-ko edukiontzi guztien murrizketa-politika orokorrean deskribatu eta, oro har, baliabideak inguruneen artean mugatzeko erabiltzen da (erabilgarria inguruneak nodo mailan zorrotz mugatzen ez direnean)
Honako hauek dira baliabideen mugak ezartzen dituzten manifestuen adibideak:
-
Edukiontzi maila espezifikoan:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mHoriek. kasu honetan, nginx-ekin edukiontzi bat exekutatzeko, gutxienez 1G RAM libre eta 0.2 CPU beharko dituzu nodoan, gehienez ere edukiontziak 0.2 CPU eta nodoan eskuragarri dagoen RAM guztia kontsumitu dezakeen bitartean.
-
ns osoko mailan:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiHoriek. ns lehenetsitako eskaera-edukiontzi guztien batura ezin da 300m gainditu CPUrako eta 1G OPrako, eta muga guztien batura 700m da CPUrako eta 2G OPrako.
-
ns-ko edukiontzien muga lehenetsiak:
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: 4GiHoriek. edukiontzi guztien izen-espazio lehenetsian, eskaera 100m ezarriko da CPUrako eta 1G OPrako, muga - 1 CPU eta 2G. Aldi berean, CPU (50m < x < 2) eta RAM (500M < x < 4G) eskaera/mugan izan daitezkeen balioei ere muga bat ezartzen zaie.
-
Pod-mailako murrizketak ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiHoriek. ns lehenetsiko pod bakoitzeko 4 vCPU eta 1G-ko muga egongo da.
Orain murrizketa hauek ezartzeak zer abantaila ekar diezazkigukeen esan nahiko nuke.
Nodoen arteko karga orekatzeko mekanismoa
Dakizuenez, k8s osagaia nodoen artean lekak banatzeaz arduratzen da, adibidez antolatzaileak, algoritmo zehatz baten arabera funtzionatzen duena. Algoritmo honek bi fase igarotzen ditu abiarazteko nodo optimoa hautatzeko orduan:
- iragazte
- Sortzen
Horiek. deskribatutako politikaren arabera, hasiera batean nodoak hautatzen dira eta horietan multzo batean oinarritutako pod bat abiarazteko aukera dago predikatuak (nodoak pod-a exekutatzeko nahikoa baliabide dituen egiaztatzea barne - PodFitsResources), eta gero nodo horietako bakoitzarentzat, arabera lehentasunak puntuak ematen dira (nodo batek zenbat eta baliabide libre gehiago izan, orduan eta puntu gehiago esleitzen zaizkio - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) eta poda puntu gehien dituen nodoan abiarazten da (hainbat nodok baldintza hori betetzen badute, orduan ausaz bat aukeratzen da).
Aldi berean, planifikatzaileak, nodo baten baliabide erabilgarrien ebaluazioan, etcd-n gordetzen diren datuek gidatzen dutela ulertu behar duzu - hau da. Nodo honetan exekutatzen den pod bakoitzaren eskatutako/mugatzeko baliabidearen zenbatekoagatik, baina ez benetako baliabideen kontsumoagatik. Informazio hori komandoaren irteeratik lor daiteke kubectl describe node $NODE, adibidez:
# 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%)Hemen nodo zehatz batean exekutatzen diren pod guztiak ikusiko ditugu, baita pod bakoitzak eskatzen dituen baliabideak ere. Eta hona hemen programatzaileen erregistroak cronjob-cron-events-1573793820-xt6q9 pod-a abiarazten denean (informazio hau abiarazteko komandoaren argumentuetan -v=10) 10. erregistro-maila ezartzen duzunean antolatzailearen erregistroan agertuko da):
erregistroa
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-s10Hemen ikusten dugu hasieran programatzaileak abiarazteko 3 nodoen zerrenda iragazten eta sortzen duela (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Ondoren, hainbat parametrotan oinarritutako puntuazioak kalkulatzen ditu (BalanedResourceAllocation, LeastResourceAllocation barne) nodo horietako bakoitzarentzat, nodo egokiena zein den zehazteko. Azken finean, poda puntu kopuru handiena duen nodoan programatzen da (hemen bi nodok aldi berean 100037 puntu kopuru bera dute, beraz, ausazko bat hautatzen da - nxs-k8s-s10).
Irteera: nodo batek murrizketarik ezartzen ez dituen pods-ak exekutatzen baditu, orduan k8-etarako (baliabideen kontsumoaren ikuspuntutik) hau nodo honetan halako podik ez balego bezala baliokidea izango da. Hori dela eta, baldintzapean prozesu gluttocious bat duen pod bat baduzu (adibidez, wowza) eta ez bada murrizketarik ezartzen, orduan egoera bat sor daiteke pod honek nodoaren baliabide guztiak jaten dituenean, baina k8s-entzat nodo honek deskargatutzat jotzen da eta puntu kopuru bera emango zaio sailkapenean (eskura daitezkeen baliabideak ebaluatzeko puntuetan, hain zuzen) funtzionatzen duen lekak ez dituen nodo batek, azken finean, nodoen arteko kargaren banaketa irregularra ekar dezake.
Pod-en desalojoa
Dakizuenez, pod bakoitzari 3 QoS klaseetako bat esleitzen zaio:
- bermatuta β Pod-eko edukiontzi bakoitzeko memoriarako eta CPUrako eskaera eta muga zehazten direnean esleitzen da, eta balio hauek bat etorri behar dute
- lehergarria β Gutxienez ontziko edukiontzi batek eskaera eta muga bat ditu, eskaera < mugarekin
- ahalegin onena β ontzian edukiontzi bakar bat ere baliabide mugatua ez denean
Aldi berean, nodo batek baliabide falta jasaten duenean (diskoa, memoria), kubelet-ek pod-aren lehentasuna eta bere QoS klasea kontuan hartzen dituen algoritmo zehatz baten arabera sailkatzen eta kanporatzen hasten da. Adibidez, RAMari buruz ari bagara, QoS klasean oinarrituta, puntuak hurrengo printzipioaren arabera ematen dira:
- Bermatuta: -998
- BestEffort: 1000
- Lehergarria: min (gehienez (2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Horiek. lehentasun berarekin, kubelet-ak lehenik QoS klaseko ahaleginik onena duten lekak kanporatuko ditu nodotik.
Irteera: nahi duzun poda nodotik kanporatzeko probabilitatea murriztu nahi baduzu baliabide faltaren kasuan, orduan lehentasunarekin batera, eskaera/muga ezartzeaz ere arduratu beharko zara.
Aplikazio-ontzien eskalatze automatiko horizontalerako mekanismoa (HPA)
Zereginak baliabideen erabileraren (sistema - CPU/RAM edo erabiltzailea - rps) arabera automatikoki handitu eta murriztea denean, hala nola k8s entitate bat. HPa (Horizontal Pod Autoscaler). Horren algoritmoa honako hau da:
- Behatutako baliabidearen uneko irakurketak zehazten dira (currentMetricValue)
- Baliabiderako nahi diren balioak zehazten dira (desiredMetricValue), sistemaren baliabideetarako eskaera erabiliz ezartzen direnak.
- Uneko erreplika kopurua zehazten da (currentReplicas)
- Hurrengo formulak nahi den erreplika kopurua kalkulatzen du (desiredReplicas)
wishReplicas = [ currentReplicas * ( currentMetricValue / wantMetricValue )]
Kasu honetan, eskalatzea ez da gertatuko koefizientea (currentMetricValue / wantMetricValue) 1etik gertu dagoenean (kasu honetan, guk geuk ezar dezakegu baimendutako errorea; lehenespenez 0.1 da).
Ikus dezagun hpa-k nola funtzionatzen duen app-test aplikazioaren adibidea erabiliz (Deployment gisa deskribatua), non beharrezkoa den erreplika kopurua PUZaren kontsumoaren arabera aldatzea:
-
Aplikazioaren manifestua
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-statusHoriek. ikusten dugu aplikazio-potea hasiera batean bi instantziatan abiarazten dela, eta horietako bakoitzak bi nginx eta nginx-exporter edukiontzi ditu, horietako bakoitzean zehaztutako bat. eskaerak CPUrako.
-
HPA Manifestua
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: 30Horiek. Inplementazio aplikazioaren proba kontrolatuko duen hpa bat sortu dugu eta aplikazioarekin pods kopurua egokituko du CPU-adierazlearen arabera (eskatzen duen PUZaren % 30 kontsumitu beharko duela espero dugu), erreplika kopurua barne. 2-10 bitartekoa.
Orain, ikus dezagun hpa funtzionamenduaren mekanismoa sutegietako bati karga bat aplikatzen badiogu:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Guztira honako hauek ditugu:
- Nahi den balioa (desiredMetricValue) - hpa ezarpenen arabera, % 30 dugu
- Uneko balioa (currentMetricValue) - kalkulurako, kontroladore-kudeatzaileak baliabideen kontsumoaren batez besteko balioa %-tan kalkulatzen du, hau da. baldintzapean honako hau egiten du:
- Pod metrikaren balio absolutuak jasotzen ditu metrika zerbitzaritik, hau da. 101m eta 4m
- Batez besteko balio absolutua kalkulatzen du, hau da. (101m + 4m) / 2 = 53m
- Nahi den baliabide-kontsumoaren balio absolutua lortzen du (horretarako, edukiontzi guztien eskaerak batzen dira) 60m + 30m = 90m
- PUZaren kontsumoaren batez besteko ehunekoa kalkulatzen du eskaera-podarekiko, hau da. 53 m / 90 m * % 100 = % 59
Orain erreplika kopurua aldatu behar dugun zehazteko behar dugun guztia daukagu; horretarako, koefizientea kalkulatuko dugu:
ratio = 59% / 30% = 1.96
Horiek. erreplika kopurua ~ 2 aldiz handitu behar da eta [2 * 1.96] = 4 izan behar du.
Ondorioa: Ikus dezakezunez, mekanismo honek funtziona dezan, beharrezko baldintza da behatutako ontzian edukiontzi guztien eskaerak egotea.
Nodoen autoeskala horizontalerako mekanismoa (Cluster Autoscaler)
Karga igoeran sistemaren eragin negatiboa neutralizatzeko, hpa konfiguratua izatea ez da nahikoa. Esate baterako, hpa kontroladorearen kudeatzailearen ezarpenen arabera, erreplika kopurua 2 aldiz handitu behar dela erabakitzen du, baina nodoek ez dute baliabiderik doako pods kopuru hori exekutatzeko (hau da, nodoak ezin du eman eskatutako baliabideak eskaeren ontzira) eta ontzi horiek Zain egoerara aldatzen dira.
Kasu honetan, hornitzaileak dagokion IaaS/PaaS bat badu (adibidez, GKE/GCE, AKS, EKS, etab.), bezalako tresna bat. Nodo Autoscaler. Klusterrean gehienezko eta gutxieneko nodo kopurua ezartzeko eta uneko nodo kopurua automatikoki doitzeko aukera ematen du (hodeiko hornitzailearen APIra deituz nodo bat eskatzeko/kentzeko) baliabide falta dagoenean klusterrean eta podetan. ezin dira programatu (Zein egoeran daude).
Ondorioa: Nodoak automatikoki eskalatu ahal izateko, beharrezkoa da eskaerak ezartzea pod edukiontzietan, k8s-ek nodoen karga behar bezala ebaluatu ahal izateko eta, horren arabera, klusterrean hurrengo poda abiarazteko baliabiderik ez dagoela jakinarazi.
Ondorioa
Kontuan izan behar da edukiontzien baliabideen mugak ezartzea ez dela betekizuna aplikazioa behar bezala exekutatzeko, baina hala ere hobe dela arrazoi hauengatik:
- K8s nodoen arteko karga orekatzeari dagokionez, programatzailearen funtzionamendu zehatzagoa lortzeko
- "Pod desalojo" gertaera bat gertatzeko probabilitatea murrizteko
- Aplikazio-ontzien (HPA) eskalatze automatiko horizontala funtziona dezan
- Nodoen autoeskala horizontalerako (Cluster Autoscaling) hodeiko hornitzaileentzako
Irakurri beste artikulu batzuk ere gure blogean:
Iturria: www.habr.com