🥇Kubernetes: Ngano nga importante kaayo ang pag-configure sa pagdumala sa kahinguhaan sa sistema?

Kasagaran, kanunay adunay panginahanglan sa paghatag og usa ka gipahinungod nga pundok sa mga kahinguhaan sa usa ka aplikasyon alang sa husto ug lig-on nga operasyon niini. Apan unsa man kon daghang mga aplikasyon ang nagdagan sa parehas nga mga kahinguhaan? Giunsa paghatag sa matag aplikasyon ang minimum nga gikinahanglan nga mga kahinguhaan? Giunsa limitahan ang pagkonsumo sa kahinguhaan? Giunsa intelihente nga maapod-apod ang load taliwala sa mga node? Giunsa masiguro ang horizontal scaling samtang nagdugang ang load sa aplikasyon?

Kinahanglan natong sugdan sa mga nag-unang klase sa kahinguhaan sa sistema—siyempre, ang oras sa CPU ug RAM. Sa mga manifest sa K8S, kini nga mga klase sa kahinguhaan gisukod sa mosunod nga mga yunit:

CPU - sulod sa mga core
RAM - sa mga byte

Dugang pa, alang sa matag kapanguhaan posible nga magtakda og duha ka klase sa mga kinahanglanon: Mga hangyo и limitasyonAng "Requests" naghulagway sa minimum nga mga kinahanglanon para sa libreng node resources aron modagan ang usa ka container (ug usa ka pod sa kinatibuk-an), samtang ang "limits" nagtakda og usa ka estrikto nga limitasyon sa mga resources nga magamit sa container.

Importante nga masabtan nga dili kinahanglan nga klaro nga ipasabot ang duha ka klase sa manifest, apan ang pamatasan mao ang mosunod:

Kon ang mga limitasyon lang sa usa ka kahinguhaan ang klarong gitino, ang mga hangyo alang niana nga kahinguhaan awtomatikong makakuha og bili nga katumbas sa mga limitasyon (kini mapamatud-an pinaagi sa pagtawag sa describe sa entidad). Sa ato pa, ang operasyon sa container epektibong limitado sa parehas nga gidaghanon sa mga kahinguhaan nga gikinahanglan niini aron modagan.
Kon ang mga hangyo lang ang klarong gitino para sa usa ka kahinguhaan, nan walay mga pagdili nga gipahamtang niini nga kahinguhaan—i.e., ang sudlanan limitado lamang sa mga kahinguhaan sa node mismo.

Posible usab nga i-configure ang resource management dili lamang sa lebel sa usa ka piho nga container, apan lakip usab sa lebel sa namespace gamit ang mosunod nga mga entidad:

LimitRange — naghulagway sa palisiya sa limitasyon sa lebel sa container/pod sa ns ug gikinahanglan aron ihulagway ang default nga mga limitasyon para sa usa ka container/pod, ingon man aron mapugngan ang paghimo sa klaro nga tambok nga mga container/pod (o vice versa), limitahan ang ilang gidaghanon ug mahibal-an ang posible nga kalainan sa mga kantidad sa mga limitasyon ug mga hangyo
ResourceQuotas — naghulagway sa palisiya sa pagdili alang sa tanan nga mga sudlanan sa ns sa kinatibuk-an ug kasagaran gigamit aron i-delimit ang mga kahinguhaan pinaagi sa palibot (mapuslanon kung ang mga palibot dili estrikto nga gi-delimit sa lebel sa node)

Ania ang mga ehemplo sa mga manifest nga nagtakda og mga limitasyon sa kahinguhaan:

Sa lebel sa usa ka piho nga sudlanan:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
Sa ato pa, sa kini nga kaso, aron maglunsad og container nga adunay nginx, kinahanglan nimo ang labing menos 1G nga libre nga RAM ug 0.2 CPU sa node, samtang ang maximum nga magamit sa container mao ang 0.2 CPU ug ang tanan nga magamit nga RAM sa node.
Sa lebel sa integer nga ns:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
Sa ato pa, ang sumada sa tanang request containers sa default ns dili molapas sa 300m para sa CPU ug 1G para sa RAM, ug ang sumada sa tanang limit kay 700m para sa CPU ug 2G para sa RAM.
Mga default nga limitasyon para sa mga sudlanan sa 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
```
Kini nagpasabot nga ang default nga namespace para sa tanang container mo-set sa request ngadto sa 100M para sa CPU ug 1G para sa RAM, nga may limit nga 1 CPU ug 2G. Aduna usay limit sa posibleng mga request/limit values para sa CPU (50M < x < 2) ug RAM (500M < x < 4G).
Mga restriksyon sa lebel sa pod ns:
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
Kini nagpasabot nga para sa matag pod sa default ns, usa ka limit nga 4 vCPU ug 1G ang itakda.

Karon gusto kong isulti kanimo kung unsang mga benepisyo ang mahatag kanato sa pagbutang niining mga restriksyon.

Mekanismo sa pagbalanse sa karga tali sa mga node

Sama sa nahibal-an, ang pag-apod-apod sa mga pod taliwala sa mga node responsibilidad sa ingon nga sangkap sa k8s sama sa iskedyul, nga naglihok sumala sa usa ka piho nga algorithm. Kini nga algorithm moagi sa duha ka yugto sa pagpili sa labing maayo nga node nga ilunsad:

pagsala
Naglangkob

Kana mao, sumala sa gihulagway nga palisiya, ang mga node unang gipili kung asa ilunsad ang usa ka pod base sa usa ka set. mga predicate (lakip ang pagsusi kung ang node adunay igo nga mga kahinguhaan aron mapadagan ang pod - PodFitsResources), ug dayon alang sa matag usa niini nga mga node, sumala sa prayoridad Ang mga puntos ihatag (lakip na kon mas daghang libreng resources ang naa sa usa ka node, mas daghang puntos ang i-assign niini - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ug ang pod ilunsad sa node nga adunay pinakadaghang puntos (kon daghang node ang makatuman niini nga kondisyon sa usa ka higayon, usa ka random nga node ang pilion).

Importante nga masabtan nga sa pag-assess sa available resources sa usa ka node, ang scheduler mosalig sa data nga gitipigan sa etcd—nga mao, ang gihangyo/limitado nga resource sa matag pod nga nagdagan sa maong node—apan dili sa aktuwal nga konsumo sa resource. Kini nga impormasyon makuha gikan sa command output. kubectl describe node $NODEsama pananglit:

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

Dinhi atong makita ang tanang pods nga nagdagan sa usa ka piho nga node, ingon man ang mga resources nga gihangyo sa matag pod. Ug mao kini ang hitsura sa scheduler logs kung gipadagan ang pod cronjob-cron-events-1573793820-xt6q9 (kini nga impormasyon makita sa scheduler log kung imong i-set ang logging level 10 sa startup command arguments --v=10):

troso

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

Dinhi atong makita nga ang scheduler sa sinugdanan mosala ug mo-generate og lista sa tulo ka node diin kini mahimong modagan (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Dayon kini mokalkulo sa mga score para sa matag usa niini nga mga node base sa daghang mga parameter (lakip ang BalancedResourceAllocation ug LeastResourceAllocation) aron mahibal-an ang labing angay nga node. Sa katapusan, ang pod gi-iskedyul sa node nga adunay pinakataas nga score (dinhi, duha ka node ang adunay parehas nga score nga 100037, mao nga ang gipili nga random—nxs-k8s-s10—mao ang gipili).

konklusyonKon ang usa ka node adunay mga pod nga nagdagan nga walay gitakdang mga limitasyon, ang k8s motratar niini nga daw walay mga pod nga nagdagan sa node, kon bahin sa konsumo sa kahinguhaan. Busa, kon ikaw adunay pod nga adunay proseso nga gigutom sa kahinguhaan (pananglitan, wowza) ug walay gitakdang mga limitasyon alang niini, kini nga pod mahimong epektibong mokonsumo sa tanang kahinguhaan sa node. Apan, ang k8s nag-isip niini nga node nga wala nay gamit ug mohatag sa parehas nga mga puntos sa ranggo (ilabi na, sa mga termino sa magamit nga mga kahinguhaan) sama sa usa ka node nga walay mga pod nga nagdagan, nga sa katapusan mahimong mosangpot sa dili patas nga pag-apod-apod sa karga taliwala sa mga node.

Pagpapahawa sa pod

Sama sa imong nahibaloan, ang matag pod gi-assign sa usa sa 3 ka QoS classes:

garantiyado — gi-assign kon ang request ug limit gitakda para sa memory ug CPU para sa matag container sa pod, ug kini nga mga value kinahanglan nga motakdo
mabuak — labing menos usa ka container sa pod ang adunay request ug limit, ug ang request < limit
labing paningkamot - kung walay sudlanan sa pod nga limitado ang kahinguhaan

Kung ang usa ka node makasinati og kakulang sa mga kahinguhaan (disk, memorya), ang kubelet magsugod sa pag-ranggo ug pagtangtang sa mga pod gamit ang usa ka piho nga algorithm nga nagkonsiderar sa prayoridad ug klase sa QoS sa pod. Pananglitan, kung ang pod naka-RAM, ang mga puntos ihatag base sa klase sa QoS sama sa mosunod:

Gigarantiya:-998
Labing Maayong Paningkamot: 1000
Mabuak: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

Buot ipasabot, sa parehas nga prayoridad, ang kubelet unang mopapahawa sa mga pod nga adunay pinakamaayong paningkamot sa QoS class gikan sa node.

konklusyonKon gusto nimong pakunhuran ang posibilidad nga ang gikinahanglan nga pod matangtang gikan sa usa ka node kon adunay kakulangon sa kahinguhaan, uban sa prayoridad, kinahanglan usab nimo nga atimanon ang pagbutang og hangyo/limit para niini.

Mekanismo sa Horizontal Autoscaling para sa mga Application Pod (HPA)

Kung ang buluhaton mao ang awtomatikong pagdugang ug pagkunhod sa gidaghanon sa mga pod depende sa paggamit sa kahinguhaan (sistema - CPU/RAM o tiggamit - rps), ang ingon nga k8s entity sama sa HPA (Horizontal Pod Autoscaler). Ang algoritmo mao ang mosunod:

Ang kasamtangang mga pagbasa sa gimonitor nga kapanguhaan (currentMetricValue) gitino.
Ang gitinguha nga mga kantidad para sa kahinguhaan (desiredMetricValue) gitino, nga para sa mga kahinguhaan sa sistema gitino gamit ang request
Ang kasamtangang gidaghanon sa mga replika gitino (currentReplicas)
Ang mosunod nga pormula nagkalkula sa gitinguha nga gidaghanon sa mga replica (desiredReplicas)
gitinguha nga mga Replika = [ kasamtangang mga Replika * ( kasamtangang Balor sa Metriko / gitinguha nga Balor sa Metriko )]

Sa kini nga kaso, ang scaling dili mahitabo kung ang coefficient (currentMetricValue / desiredMetricValue) duol sa 1 (bisan pa, mahimo natong itakda ang gitugot nga error sa atong kaugalingon; pinaagi sa default kini 0.1).

Atong hisgotan ang operasyon sa HPA gamit ang ehemplo sa app-test application (gihulagway nga Deployment), diin gikinahanglan nga usbon ang gidaghanon sa mga replica depende sa konsumo sa CPU:

Manifesto sa aplikasyon

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

Sa ato pa, atong makita nga ang pod nga adunay aplikasyon sa sinugdanan gilunsad sa duha ka kopya, nga ang matag usa adunay duha ka sudlanan nga nginx ug nginx-exporter, nga alang sa matag usa ang Mga hangyo para sa CPU.

Manipesto sa HPA

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

Buot ipasabot, naghimo mig hpa nga mo-monitor sa Deployment app-test ug mo-regulate sa gidaghanon sa mga pod gamit ang aplikasyon base sa CPU indicator (among gilauman nga ang pod mokonsumo og 30% sa CPU nga gipangayo niini), samtang ang gidaghanon sa mga replica naa sa range nga 2-10.

Karon, atong tan-awon kon unsaon pag-andar sa HPA kon atong i-apply ang load sa usa sa mga pod:

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

Busa naa nato ang mosunod:

DesiredMetricValue - sumala sa among mga setting sa hpa, kini 30%
Kasamtangang bili (currentMetricValue) - para sa pagkalkulo, ang controller-manager nagkalkula sa aberids nga bili sa konsumo sa kahinguhaan sa %, i.e., kini nagbuhat sa mosunod:
1. Mokuha og absolute values sa pod metrics gikan sa metric server, i.e. 101m ug 4m
2. Nagkalkulo sa aberids nga hingpit nga kantidad, i.e. (101m + 4m) / 2 = 53m
3. Makakuha sa hingpit nga bili para sa gitinguha nga konsumo sa kahinguhaan (para niini, ang mga hangyo sa tanang sudlanan gisumada) 60m + 30m = 90m
4. Gikalkulo ang aberids nga porsyento sa konsumo sa CPU kalabot sa hangyo sa pod, i.e. 53m / 90m * 100% = 59%

Karon naa na nato ang tanan nga atong gikinahanglan aron mahibal-an kung kinahanglan ba natong usbon ang gidaghanon sa mga replika. Aron mahimo kini, atong kuwentahon ang koepisyente:

ratio = 59% / 30% = 1.96

Sa ato pa, ang gidaghanon sa mga replica kinahanglan nga dugangan og ~2 ka pilo ug mokabat sa [2 * 1.96] = 4.

Panapos: Sama sa imong makita, aron molihok kini nga mekanismo, ang gikinahanglan nga kondisyon mao ang presensya sa mga hangyo alang sa tanan nga mga container sa naobserbahan nga pod.

Cluster Autoscaler

Aron maibanan ang negatibong epekto sa sistema atol sa load surges, ang pagbaton og na-configure nga HPA kasagaran dili igo. Pananglitan, base sa mga setting sa HPA controller manager, ang gidaghanon sa mga replica kinahanglan nga doblehon, apan ang mga node walay igong magamit nga mga kapanguhaan aron mapadagan kini nga daghang mga pod (pananglitan, ang node dili makahatag sa gihangyo nga mga kapanguhaan sa requests pod), ug kini nga mga pod mosulod sa Pending state.

Sa kini nga kaso, kung ang provider adunay katugbang nga IaaS/PaaS (pananglitan GKE/GCE, AKS, EKS, ug uban pa), usa ka himan sama sa Awtomatikong Pag-scal sa NodeGitugotan ka niini nga itakda ang labing taas ug labing gamay nga gidaghanon sa mga node sa usa ka cluster ug awtomatikong i-adjust ang kasamtangang gidaghanon sa mga node (pinaagi sa pag-access sa API sa cloud provider aron mag-order/magtangtang sa usa ka node) kung adunay kakulang sa mga kahinguhaan sa cluster ug ang mga pod dili ma-iskedyul (naa sa Pending state).

Panapos: Aron ma-enable ang node autoscaling, kinahanglan nga i-specify ang mga request sa mga pod container aron ang K8S maka-assess sa node load sa saktong paagi ug maka-report nga walay resources sa cluster aron ilunsad ang sunod nga pod.

konklusyon

Kinahanglan nga matikdan nga ang pagbutang og mga limitasyon sa kahinguhaan sa sudlanan dili usa ka mandatory nga kinahanglanon alang sa usa ka malampuson nga paglansad sa aplikasyon, apan maayo gihapon nga buhaton kini tungod sa mosunod nga mga hinungdan:

Para sa mas tukma nga trabaho sa scheduler sa mga termino sa load balancing tali sa mga k8s node
Aron makunhuran ang posibilidad nga mahitabo ang usa ka panghitabo nga "pod eviction"
Para mogana ang horizontal application pod autoscaling (HPA)
Para ma-enable ang horizontal node autoscaling (Cluster Autoscaling) sa mga cloud providers