🥇Kubernetes: hoekom is dit so belangrik om stelselhulpbronbestuur op te stel?

As 'n reël is daar altyd 'n behoefte om 'n toegewyde poel hulpbronne aan 'n toepassing te verskaf vir die korrekte en stabiele werking daarvan. Maar wat as verskeie toepassings op dieselfde krag werk? Hoe om aan elkeen van hulle die minimum nodige hulpbronne te voorsien? Hoe kan jy hulpbronverbruik beperk? Hoe om die las korrek tussen nodusse te versprei? Hoe om te verseker dat die horisontale skaalmeganisme werk as die toedieningslas toeneem?

U moet begin met watter hooftipes hulpbronne in die stelsel bestaan - dit is natuurlik verwerkertyd en RAM. In k8s-manifeste word hierdie hulpbrontipes in die volgende eenhede gemeet:

SVE - in kerns
RAM - in grepe

Verder, vir elke hulpbron is dit moontlik om twee tipes vereistes te stel - versoeke и grense. Versoeke - beskryf die minimum vereistes vir gratis hulpbronne van 'n nodus om 'n houer (en peul as 'n geheel) te bestuur, terwyl limiete 'n harde beperking stel op die hulpbronne wat beskikbaar is vir die houer.

Dit is belangrik om te verstaan dat die manifes nie beide tipes eksplisiet hoef te definieer nie, maar die gedrag sal soos volg wees:

As slegs die limiete van 'n hulpbron uitdruklik gespesifiseer word, neem versoeke vir hierdie hulpbron outomaties 'n waarde gelyk aan limiete (jy kan dit verifieer deur beskryf entiteite te noem). Dié. trouens, die houer sal beperk word tot dieselfde hoeveelheid hulpbronne wat dit benodig om te hardloop.
As slegs versoeke uitdruklik vir 'n hulpbron gespesifiseer word, word geen boonste beperkings op hierdie hulpbron gestel nie - m.a.w. die houer word slegs beperk deur die hulpbronne van die nodus self.

Dit is ook moontlik om hulpbronbestuur nie net op die vlak van 'n spesifieke houer op te stel nie, maar ook op die naamruimtevlak deur die volgende entiteite te gebruik:

LimitReik — beskryf die beperkingsbeleid op die houer/peulvlak in ns en is nodig om die versteklimiete op die houer/peul te beskryf, asook om die skep van ooglopend vet houers/peule te voorkom (of omgekeerd), hul getal te beperk en bepaal die moontlike verskil in die waardes in limiete en versoeke
Hulpbronkwotas — beskryf die beperkingsbeleid in die algemeen vir alle houers in ns en word as 'n reël gebruik om hulpbronne tussen omgewings af te baken (nuttig wanneer omgewings nie streng op die nodusvlak afgebaken is nie)

Die volgende is voorbeelde van manifeste wat hulpbronlimiete stel:

Op die spesifieke houervlak:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
Dié. in hierdie geval, om 'n houer met nginx te laat loop, sal jy ten minste 1G vrye RAM en 0.2 SVE op die nodus benodig, terwyl die houer hoogstens 0.2 SVE en alle beskikbare RAM op die knoop kan verbruik.
Op die heelgetalvlak ns:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
Dié. die som van alle versoekhouers in die verstek-ns kan nie 300m vir die SVE en 1G vir die OP oorskry nie, en die som van alle limiet is 700m vir die SVE en 2G vir die OP.

Versteklimiete vir houers in 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

Dié. in die verstek naamruimte vir alle houers, sal versoek gestel word op 100m vir SVE en 1G vir OP, beperk - 1 SVE en 2G. Terselfdertyd word 'n limiet ook gestel op die moontlike waardes in versoek/limiet vir SVE (50m < x < 2) en RAM (500M < x < 4G).

Peulvlakbeperkings ns:

apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi

Dié. vir elke peul in die verstek ns sal daar 'n limiet van 4 vCPU en 1G wees.

Nou wil ek jou graag vertel watter voordele die opstel van hierdie beperkings ons kan gee.

Lasbalanseringsmeganisme tussen nodusse

Soos u weet, is die k8s-komponent verantwoordelik vir die verspreiding van peule onder nodusse, soos skeduleerder, wat volgens 'n spesifieke algoritme werk. Hierdie algoritme gaan deur twee stadiums wanneer die optimale nodus gekies word om te begin:

filter
Reeks

Dié. volgens die beskryfde beleid word aanvanklik nodusse gekies waarop dit moontlik is om 'n peul op grond van 'n stel bekend te stel predikate (insluitend om te kontroleer of die nodus genoeg hulpbronne het om die pod te laat loop - PodFitsResources), en dan vir elk van hierdie nodusse, volgens prioriteite punte word toegeken (insluitend, hoe meer gratis hulpbronne 'n nodus het, hoe meer punte word dit toegeken - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) en die pod word op die nodus met die meeste punte geloods (as verskeie nodusse tegelyk aan hierdie voorwaarde voldoen, dan 'n ewekansige een word gekies).

Terselfdertyd moet jy verstaan dat die skeduleerder, wanneer die beskikbare hulpbronne van 'n nodus beoordeel word, gelei word deur die data wat in etcd gestoor word - d.w.s. vir die bedrag van die versoekte/limiet hulpbron van elke peul wat op hierdie nodus loop, maar nie vir die werklike hulpbronverbruik nie. Hierdie inligting kan verkry word vanaf die opdraguitvoer kubectl describe node $NODE, byvoorbeeld:

# 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%)

Hier sien ons al die peule wat op 'n spesifieke nodus loop, sowel as die hulpbronne wat elke peul versoek. En hier is hoe die skeduleerderlogboeke lyk wanneer die cronjob-cron-events-1573793820-xt6q9-peul geloods word (hierdie inligting sal in die skeduleerderlogboek verskyn wanneer jy die 10de aantekenvlak in die opstartbevel-argumente -v=10 stel):

Meld

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-s10

Hier sien ons dat die skeduleerder aanvanklik 'n lys van 3 nodusse filtreer en genereer waarop dit geloods kan word (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Dan bereken dit tellings gebaseer op verskeie parameters (insluitend BalancedResourceAllocation, LeastResourceAllocation) vir elk van hierdie nodusse om die mees geskikte nodus te bepaal. Uiteindelik word die peul geskeduleer op die nodus met die hoogste aantal punte (hier het twee nodusse gelyktydig dieselfde aantal punte 100037, so 'n ewekansige een word gekies - nxs-k8s-s10).

Output: as 'n nodus peule bestuur waarvoor geen beperkings gestel is nie, dan sal dit vir k8s (uit die oogpunt van hulpbronverbruik) gelykstaande wees aan asof daar glad nie sulke peule op hierdie nodus was nie. Daarom, as jy, voorwaardelik, 'n peul het met 'n vraatproses (byvoorbeeld, wowza) en geen beperkings word daarvoor gestel nie, dan kan 'n situasie ontstaan wanneer hierdie peul eintlik al die hulpbronne van die nodus geëet het, maar vir k8s hierdie node word as afgelaai beskou en dit sal dieselfde aantal punte toegeken word wanneer dit gerangskik word (juis in punte wat beskikbare hulpbronne beoordeel) as 'n nodus wat nie werkende peule het nie, wat uiteindelik kan lei tot ongelyke verspreiding van die las tussen nodusse.

Pod se uitsetting

Soos u weet, word aan elke peul een van 3 QoS-klasse toegewys:

gewaarborg - word toegeken wanneer vir elke houer in die peul 'n versoek en limiet gespesifiseer word vir geheue en cpu, en hierdie waardes moet ooreenstem
barsbaar — ten minste een houer in die peul het 'n versoek en 'n limiet, met versoek < limiet
beste poging - wanneer nie 'n enkele houer in die peul hulpbronbeperk is nie

Terselfdertyd, wanneer 'n nodus 'n gebrek aan hulpbronne (skyf, geheue) ervaar, begin kubelet om peule te rangskik en uit te sit volgens 'n spesifieke algoritme wat die prioriteit van die peul en sy QoS-klas in ag neem. Byvoorbeeld, as ons oor RAM praat, word punte volgens die volgende beginsel toegeken, gebaseer op die QoS-klas:

Gewaarborg: -998
Beste poging: 1000
Barsbaar: min(maks(2, 1000 - (1000 * geheueVersoekBytes) / masjienMemoryCapacityBytes), 999)

Dié. met dieselfde prioriteit, sal die kubelet eers peule met die beste moeite QoS-klas uit die nodus verwyder.

Output: as jy die waarskynlikheid wil verminder dat die gewenste peul uit die nodus gesit word in die geval van 'n gebrek aan hulpbronne daarop, dan moet jy saam met die prioriteit ook sorg vir die stel van die versoek/limiet daarvoor.

Meganisme vir horisontale outo-skaal van toepassingpeule (HPA)

Wanneer die taak is om outomaties die aantal peule te verhoog en te verminder, afhangende van die gebruik van hulpbronne (stelsel - SVE/RAM of gebruiker - rps), soos 'n k8s-entiteit soos HPA (Horizontal Pod Autoscaler). Die algoritme is soos volg:

Die huidige lesings van die waargenome hulpbron word bepaal (currentMetricValue)
Die verlangde waardes vir die hulpbron word bepaal (desiredMetricValue), wat vir stelselhulpbronne gestel word met behulp van versoek
Die huidige aantal replikas word bepaal (huidige Replikas)
Die volgende formule bereken die verlangde aantal replikas (gewenste replikas)
gewensteReplicas = [ currentReplicas * ( currentMetricValue / gewensteMetricValue )]

In hierdie geval sal skaal nie plaasvind wanneer die koëffisiënt (currentMetricValue / gewensteMetricValue) naby aan 1 is (in hierdie geval kan ons die toelaatbare fout self stel; dit is by verstek 0.1).

Kom ons kyk na hoe hpa werk met behulp van die voorbeeld van die toepassing-toetstoepassing (beskryf as Ontplooiing), waar dit nodig is om die aantal replikas te verander na gelang van SVE-verbruik:

Aansoekmanifes

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

Dié. ons sien dat die toepassingspod aanvanklik in twee gevalle geloods word, wat elk twee nginx- en nginx-uitvoerderhouers bevat, vir elkeen 'n gespesifiseerde versoeke vir SVE.

HPA Manifes

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

Dié. Ons het 'n hpa geskep wat die Ontplooiing-toepassingstoets sal monitor en die aantal peule met die toepassing sal aanpas op grond van die cpu-aanwyser (ons verwag dat die peul 30% van die SVE wat dit versoek sal verbruik), met die aantal replikas in die reeks van 2-10.

Kom ons kyk nou na die meganisme van hpa-werking as ons 'n las op een van die vuurherde toepas:

 # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi

In totaal het ons die volgende:

Die verlangde waarde (desiredMetricValue) - volgens die hpa-instellings het ons 30%
Huidige waarde (currentMetricValue) - vir berekening bereken beheerder-bestuurder die gemiddelde waarde van hulpbronverbruik in %, d.w.s. doen voorwaardelik die volgende:
1. Ontvang absolute waardes van pod-statistieke van die metrieke bediener, d.w.s. 101m en 4m
2. Bereken die gemiddelde absolute waarde, m.a.w. (101m + 4m) / 2 = 53m
3. Kry die absolute waarde vir die verlangde hulpbronverbruik (hiervoor word die versoeke van alle houers opgesom) 60m + 30m = 90m
4. Bereken die gemiddelde persentasie van SVE-verbruik relatief tot die versoekpod, d.w.s. 53 m / 90 m * 100% = 59%

Nou het ons alles wat ons nodig het om te bepaal of ons die aantal replikas moet verander; om dit te doen, bereken ons die koëffisiënt:

ratio = 59% / 30% = 1.96

Dié. die aantal replikas moet met ~2 keer vermeerder word en tot [2 * 1.96] = 4 beloop.

Gevolgtrekking: Soos u kan sien, om hierdie meganisme te laat werk, is 'n noodsaaklike voorwaarde die teenwoordigheid van versoeke vir alle houers in die waargenome peul.

Meganisme vir horisontale outoskaling van nodusse (Cluster Autoscaler)

Om die negatiewe impak op die stelsel tydens beurtkrag te neutraliseer, is dit nie genoeg om 'n gekonfigureerde hpa te hê nie. Byvoorbeeld, volgens die instellings in die hpa-beheerderbestuurder, besluit dit dat die aantal replikas met 2 keer vermeerder moet word, maar die nodusse het nie gratis hulpbronne om so 'n aantal peule te laat loop nie (m.a.w. die nodus kan nie die hulpbronne na die versoeke-pod aangevra het) en hierdie peule skakel oor na die hangende toestand.

In hierdie geval, as die verskaffer 'n ooreenstemmende IaaS/PaaS het (byvoorbeeld GKE/GCE, AKS, EKS, ens.), 'n hulpmiddel soos Node Autoscaler. Dit laat jou toe om die maksimum en minimum aantal nodusse in die groepie te stel en outomaties die huidige aantal nodusse aan te pas (deur die wolkverskaffer API te bel om 'n nodus te bestel/verwyder) wanneer daar 'n gebrek aan hulpbronne in die groepie en die peule is kan nie geskeduleer word nie (is in die hangende toestand).

Gevolgtrekking: Om nodusse te kan outoskaal, is dit nodig om versoeke in die peulhouers te stel sodat k8s die las op die nodusse korrek kan assesseer en dienooreenkomstig kan rapporteer dat daar geen hulpbronne in die groep is om die volgende peul te begin nie.

Gevolgtrekking

Daar moet kennis geneem word dat die opstel van houerhulpbronlimiete nie 'n vereiste is vir die toepassing om suksesvol te loop nie, maar dit is steeds beter om dit te doen om die volgende redes:

Vir meer akkurate werking van die skeduleerder in terme van lasbalansering tussen k8s nodusse
Om die waarskynlikheid van 'n "peuluitsetting"-gebeurtenis te verminder
Vir horisontale outoskaling van toepassingspeule (HPA) om te werk
Vir horisontale outoskaling van nodusse (Cluster Autoscaling) vir wolkverskaffers

Lees ook ander artikels op ons blog:

Bron: will.com

Kubernetes: hoekom is dit so belangrik om stelselhulpbronbestuur op te stel?