🥇Kubernetes: miks on süsteemi ressursihalduse seadistamine nii oluline?

Tavaliselt on alati vajalik tagada pühendatud ressursside hulk rakendusele, et see töötab õigesti ja stabiilselt. Aga mis juhtub, kui mitu rakendust töötab samadel seadmetel? Kuidas tagada igale rakendusele minimaalne vajalik ressursihulk? Kuidas saab piirata ressursside tarbimist? Kuidas jaotada koormus õigesti sõlmede vahel? Kuidas tagada horisontaalse skaleerimise mehhanismi töö rakenduste koormuse tõustes?

Alustada tuleb sellega, millised on peamised ressursside tüübid süsteemis — need on muidugi protsessoriaeg ja mälu. K8si manifestides mõõdetakse neid ressursitüüpe järgmistes ühikutes:

CPU — tuumades
RAM — baitides

Igale ressursile on võimalik määrata kahte tüüpi nõudmisi — requests ja limits. Requests — kirjeldab minimaalset nõuet sõlme vaba ressursi osas konteineri (ja podi tervikuna) käivitamiseks, samas kui limits seab ressursside range piirangu, mis on konteinerile kätte saadav.

Oluline on mõista, et manifestis ei pea olema kohustuslikult selgelt määratletud mõlemat tüüpi, samasugune käitumine kehtib järgmistel tingimustel:

Kui on selgelt määratud ainult ressursside limiidid, siis selle ressursi taotlused võtavad automaatselt väärtuse, mis on võrdne limiitidega (seda saab kontrollida, kutsudes esile üksuse kirjeldamise). St tegelikult on konteineri töö piiratud sama palju ressursse, kui see vajab oma käivitamiseks.
Kui ressursile on selgelt määratud ainult taotlused, siis sellele ressursile ei rakendata üldse ülemisi piiranguid — st konteiner on piiratud ainult sõlme enda ressurssidega.

Samuti on võimalik seadistada ressursihaldust mitte ainult konkreetse konteineri tasemel, vaid ka namespaces tasemel järgmiste üksuste abil:

LimitRange — kirjeldab piiranguid konteineri/podi tasemel ns ja on vajalik, et kirjeldada konteineri/podi vaikimisi piiranguid, samuti vältida teadlikult suurte konteinerite/podide loomist (või vastupidi), piirata nende arvu ja määrata võimalike limiitide ja taotluste väärtuste erinevust
ResourceQuotas — kirjeldavad piirangupoliitikat üldiselt kõigi konteinerite jaoks ns-s ning seda kasutatakse tavaliselt ressursside piiretluseks keskkondade vahel (kasulik, kui keskkonnad ei ole tõeliselt eraldatud sõlmede tasandil).

Allpool on näited manifestidest, kus on seatud 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 konteinri käitamiseks vaja vähemalt 1G vabast RAM-ist ja 0.2 CPU-d sõlmes, samas kui maksimaalselt võib konteiner tarbida 0.2 CPU-d ja kogu saadavalolev RAM 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 konteinerite requestide summa defaul ns-is ei tohi ületada 300m CPU ja 1G RAM, samas kui kõigi limitide summa ei tohi ületada 700m CPU ja 2G RAM.
Defauid piirangud konteinerite jaoks ns-is:
```
apiVersion: v1
kind: LimitRange
metadata:
  name: nxs-limit-per-container
spec:
 limits:
   - type: Container
     defaultRequest:
       cpu: 100m
       memory: 1Gi
     default:
       cpu: 1
       memory: 2Gi
     min:
       cpu: 50m
       memory: 500Mi
     max:
       cpu: 2
       memory: 4Gi
```
See, vaikimisi nimiruumi jaoks on kõikidele konteineritele CPU nõudmiseks määratud 100m ja RAM-i nõudmiseks 1G, piiri määramiseks on seatud 1 CPU ja 2G. Samuti on kehtestatud piirangud nõudmise/piiri väärtustele CPU jaoks (50m < x < 2) ja RAM-i jaoks (500M < x < 4G).

Piirangud podide tasemel ns:

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

See tähendab, et iga podi jaoks vaikimisi nimiruumis määratakse piirang 4 vCPU ja 1G.

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

Laadimise tasakaalustamise mehhanism sõlmede vahel

Kuidas teada, podide jaotuse eest sõlmede vahel vastutab k8s komponendiks scheduler, mis töötab kindla algoritmi alusel. See algoritm läbib kahe etapi, et valida optimaalne sõlm käivitamiseks:

Filtreerimine
Reiting

See tähendab, et kirjeldatud poliitika kohaselt valitakse algselt sõlmed, kus podi käivitamine on võimalik, tuginedes komplektile predicates (sealhulgas kontrollitakse, kas sõlmel on piisavalt ressursse podi käivitamiseks — PodFitsResources), seejärel hinnatakse nende sõlmede jaoks vastavalt priorities punkte antakse (sealhulgas, mida rohkem on vabu ressursse node'il - seda rohkem punkte sellele antakse - LeastResourceAllocation / LeastRequestedPriority / BalancedResourceAllocation) ja seda käivitatakse node'il, millel on kõige rohkem punkte (kui mitu node'it vastab sellele tingimusele, valitakse neist juhuslik).

Samuti tuleb mõista, et ajakava hindab node'i kättesaadavaid ressursse andmete põhjal, mis on salvestatud etcd-s - st iga selle node'i peal käivitatud pod'i requested / limit ressursside summa, kuid mitte tegeliku ressursikasutuse põhjal. Selle teabe saab käsku kasutades kubectl describe node $NODE, näiteks:

# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods:         (9 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  ingress-nginx              nginx-ingress-controller-754b85bf44-qkt2t    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-flannel-26bl4                           150m (0%)     300m (1%)   64M (0%)         500M (1%)      233d
  kube-system                kube-proxy-exporter-cb629                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-proxy-x9fsc                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                nginx-proxy-k8s-worker-s1                    25m (0%)      300m (1%)   32M (0%)         512M (1%)      233d
  nxs-monitoring             alertmanager-main-1                          100m (0%)     100m (0%)   425Mi (1%)       25Mi (0%)      233d
  nxs-logging                filebeat-lmsmp                               100m (0%)     0 (0%)      100Mi (0%)       200Mi (0%)     233d
  nxs-monitoring             node-exporter-v4gdq                          112m (0%)     122m (0%)   200Mi (0%)       220Mi (0%)     233d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                487m (3%)          822m (5%)
  memory             15856217600 (2%)  749976320 (3%)
  ephemeral-storage  0 (0%)             0 (0%)

Siin näeme kõiki pod’e, mis on konkreetse node'i peal käivitatud, samuti ressursse, mida iga pod küsib. Ja siin on logid ajakava tööprotsessist cronjob-cron-events-1573793820-xt6q9 (see teave ilmub ajakava logis, kui tõstetakse logimise taset 10. tasemeni käivituskomandi argumentides -v=10):

log

I1115 07:57:21.637791       1 scheduling_queue.go:908] Proovime nüüd ajastada pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Proovime ajastada 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine 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 ajastamine sõlmele nxs-k8s-s10 on lubatud, olemasolevad pod'ide anti-affinity tingimused on täidetud.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 ajastamine sõlmele nxs-k8s-s8 on lubatud, olemasolevad pod'ide anti-affinity tingimused on täidetud.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 ajastamine sõlmele nxs-k8s-s9 on lubatud, olemasolevad pod'ide anti-affinity tingimused on täidetud.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Pod'i nxs-stage/cronjob-cron-events-1573793820-xt6q9 ajastamine 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 ressursside jaotamine, maht 39900 millicores 66620178432 mälubaidi, kogunõue 2343 millicores 9640186880 mälubaidi, skoor 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: Vähenenud ressursside jaotamine, maht 39900 millicores 66620178432 mälubaidi, kogunõue 2343 millicores 9640186880 mälubaidi, skoor 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: Tasakaalustatud ressursside jaotamine, maht 39900 millicores 66620170240 mälubaidi, kogunõue 4107 millicores 11307422720 mälubaidi, skoor 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: Tasakaalustatud ressursside jaotamine, maht 39900 millicores 66620178432 mälubaidi, kogunõue 5847 millicores 24333637120 mälubaidi, skoor 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: Vähenenud ressursside jaotamine, maht 39900 millicores 66620170240 mälubaidi, kogunõue 4107 millicores 11307422720 mälubaidi, skoor 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: Vähenenud ressursside jaotamine, maht 39900 millicores 66620178432 mälubaidi, kogunõue 5847 millicores 24333637120 mälubaidi, skoor 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, skoor: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, skoor: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, skoor: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, skoor: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, skoor: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, skoor: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, skoor: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, skoor: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, skoor: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, skoor: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, skoor: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, skoor: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, skoor: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, skoor: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, skoor: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Sõlm nxs-k8s-s10 => skoor 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Sõlm nxs-k8s-s8 => skoor 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Sõlm nxs-k8s-s9 => skoor 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] Oletan pod'i mahud pod'ile "nxs-stage/cronjob-cron-events-1573793820-xt6q9", sõlm "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] Oletan pod'i mahud pod'ile "nxs-stage/cronjob-cron-events-1573793820-xt6q9", sõlm "nxs-k8s-s10": kõik PVC'd on seotud ja pole midagi teha                                                                             
I1115 07:57:21.639333       1 factory.go:733] Proovin siduda cronjob-cron-events-1573793820-xt6q9 nxs-k8s-s10'ga

Siin näeme, et esialgu filtreerib scheduler ja koostab kolme sõlme nimekirja, kus käivitamine on võimalik (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Seejärel arvutab see punktid mitmete parameetrite alusel (sealhulgas BalancedResourceAllocation, LeastResourceAllocation) iga kõnealuse sõlme jaoks, et määrata kõige sobivam sõlm. Lõpuks plaanitakse käivitamine kõige rohkem punkte saanud sõlmes (siin on koht, kus kaks sõlme saavad samasuguse punktide arvu 100037, seetõttu valitakse neist juhuslik, nimelt nxs-k8s-s10).

Kokkuvõte: kui sõlmedes töötavad podid, mille jaoks ei ole piiranguid määratud, siis k8si jaoks (ressursikasutuse mõttes) on see sama nagu kui sellised podid ei oleks üldse olemas. Seetõttu, kui teil on näiteks pod, millel on ressursinäljane protsess (nt wowza) ja millele ei ole piiranguid määratud, võib tekkida olukord, kus see pod on tegelikult söönud kõik sõlme ressursid, kuid k8si jaoks loetakse see sõlm mitte ülekoormatud ja sellel määratakse sama palju punkte hindamisel (nimelt k8si kergesti juurdepääsetavuse punktides) nagu sõlmele, millel pole töötavaid pode, mis lõpuks võib viia koormuse ebaühtlase jaotumiseni sõlmede vahel.

Podi väljaajamine

Nagu teada, määratakse igale podile üks kolmest QoS-klassist:

garanteeritud — määratakse siis, kui iga konteineri jaoks podis on määratud memory ja cpu jaoks request ja limit, ning need väärtused peavad olema ühesugused
burstable — vähemalt ühel konteineril podis on määratud request ja limit, ning request < limit
parim pingutus — kui ühtegi konteinerit podis ei piirati ressursside osas

Kui sõlmedes on täiendavaid ressursse (ketta, mäluga) vähem, alustab kubelet podide järjestamise ja väljatõstmise protsessi, järgides kindlat algoritmi, mis arvestab podi prioriteedi ja tema QoS-klassi. Näiteks kui on jutt RAM-ist, siis QoS klassi põhjal määratakse punktid järgmise põhimõtte kohaselt:

Tagatud: -998
Parim Pingutus: 1000
Purskamine: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

See tähendab, et sama prioriteedi korral hakkab kubelet esmajoones välja tõstma sõlmedest pod'e, millel on QoS-klassi parim pingutus.

Kokkuvõte: kui soovite vähendada vajaliku pod-i väljatõstmise tõenäosust sõlmest ressursipuuduse korral, siis peab lisaks prioriteedile olema hoolt kando ka request/limit määramise eest.

Rakenduste podide horisontaalpõhine automaatne skaleerimine (HPA)

Kui eesmärgiks on automaatselt suurendada ja väiksemaks muuta pod'ide arvu sõltuvalt ressursside kasutusest (süsteemi — CPU/RAM või kasutaja — rps), siis võib selle lahendamiseks aidata selline k8s üksus nagu HPA (Horisontaalne Pod Automaatne Skaleerija). Selle algoritm seisneb järgnevates detailides:

Määratakse vaadeldava ressursi (currentMetricValue) praegused näidud
Määratakse ressursi soovitud väärtused (desiredMetricValue), mis määratakse süsteemiressursside jaoks nõude kaudu
Määratakse hetke replikate arv (currentReplicas)
Järgmise valemi alusel arvutatakse soovitud replikate arv (desiredReplicas)
desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]

Kuna skaleerimist ei toimu, kui koefitsient (currentMetricValue / desiredMetricValue) on lähedal 1 (samuti saame ise määrata lubatud vea, mille vaikeväärtus on 0,1).

Vaatleme hpa toimimist rakenduse app-test näitel (mida on kirjeldatud kui Deployment), kus on vajalik muuta replikate arvu vastavalt CPU tarbimisele:

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

See, et rakenduse käivitamine toimub algselt kahes eksemplaris, millest igaühes on kaks konteinerit nginx ja nginx-exporter, millele on määratud requests CPU.

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

Seega, oleme loonud hpa, mis jälgib Deployment'i app-test ja reguleerib rakenduse pod'ide arvu CPU näitajate alusel (ootame, et pod tarbib 30% küsitud CPU-st), samas kui replikate arv jääb vahemikku 2-10.

Nüüd vaatame hpa toimimise mehhanismi, kui ühele pod'ile koormust rakendada:

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

Kokkuvõttes saame järgmise:

Soovitud väärtus (desiredMetricValue) — vastavalt hpa seadistustele on see 30%
Praegune väärtus (currentMetricValue) — controller-manager arvutab keskmise ressursside tarbimise protsendi, st tõenäoliselt teeb järgmist:
1. Saab metrikate absoluutväärtused metrikaserverist, st 101m ja 4m
2. Arvutab keskmise absoluutse väärtuse, st (101m + 4m) / 2 = 53m
3. Hankige absoluutne väärtus soovitud ressursitarbimise jaoks (selleks liidetakse kõigi konteinerite request'id) 60m + 30m = 90m
4. Arvutab CPU tarbimise keskmise protsendi võrreldes poda request'iga, st 53m / 90m * 100% = 59%

Nüüd on meil kõik vajalik, et määrata, kas replikaide arvu tuleb muuta, selleks arvutame koefitsiendi:

ratio = 59% / 30% = 1.96

St replikaide arvu tuleks suurendada ~2 korda ja see peaks olema [2 * 1.96] = 4.

Väljund: Nagu näha, et see mehhanism toimiks, on vajalikud tingimused, sealhulgas requests'i olemasolu kõigi konteinerite jaoks jälgitavas pod'is.

Klusteri automaatne horisontaalne skaleerimine (Cluster Autoscaler)

Süsteemi negatiivse mõju leevendamiseks koormuse tõusude ajal ei pruugi hpa olemasolu olla piisav. Näiteks, hpa controller manager'i seade kohaselt otsustatakse, et replikaide arvu tuleb kahekordistada, kuid node'idel ei ole piisavalt ressursse sellise hulga pod'ide käitamiseks (st node ei saa pakkuda nõutavaid ressursse pod'i requests) ja need pod'id lähevad Pending olekusse.

Selles olukorras, kui teenusepakkujal on vastav IaaS/PaaS (näiteks GKE/GCE, AKS, EKS jne), võib meid aidata selline tööriist nagu Node Autoscaler. See võimaldab seada klastris maksimaalne ja minimaalne node'i arv ning automaatselt reguleerida praegust node'ide arvu (kasutades pilveteenuse pakkuja API-d node'i tellimiseks/ kustutamiseks), kui klastris on ressursid puudulikud ja pod'e ei saa planeerida (nad on olekus Pending).

Väljund: Node'ide automaatse skaleerimise võimaldamiseks on vajalik määrata päringud pod'i konteinerites, et k8s saaks õigesti hinnata node'ide koormust ning vastavalt teavitada, et järgmise pod'i käitamiseks pole klastris ressursse.

Kokkuvõte

Oluline on märkida, et konteineri ressursside piirangute seadmine ei ole rakenduse eduka käitamise kohustuslik tingimus, kuid see on siiski parem teha järgmiste põhjuste tõttu:

Et scheduler toimiks täpsemalt node'ide vahelise koormuse jaotamise osas k8s
Et vähendada võimalust “pod'i väljatõukamise” sündmuseks
Et korraldada rakenduse pod'ide horisontaalset automaatset skaleerimist (HPA)
Horisontaalsete automaatsete skaalade (Cluster Autoscaling) tööks pilvteenuse pakkujate juures

Vaata ka teisi artikleid meie blogis:

Allikas: habr.com