Po pravilu, uvijek postoji potreba da se aplikaciji obezbijedi namjenski skup resursa za njen ispravan i stabilan rad. Ali šta ako nekoliko aplikacija radi na istu snagu? Kako svakom od njih obezbijediti minimum potrebnih resursa? Kako možete ograničiti potrošnju resursa? Kako pravilno rasporediti opterećenje između čvorova? Kako osigurati da mehanizam horizontalnog skaliranja radi ako se opterećenje aplikacije poveća?
Morate početi od toga koje glavne vrste resursa postoje u sistemu - to su, naravno, procesorsko vrijeme i RAM. U manifestima k8s ovi tipovi resursa se mjere u sljedećim jedinicama:
- CPU - u jezgrama
- RAM - u bajtovima
Štaviše, za svaki resurs moguće je postaviti dvije vrste zahtjeva - zahtjevi и granica. Zahtjevi - opisuje minimalne zahtjeve za slobodne resurse čvora za pokretanje kontejnera (i pod u cjelini), dok ograničenja postavljaju čvrsto ograničenje resursa dostupnih kontejneru.
Važno je shvatiti da manifest ne mora eksplicitno definirati oba tipa, ali će ponašanje biti sljedeće:
- Ako su samo ograničenja resursa eksplicitno specificirana, tada zahtjevi za ovaj resurs automatski uzimaju vrijednost jednaku ograničenjima (to možete provjeriti pozivanjem describe entiteta). One. u stvari, kontejner će biti ograničen na istu količinu resursa potrebnih za pokretanje.
- Ako su samo zahtjevi eksplicitno specificirani za resurs, tada se za ovaj resurs ne postavljaju gornja ograničenja - tj. kontejner je ograničen samo resursima samog čvora.
Takođe je moguće konfigurisati upravljanje resursima ne samo na nivou određenog kontejnera, već i na nivou imenskog prostora koristeći sledeće entitete:
- LimitRange — opisuje politiku ograničenja na nivou kontejnera/mahune u ns i potrebna je kako bi se opisala zadana ograničenja na kontejneru/mahuni, kao i spriječila stvaranje očigledno debelih kontejnera/mahuna (ili obrnuto), ograničila njihov broj i odrediti moguću razliku u vrijednostima u granicama i zahtjevima
- ResourceQuotas — opisati politiku ograničenja općenito za sve kontejnere u ns i koristi se, po pravilu, za razgraničenje resursa između okruženja (korisno kada okruženja nisu striktno razgraničena na nivou čvora)
Slijede primjeri manifesta koji postavljaju ograničenja resursa:
-
Na nivou specifičnog kontejnera:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mOne. u ovom slučaju, da biste pokrenuli kontejner sa nginxom, trebat će vam najmanje 1G slobodne RAM-a i 0.2 CPU-a na čvoru, dok kontejner može potrošiti najviše 0.2 CPU-a i svu raspoloživu RAM memoriju na čvoru.
-
Na nivou cijelog broja ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiOne. zbir svih kontejnera zahtjeva u zadanim ns ne može premašiti 300m za CPU i 1G za OP, a zbir svih ograničenja je 700m za CPU i 2G za OP.
-
Zadana ograničenja za kontejnere u 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: 4GiOne. u zadanom imenskom prostoru za sve kontejnere, zahtjev će biti postavljen na 100m za CPU i 1G za OP, ograničenje - 1 CPU i 2G. Istovremeno, postavljeno je i ograničenje na moguće vrijednosti u zahtjevu/ograničenju za CPU (50m < x < 2) i RAM (500M < x < 4G).
-
Ograničenja na nivou podova ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiOne. za svaki pod u zadanom ns će postojati ograničenje od 4 vCPU i 1G.
Sada bih vam želio reći koje nam prednosti može donijeti postavljanje ovih ograničenja.
Mehanizam za balansiranje opterećenja između čvorova
Kao što znate, k8s komponenta je odgovorna za distribuciju podova među čvorovima, kao što su planer, koji radi prema određenom algoritmu. Ovaj algoritam prolazi kroz dvije faze prilikom odabira optimalnog čvora za pokretanje:
- filtriranje
- Rasponu
One. prema opisanoj politici, inicijalno se biraju čvorovi na kojima je moguće pokrenuti pod na osnovu skupa predikati (uključujući provjeru da li čvor ima dovoljno resursa za pokretanje pod - PodFitsResources), a zatim za svaki od ovih čvorova, prema prioritete dodeljuju se bodovi (uključujući, što više slobodnih resursa ima čvor, više bodova mu se dodeljuje - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) i pod se pokreće na čvoru sa najviše poena (ako nekoliko čvorova istovremeno zadovoljava ovaj uslov, tada odabran je nasumično) .
Istovremeno, morate shvatiti da se planer, kada procjenjuje dostupne resurse čvora, vodi podacima koji su pohranjeni u etcd - tj. za iznos traženog/ograničenog resursa za svaki pod koji radi na ovom čvoru, ali ne i za stvarnu potrošnju resursa. Ove informacije se mogu dobiti iz izlaza naredbe kubectl describe node $NODE, na primjer:
# 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%)Ovdje vidimo sve podove koji rade na određenom čvoru, kao i resurse koje svaki pod zahtijeva. A evo kako izgledaju zapisnici planera kada se pokrene cronjob-cron-events-1573793820-xt6q9 pod (ova informacija će se pojaviti u dnevniku planera kada postavite 10. nivo evidentiranja u argumentima naredbe za pokretanje -v=10):
log
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-s10Ovdje vidimo da u početku planer filtrira i generiše listu od 3 čvora na kojima se može pokrenuti (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Zatim izračunava rezultate na osnovu nekoliko parametara (uključujući BalancedResourceAllocation, LeastResourceAllocation) za svaki od ovih čvorova kako bi odredio najprikladniji čvor. Na kraju, pod je zakazan na čvoru sa najvećim brojem bodova (ovdje dva čvora imaju isti broj bodova 100037, pa je odabran slučajni - nxs-k8s-s10).
zaključak: ako čvor pokreće podove za koje nisu postavljena ograničenja, onda će za k8s (sa stajališta potrošnje resursa) to biti ekvivalentno kao da takvih podova uopće nema na ovom čvoru. Stoga, ako, uvjetno, imate pod s proždrljivim procesom (na primjer, wowza) i za njega nisu postavljena ograničenja, tada može nastati situacija kada ovaj pod zapravo pojede sve resurse čvora, ali za k8s ovaj čvor smatra se neopterećenim i pri rangiranju će mu biti dodijeljen isti broj bodova (tačno u bodovima procjenjujući raspoložive resurse) kao čvor koji nema radne podove, što u konačnici može dovesti do neravnomjerne raspodjele opterećenja između čvorova.
Podova deložacija
Kao što znate, svakom modulu je dodijeljena jedna od 3 QoS klase:
- garantirano — dodjeljuje se kada se za svaki spremnik u pod-u specificiraju zahtjev i ograničenje za memoriju i procesor, a ove vrijednosti moraju odgovarati
- burstable — najmanje jedan kontejner u pod ima zahtjev i ograničenje, sa zahtjevom < limit
- najbolji trud — kada nijedan kontejner u kapsuli nije ograničen resursima
Istovremeno, kada čvor iskusi nedostatak resursa (disk, memorija), kubelet počinje rangirati i izbacivati podove prema specifičnom algoritmu koji uzima u obzir prioritet modula i njegovu QoS klasu. Na primjer, ako govorimo o RAM-u, tada se na osnovu QoS klase, bodovi dodjeljuju prema sljedećem principu:
- Garantovano: -998
- BestEffort: 1000
- Burstable: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
One. sa istim prioritetom, kubelet će prvo izbaciti podove sa QoS klasom najboljeg napora iz čvora.
zaključak: ako želite da smanjite vjerovatnoću da će željeni pod biti izbačen iz čvora u slučaju nedostatka resursa na njemu, tada uz prioritet, također morate voditi računa o postavljanju zahtjeva/ograničenja za njega.
Mehanizam za horizontalno automatsko skaliranje aplikacija (HPA)
Kada je zadatak da automatski povećava i smanjuje broj podova u zavisnosti od upotrebe resursa (sistem - CPU/RAM ili korisnik - rps), kao k8s entitet kao što je HPA (Horizontal Pod Autoscaler). Algoritam koji je sljedeći:
- Određuju se trenutna očitanja posmatranog resursa (currentMetricValue)
- Određuju se željene vrijednosti za resurs (desiredMetricValue), koje se za sistemske resurse postavljaju pomoću zahtjeva
- Određuje se trenutni broj replika (trenutne replike)
- Sljedeća formula izračunava željeni broj replika (desiredReplicas)
željene replike = [ trenutne replike * ( trenutna metrička vrijednost / željena vrijednost metrike )]
U ovom slučaju do skaliranja neće doći kada je koeficijent (currentMetricValue / desiredMetricValue) blizu 1 (u ovom slučaju možemo sami postaviti dozvoljenu grešku; po defaultu je 0.1).
Pogledajmo kako hpa radi na primjeru aplikacije za testiranje aplikacija (opisana kao Deployment), gdje je potrebno promijeniti broj replika ovisno o potrošnji CPU-a:
-
Manifest aplikacije
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-statusOne. vidimo da se aplikacijski pod inicijalno pokreće u dvije instance, od kojih svaka sadrži dva nginx i nginx-exporter kontejnera, za svaki od kojih je specificiran zahtjevi za 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: 30One. Napravili smo hpa koji će pratiti Deployment app-test i prilagođavati broj podova sa aplikacijom na osnovu indikatora procesora (očekujemo da pod treba da potroši 30% CPU-a koji zahteva), sa brojem replika u raspon od 2-10.
Sada, pogledajmo mehanizam rada hpa ako dovedemo opterećenje na jedno od ognjišta:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Ukupno imamo sljedeće:
- Željena vrijednost (desiredMetricValue) - prema hpa postavkama imamo 30%
- Trenutna vrijednost (currentMetricValue) - za proračun, kontrolor-menadžer izračunava prosječnu vrijednost potrošnje resursa u %, tj. uslovno radi sledeće:
- Prima apsolutne vrijednosti pod metrika od metričkog servera, tj. 101m i 4m
- Izračunava prosječnu apsolutnu vrijednost, tj. (101m + 4m) / 2 = 53m
- Dobiva apsolutnu vrijednost za željenu potrošnju resursa (za to se zbrajaju zahtjevi svih kontejnera) 60m + 30m = 90m
- Izračunava prosječan postotak potrošnje CPU-a u odnosu na modul zahtjeva, tj. 53m / 90m * 100% = 59%
Sada imamo sve što nam je potrebno da odredimo da li trebamo promijeniti broj replika da bismo to učinili, izračunavamo koeficijent:
ratio = 59% / 30% = 1.96
One. broj replika treba povećati za ~2 puta i iznositi [2 * 1.96] = 4.
Zaključak: Kao što vidite, da bi ovaj mehanizam funkcionisao, neophodan uslov je prisustvo zahteva za sve kontejnere u posmatranom pod-u.
Mehanizam za horizontalno automatsko skaliranje čvorova (Cluster Autoscaler)
Da bi se neutralizirao negativan utjecaj na sistem tokom prenapona opterećenja, nije dovoljno imati konfiguriran hpa. Na primjer, prema postavkama u upravitelju hpa kontrolera, odlučuje da se broj replika treba povećati za 2 puta, ali čvorovi nemaju slobodne resurse za pokretanje tolikog broja podova (tj. čvor ne može pružiti traženi resursi u modulu zahtjeva) i ovi podovi prelaze u stanje na čekanju.
U ovom slučaju, ako dobavljač ima odgovarajući IaaS/PaaS (na primjer, GKE/GCE, AKS, EKS, itd.), alat kao što je Node Autoscaler. Omogućava vam da postavite maksimalni i minimalni broj čvorova u klasteru i automatski prilagodite trenutni broj čvorova (pozivanjem API-ja dobavljača oblaka da naručite/uklonite čvor) kada postoji nedostatak resursa u klasteru i podovima ne mogu se zakazati (u stanju su na čekanju).
Zaključak: Da biste mogli automatski skalirati čvorove, potrebno je postaviti zahtjeve u pod kontejnere tako da k8s može ispravno procijeniti opterećenje na čvorovima i u skladu s tim prijaviti da u klasteru nema resursa za pokretanje sljedećeg pod.
zaključak
Treba napomenuti da postavljanje ograničenja resursa kontejnera nije uslov za uspješno pokretanje aplikacije, ali je ipak bolje to učiniti iz sljedećih razloga:
- Za precizniji rad planera u smislu balansiranja opterećenja između k8s čvorova
- Kako bi se smanjila vjerovatnoća da će se desiti "deložacija iz mahuna".
- Za horizontalno automatsko skaliranje aplikacijskih podova (HPA) za rad
- Za horizontalno automatsko skaliranje čvorova (Cluster Autoscaling) za dobavljače u oblaku
Pročitajte i druge članke na našem blogu:
izvor: www.habr.com