Kubernetes: miks on oluline seadistada süsteemi ressursside haldamine?

Tavaliselt on vajalik tagada rakendusele pühendatud ressursipool. Aga mis juhtub siis, kui ühel ja samal süsteemil töötab mitu rakendust? Kuidas tagada, et igaühel on minimaalselt vajalikud ressursid? Kuidas piirata ressursikasutust? Kuidas jaotada koormust node'ide vahel? Kuidas tagada horisontaalse skaleerimise mehhanismi töö, kui rakenduste koormus kasvab?

Peame alustama peamistest ressursitüüpidest, mis süsteemis eksisteerivad — need on loomulikult protsessorite aeg ja operatiivmälu. K8s manifestides mõõdetakse neid ressursitüüpe järgmistes ühikutes:

• CPU — tuumades
• RAM — baitides

Iga ressursi jaoks on võimalik määrata kahte tüüpi nõudeid — taotlused ja limits. Requests – määratleb minimaalsed nõuded vabadelt node'i ressurssidelt konteineri (ja kogu poda) käivitamiseks, samas kui limits kehtestab rangelt piiratud ressursid, mis on konteinerile kergesti kätte saadavad.

Oluline on mõista, et manifestis ei ole tingimata vajalik mõlemaid tüüpe selgelt määratleda, kuid käitumine on järgmine:

• Kui ainult limits ressurssi selgelt määratletakse, siis requests selle ressursi jaoks võtab automaatselt väärtuse, mis on võrdne limits'iga (seda saab tõestada, kutsudes esile kirjeldamise). See tähendab, et konteineri töö on piiratud sama ressursihulgaga, nagu ta ise oma käivitamiseks nõuab.
• Kui ressursi jaoks on selgelt määratud ainult requests, siis ei kehtestata sellele ressursile ülemisi piiranguid — st konteiner on piiratud ainult node'i enda ressurssidega.

Samuti on võimalik seadistada ressursihalduse mitte ainult konkreetse konteineri, vaid ka nimeruumi tasandil, kasutades järgmisi elemente:

• LimitRange — kirjeldab poliitikat piirangute tasemel konteineris/podis ns ja on vajalik, et kirjeldada vaikimisi piiranguid konteineris/podis, samuti takistada juba rasvade konteinerite/podide loomist (või vastupidi), piirata nende arvu ja määrata võimaliku erinevuse väärtuste vahel limits ja requests.
• ResourceQuotas — kirjeldavad ressursipiirangu poliitikat üldiselt kõikide konteinerite jaoks ns ja kasutatakse enamasti ressursside eraldamiseks keskkondade vahel (kasulik, kui keskkonnad ei ole rangelt eristatud sõlmede tasandil)

Allpool on toodud näidised manifestidest, kus kehtestatakse ressursipiirangud:

• Konkreetse konteineri tasandil:

  containers:
  - name: app-nginx
    image: nginx
    resources:
      requests:
        memory: 1Gi
      limits:
        cpu: 200m

  See tähendab, et antud juhul on nginx konteineri käitamiseks vähemalt vajalik vabade 1G RAM ja 0.2 CPU olemasolu sõlmes, samas kui konteiner võib maksimaalselt kasutada 0.2 CPU ja kogu vabast RAM-st sõlmes.

• Kogu ns tasandil:

  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: nxs-test
  spec:
    hard:
      requests.cpu: 300m
      requests.memory: 1Gi
      limits.cpu: 700m
      limits.memory: 2Gi

  See tähendab, et kõikide defauldis ns konteinerite requestide summa ei tohi ületada 300m CPU ja 1G RAM, samas kui limitide summa ei tohi ületada 700m CPU ja 2G RAM.

• Default piirangud konteinerite jaoks 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

  See tähendab, et kõikide konteinerite jaoks default ns-is kehtestatakse request 100m CPU ja 1G RAM, limit – 1 CPU ja 2G. Samuti on seatud piirangud CPU (50m < x < 2) ja RAM (500M < x < 4G) requestide ja limitide võimalikele väärtustele.

• Piirangud podide tasandil ns:

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

  See tähendab, et igas podis default ns-is kehtestatakse piirang 4 vCPU ja 1G.

Nüüd sooviksin rääkida, milliseid eeliseid võivad need piirangud meile tuua.

Koormuse tasakaalustamise mehhanism sõlmede vahel

Nagu teada, vastutab podide jaotumise eest sõlmedes selline komponent nagu k8s scheduler, mis töötab teatud algoritmi alusel. See algoritm valib optimaalse sõlme jaoks käivitamist kahes etapis:

1. Filtreeimine
2. Hinnang

See tähendab, et kirjelduse järgi valitakse alguses need sõlmed, kus podi käitamine on võimalik vastavalt kogumile predicates (sealhulgas kontrollitakse, kas sõlmel on piisavalt ressursse podi käitamiseks — PodFitsResources), ja seejärel hinnatakse igat neist sõlmedest vastavalt priorities punkte antakse (sealhulgas, mida rohkem vabu ressursse on sõlmes – seda rohkem punkte sellele antakse – LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ja see käivitatakse sõlmes, millel on kõige rohkem punkte (kui sellele tingimusele vastab korraga mitu sõlme, valitakse juhuslikult üks neist).

Siinkohal on oluline mõista, et scheduler hindab sõlme saadaval olevaid ressursse andmete põhjal, mis on salvestatud etcd-s – st iga sõlmes käivitatud konteineri requested/limit ressursi summa, mitte ressursside tegeliku tarbimise põhjal. Selle teabe saab käskluse 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%)

Siit näeme kõiki konteinerite, mis on käivitatud konkreetse sõlme peal, ning ka ressursse, mida iga konteiner küsib. Ja siin on scheduler'i logid, kui käivitada konteiner cronjob-cron-events-1573793820-xt6q9 (see teave scheduler'i logides ilmub, kui logimise tasemeks on seatud 10. tase käivitamise käsu argumentides –v=10):

logi

I1115 07:57:21.637791       1 scheduling_queue.go:908] Proovime planeerida pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9.                                                                                          
I1115 07:57:21.637804       1 scheduler.go:453] Üritame planeerida pod'i: nxs-stage/cronjob-cron-events-1573793820-xt6q9.                                                                                          
I1115 07:57:21.638285       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s5 on lubatud, sõlm töötab ainult 16 pod'ist 110.                                                                 
I1115 07:57:21.638300       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s6 on lubatud, sõlm töötab ainult 20 pod'ist 110.                                                                 
I1115 07:57:21.638322       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s3 on lubatud, sõlm töötab ainult 20 pod'ist 110.                                                                 
I1115 07:57:21.638322       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s4 on lubatud, sõlm töötab ainult 17 pod'ist 110.                                                                 
I1115 07:57:21.638334       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s10 on lubatud, sõlm töötab ainult 16 pod'ist 110.                                                                
I1115 07:57:21.638365       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s12 on lubatud, sõlm töötab ainult 9 pod'ist 110.                                                               
I1115 07:57:21.638334       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s11 on lubatud, sõlm töötab ainult 11 pod'ist 110.                                                               
I1115 07:57:21.638385       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s1 on lubatud, sõlm töötab ainult 19 pod'ist 110.                                                               
I1115 07:57:21.638402       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s2 on lubatud, sõlm töötab ainult 21 pod'ist 110.                                                               
I1115 07:57:21.638383       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s9 on lubatud, sõlm töötab ainult 16 pod'ist 110.                                                               
I1115 07:57:21.638335       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s8 on lubatud, sõlm töötab ainult 18 pod'ist 110.                                                               
I1115 07:57:21.638408       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s13 on lubatud, sõlm töötab ainult 8 pod'ist 110.                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s10 on lubatud, olemasolevate pod'ide anti-afitiini tingimused on täidetud.                                                                                                               
I1115 07:57:21.638505       1 predicates.go:1369] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s8 on lubatud, olemasolevate pod'ide anti-afitiini tingimused on täidetud.                                                                                                               
I1115 07:57:21.638577       1 predicates.go:1369] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s9 on lubatud, olemasolevate pod'ide anti-afitiini tingimused on täidetud.                                                                                                               
I1115 07:57:21.638583       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 planeerimine sõlmele nxs-k8s-s7 on lubatud, sõlm töötab ainult 25 pod'ist 110.                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: Tasakaalustatud ressursijaotus, maht 39900 millikoore 66620178432 mälubaiti, koguur 2343 millikoore 9640186880 mälubaiti, punktid 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: Vähenenud ressursi jaotamine, maht 39900 millikoore 66620178432 mälubaiti, koguur 2343 millikoore 9640186880 mälubaiti, punktid 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: Tasakaalustatud ressursijaotus, maht 39900 millikoore 66620170240 mälubaiti, koguur 4107 millikoore 11307422720 mälubaiti, punktid 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: Tasakaalustatud ressursijaotus, maht 39900 millikoore 66620178432 mälubaiti, koguur 5847 millikoore 24333637120 mälubaiti, punktid 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: Vähenenud ressursi jaotamine, maht 39900 millikoore 66620170240 mälubaiti, koguur 4107 millikoore 11307422720 mälubaiti, punktid 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: Vähenenud ressursi jaotamine, maht 39900 millikoore 66620178432 mälubaiti, koguur 5847 millikoore 24333637120 mälubaiti, punktid 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Punkte: (10)                                                                                              
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Punkte: (10)                                                                                               
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Punkte: (10)                                                                                               
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Punkte: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Punkte: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Punkte: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Punkte: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Punkte: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Punkte: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Punkte: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Punkte: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Punkte: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Punkte: (10)                                                                                                           
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Punkte: (10)                                                                                                            
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Punkte: (10)                                                                                                            
I1115 07:57:21.639127       1 generic_scheduler.go:781] Host nxs-k8s-s10 => Punktid 100037                                                                                                                                                                        
I1115 07:57:21.639150       1 generic_scheduler.go:781] Host nxs-k8s-s8 => Punktid 100034                                                                                                                                                                         
I1115 07:57:21.639154       1 generic_scheduler.go:781] Host nxs-k8s-s9 => Punktid 100037                                                                                                                                                                         
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumePodVolumes pod'i "nxs-stage/cronjob-cron-events-1573793820-xt6q9" jaoks, sõlm "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumePodVolumes pod'i "nxs-stage/cronjob-cron-events-1573793820-xt6q9" jaoks, sõlm "nxs-k8s-s10": kõik PVC-d on ühendatud ja muud ei ole teha                                                                             
I1115 07:57:21.639333       1 factory.go:733] Üritame siduda cronjob-cron-events-1573793820-xt6q9 sõlmele nxs-k8s-s10.

Siin näeme, et esialgu filtrib scheduler ning koostab nimekirja kolmest node'ist, kus käivitamine on võimalik (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Seejärel arvutab see igasuguste parameetrite (sealhulgas BalancedResourceAllocation, LeastResourceAllocation) põhjal punktid nende node'ite jaoks, et määrata välja sobivaim sõlm. Lõpuks plaanitakse kõige rohkem punkte saanud node'ile (siin on kohe kaks node'it, millel on sama punktide arv 100037, seega valitakse neist juhuslik — nxs-k8s-s10).

KokkuvõteKui nodis töötavad podid, millele ei ole piiranguid määratud, on see k8s jaoks (ressursside tarbimise seisukohalt) sama, nagu oleks need podid sellel nodil täielikult puuduvad. Seetõttu, kui teil on näiteks pod koos näljase protsessiga (nt wowza), millele piiranguid ei ole määratud, võib tekkida olukord, kus see pod tarbib kõik node'i ressursid, kuid k8s jaoks loetakse see node mittekoormatud ning sellele antakse sama palju punkte reastamisel (just nende ressursside hindamise punktides), kui node'ile, kus ei ole töötavaid pode, mis võib lõpuks viia ebaühtlase koormuse jaotumiseni node'ite vahel.

Podi välja tõukamine

Nagu teada, antakse igale podile üks kolmest QoS-klassi:

1. guaranuted kui iga konteineri jaoks podis on määratud memory ja cpu request ja limit ning need väärtused peavad olema võrdsed
2. burstable kui vähemalt ühel konteineril podis on määratud request ja limit, kusjuures request < limit
3. best effort kui ükski konteiner podis ei ole ressursside osas piiratud

Kui nodis on ressursid (ketas, mälu) lõppenud, hakkab kubelet järjestama ja välja tõukama pode teatud algoritmi alusel, mis arvestab podi prioriteeti ja selle QoS-klassi. Näiteks, kui tegemist on RAM-iga, siis QoS-klassi alusel antakse punkte järgmise põhimõtte kohaselt:

• Guaranteed: -998
• BestEffort: 1000
• Burstable: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

See tähendab, et sama prioriteedi korral hakkab kubelet esmalt välja tõukama node'ist pode, mille QoS-klassi on best effort.

Kokkuvõte: kui soovite vähendada vajaliku podi välja tõukamise tõenäosust node'ist ressursipuuduse korral, peate lisaks prioriteedile hoolitsema ka request/limit määramise eest.

Rakenduse poodide horisontaalne automaatne skaleerimine (HPA)

Kui eesmärk on automaatselt suurendada ja vähendada poodide arvu sõltuvalt ressursikasutuse (süsteemi — CPU/RAM või kasutaja — rps) nõudest, võib selle lahenduses aidata selline k8s element nagu HPA (Horisontaalne Pod Automaatskaalija). Selle algoritm põhineb järgmisel:

1. Määratakse jälgitava ressursi praegused näidud (currentMetricValue)
2. Määratakse soovitud väärtused ressursi jaoks (desiredMetricValue), mis süsteemsete ressursside puhul määratakse request'ide abil
3. Määratakse praegune replikate arv (currentReplicas)
4. Järgmise valemi abil arvutatakse soovitud replikate arv (desiredReplicas)
   desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]

Sel juhul ei toimu skaleerimist, kui koefitsient (currentMetricValue / desiredMetricValue) on lähedal 1 (samal ajal saame ise määrata lubatud täpsuse, mis vaikimisi on 0.1).

Vaatame hpa tööd rakenduse app-test näite põhjal (mida on kirjeldatud kui Deployment), kus on vajalik muuta replikate arvu sõltuvalt CPU 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-status

  Kuna näeme, et rakenduse pood käivitatakse algselt kahes eksemplaris, millest igas on kaks konteinerit nginx ja nginx-exporter, millest igaühele on määratud taotlused CPU 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: 30

  Kuna oleme loonud hpa, mis jälgib Deployment app-test ja reguleerib rakenduse poodide arvu CPU näidu põhjal (oodame, et pood peaks tarbima 30% oma taotletud CPU-st), samal ajal on replikate arv vahemikus 2-10.

  Nüüd vaatame hpa töömehhanismi, kui koormust rakendada ühele poodidest:

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

Kokkuvõtteks saame järgmise:

• Soovitud väärtus (desiredMetricValue) - vastavalt hpa seadevale on see 30%
• Praegune väärtus (currentMetricValue) - controller-manager arvutab keskmise ressursikasutuse protsentides, st teisisõnu teeb järgmist:
  1. Saab podide mõõdikute absoluutväärtused metric-serverist, st 101m ja 4m
  2. Arvutab keskmise absoluutväärtuse, st (101m + 4m) / 2 = 53m
  3. Saab absoluutväärtuse soovitud ressursikasutuse jaoks (selleks summeeritakse kõigi konteinerite request'id) 60m + 30m = 90m
  4. Arvutab keskmise CPU kasutuse protsendi võrreldes podi request'iga, st 53m / 90m * 100% = 59%

Nüüd on meil kõik vajalikud andmed, et määrata, kas replikate arvu on vaja muuta, selleks arvutame koefitsiendi:

ratio = 59% / 30% = 1.96

St, replikate arvu tuleks suurendada umbes 2 korda ja see peaks olema [2 * 1.96] = 4.

Kokkuvõte: Nagu on märgata, et selle mehhanismi tööks on vajalik tingimus ka see, et kõikide konteinerite jaoks on podis olemas request'id.

Horisontraalne automaatne skaleerimise mehhanism (Cluster Autoscaler)

Kuna negatiivse mõju vähendamiseks süsteemile koormuse tõusude ajal ei pruugi seadistatud hpa olla piisav. Näiteks hpa seadeid järgides otsustab controller manager, et replikate arvu tuleb suurendada 2 korda, kuid node'idel ei ole piisavaid ressursse selliste podide käitamiseks (st node ei saa pakkuda podi request'eid) ja need podid lähevad Pending olekusse.

Sellisel juhul, kui teenusepakkujal on vastav IaaS/PaaS (nt GKE/GCE, AKS, EKS jne), võib meid aidata selline tööriist nagu Node Autoscaler. See võimaldab seadistada klastris maksimaalse ja minimaalse node'ite arvu ning automaatselt reguleerida praegust node'ite arvu (tehes API kõnesid pilveteenuse pakkujaga node tellimiseks/kustutamiseks), kui klastris on ressursipuudus ja podid ei saa plaanitud (on Pending olekus).

Kokkuvõte: Noodide automaatseks skaleerimiseks on vajalik määrata konteinerite request'id podides, et k8s saaks õigesti hinnata node'ite koormust ja vastavalt teavitada, et klastris ei ole ressursse järgmise podi käitamiseks.

Kokkuvõte

Tuleb märkida, et konteineri ressursipiirangute seadmine ei ole rakenduse edukaks käivitamiseks vajalik, kuid see on siiski soovitatav järgmistel põhjustel:

1. Selleks, et scheduler töötaks täpsemalt k8s sõlmede koormuse tasakaalustamise osas.
2. Selleks, et vähendada tõenäosust, et tekib "pod'i väljatõstmine".
3. Selleks, et toimiks rakenduse podide horisontaalne automaatne skaleerimine (HPA).
4. Selleks, et toimiks pilvepakkujate sõlmede horisontaalne automaatne skaleerimine (Cluster Autoscaling).

Vaata ka teisi artikleid meie blogis:

• Tekton Pipeline — Kubernetes'e natiivsed pipelines
• Dünaamiliste moodulite ehitamine Nginxi jaoks
• Milleni viis migratsioon ClickHouse'ist ilma autentsuseta ClickHouse'ile autentsusega
• Uurime konteksti paketti Golangis
• Kolm lihtsat viisi Docker-piltide vähendamiseks
• Suurte ja erinevate veebiprojektide varundamine

Allikas: habr.com