U pravilu uvijek postoji potreba za osiguravanjem namjenskog skupa resursa aplikaciji za njezin ispravan i stabilan rad. Ali što ako nekoliko aplikacija radi na istom napajanju? Kako svakom od njih osigurati minimalno potrebna sredstva? 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 s glavnim vrstama resursa koji postoje u sustavu - to je, naravno, procesorsko vrijeme i RAM. U manifestima k8s ove se vrste resursa mjere u sljedećim jedinicama:
- CPU - u jezgrama
- RAM - u bajtovima
Štoviše, za svaki resurs moguće je postaviti dvije vrste zahtjeva - zahtjeva и Limiti. Zahtjevi - opisuje minimalne zahtjeve za slobodne resurse čvora za pokretanje spremnika (i pod-a u cjelini), dok ograničenja postavljaju čvrsta ograničenja resursa dostupnih spremniku.
Važno je razumjeti da manifest ne mora eksplicitno definirati obje vrste, ali ponašanje će biti sljedeće:
- Ako su samo ograničenja resursa eksplicitno navedena, tada zahtjevi za ovaj resurs automatski uzimaju vrijednost jednaku ograničenjima (možete to provjeriti pozivanjem entiteta opisa). Oni. zapravo, spremnik će biti ograničen na istu količinu resursa koji su mu potrebni za rad.
- Ako su samo zahtjevi eksplicitno navedeni za resurs, tada se na ovaj resurs ne postavljaju gornja ograničenja - tj. spremnik je ograničen samo resursima samog čvora.
Također je moguće konfigurirati upravljanje resursima ne samo na razini određenog spremnika, već i na razini prostora imena koristeći sljedeće entitete:
- LimitRange — opisuje politiku ograničenja na razini spremnika/mahune u ns i potrebna je za opisivanje zadanih ograničenja na spremniku/mahuni, kao i za sprječavanje stvaranja očito masnih posuda/mahuna (ili obrnuto), ograničavanje njihovog broja te odrediti moguću razliku u vrijednostima u limitima i zahtjevima
- Kvote resursa — opisuje politiku ograničenja općenito za sve spremnike u ns-u i koristi se, u pravilu, za razgraničenje resursa između okruženja (korisno kada okruženja nisu strogo razgraničena na razini čvora)
Slijede primjeri manifesta koji postavljaju ograničenja resursa:
-
Na razini određenog spremnika:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mOni. u ovom slučaju, za pokretanje spremnika s nginxom trebat će vam najmanje 1G slobodnog RAM-a i 0.2 CPU-a na čvoru, dok najviše kontejner može potrošiti 0.2 CPU-a i svu dostupnu RAM-u na čvoru.
-
Na cjelobrojnoj razini ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiOni. zbroj svih spremnika zahtjeva u zadanom ns-u ne može premašiti 300 m za CPU i 1G za OP, a zbroj svih ograničenja je 700 m za CPU i 2G za OP.
-
Zadana ograničenja za spremnike 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: 4GiOni. u zadanom prostoru imena za sve spremnike, zahtjev će biti postavljen na 100m za CPU i 1G za OP, ograničenje - 1 CPU i 2G. U isto vrijeme, 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 razini pod:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiOni. za svaki pod u zadanom ns postojat će ograničenje od 4 vCPU-a i 1G.
Sada bih vam želio reći koje prednosti nam može dati postavljanje ovih ograničenja.
Mehanizam za uravnoteženje opterećenja između čvorova
Kao što znate, k8s komponenta je odgovorna za distribuciju podova među čvorovima, kao što je planer, koji radi prema određenom algoritmu. Ovaj algoritam prolazi kroz dvije faze pri odabiru optimalnog čvora za pokretanje:
- filtriranje
- Raspon
Oni. prema opisanoj politici inicijalno se odabiru čvorovi na kojima je moguće pokrenuti pod na temelju skupa predikati (uključujući provjeru ima li čvor dovoljno resursa za pokretanje modula - PodFitsResources), a zatim za svaki od tih čvorova, prema prioriteti dodjeljuju se bodovi (uključujući, što više slobodnih resursa čvor ima, više mu se bodova dodjeljuje - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) i pod se pokreće na čvoru s najviše bodova (ako nekoliko čvorova istovremeno zadovoljava ovaj uvjet, tada odabire se nasumično) .
U isto vrijeme, morate razumjeti da se planer, kada procjenjuje raspoložive resurse čvora, vodi podacima koji su pohranjeni u etcd - tj. za količinu traženog/ograničenog resursa svakog pod-a koji radi na ovom čvoru, ali ne i za stvarnu potrošnju resursa. Ove informacije mogu se 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 pod cronjob-cron-events-1573793820-xt6q9 (ova informacija će se pojaviti u zapisniku planera kada postavite 10. razinu zapisivanja u argumentima naredbe za pokretanje -v=10):
zapisnik
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 generira popis od 3 čvora na kojima se može pokrenuti (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Zatim izračunava rezultate na temelju nekoliko parametara (uključujući BalancedResourceAllocation, LeastResourceAllocation) za svaki od tih čvorova kako bi odredio najprikladniji čvor. U konačnici, pod je zakazan na čvoru s najvećim brojem bodova (ovdje dva čvora odjednom imaju isti broj bodova 100037, pa se odabire slučajni - nxs-k8s-s10).
Izlaz: ako čvor pokreće podove za koje nisu postavljena ograničenja, tada će za k8s (sa stajališta potrošnje resursa) to biti ekvivalentno kao da takvih podova na ovom čvoru uopće nema. Stoga, ako, uvjetno, imate mahunu s proždrljivim procesom (na primjer, wowza) i za nju nisu postavljena ograničenja, tada može doći do situacije kada je ova mahuna zapravo pojela sve resurse čvora, ali za k8s ovaj čvor smatra se neopterećenim i bit će mu dodijeljen isti broj bodova prilikom rangiranja (upravo u bodovima koji procjenjuju raspoložive resurse) kao i č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 podu je dodijeljena jedna od 3 QoS klase:
- zajamčeno — dodjeljuje se kada su za svaki spremnik u podu navedeni zahtjev i ograničenje za memoriju i procesor, a te se vrijednosti moraju podudarati
- rasprsnuti — najmanje jedan spremnik u modulu ima zahtjev i ograničenje, sa zahtjevom < ograničenje
- najbolji trud — kada niti jedan spremnik u kapsuli nije ograničen resursima
U isto vrijeme, kada čvor doživi nedostatak resursa (disk, memorija), kubelet počinje rangirati i izbacivati podove prema specifičnom algoritmu koji uzima u obzir prioritet poda i njegovu QoS klasu. Na primjer, ako govorimo o RAM-u, tada se na temelju QoS klase bodovi dodjeljuju prema sljedećem principu:
- Zajamčena: -998
- BestEffort: 1000
- Rasprsnuti: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Oni. s istim prioritetom, kubelet će prvo iz čvora izbaciti mahune s najboljom QoS klasom.
Izlaz: ako želite smanjiti vjerojatnost da željeni pod bude izbačen iz čvora u slučaju nedostatka resursa na njemu, tada uz prioritet morate voditi računa i o postavljanju zahtjeva/limita za njega.
Mehanizam za horizontalno automatsko skaliranje paketa aplikacija (HPA)
Kada je zadatak automatski povećati i smanjiti broj mahuna ovisno o korištenju resursa (sustav - CPU/RAM ili korisnik - rps), kao k8s entitet kao HPA (Horizontalni Pod Autoscaler). Algoritam je sljedeći:
- Određena su trenutna očitanja promatranog izvora (currentMetricValue)
- Određuju se željene vrijednosti za resurs (desiredMetricValue), koje se za resurse sustava postavljaju pomoću zahtjeva
- Određen je trenutni broj replika (currentReplicas)
- Sljedeća formula izračunava željeni broj replika (desiredReplicas)
željene replike = [ trenutne replike * ( trenutna metrička vrijednost / željena metrička vrijednost )]
U ovom slučaju, skaliranje se neće dogoditi kada je koeficijent (currentMetricValue / desireMetricValue) blizu 1 (u ovom slučaju možemo sami postaviti dopuštenu pogrešku; prema zadanim postavkama ona je 0.1).
Pogledajmo kako radi hpa na primjeru aplikacije za testiranje aplikacije (opisane 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-statusOni. vidimo da se pod aplikacija inicijalno pokreće u dvije instance, od kojih svaka sadrži dva spremnika nginx i nginx-exporter, za svaki od kojih je specificiran zahtjeva za CPU.
-
Manifest 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: 30Oni. Napravili smo hpa koji će nadzirati test aplikacije Deployment i prilagoditi broj podova s aplikacijom na temelju indikatora procesora (očekujemo da bi pod trebao trošiti 30% CPU-a koji zahtijeva), s brojem replika u raspon od 2-10.
Sada, pogledajmo mehanizam rada hpa ako primijenimo 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 izračun kontroler-upravitelj izračunava prosječnu vrijednost potrošnje resursa u %, tj. uvjetno radi sljedeće:
- Prima apsolutne vrijednosti pod metrike od poslužitelja metrike, tj. 101m i 4m
- Izračunava prosječnu apsolutnu vrijednost, tj. (101m + 4m) / 2 = 53m
- Dobiva apsolutnu vrijednost za željenu potrošnju resursa (za ovo se zbrajaju zahtjevi svih spremnika) 60m + 30m = 90m
- Izračunava prosječni postotak potrošnje CPU-a u odnosu na pod zahtjev, tj. 53m / 90m * 100% = 59%
Sada imamo sve što nam je potrebno da odredimo trebamo li promijeniti broj replika; da bismo to učinili, izračunavamo koeficijent:
ratio = 59% / 30% = 1.96
Oni. broj replika treba povećati ~2 puta i iznositi [2 * 1.96] = 4.
Zaključak: Kao što vidite, da bi ovaj mehanizam funkcionirao, neophodan uvjet je prisutnost zahtjeva za sve spremnike u promatranoj grupi.
Mehanizam za horizontalno automatsko skaliranje čvorova (Cluster Autoscaler)
Da bi se neutralizirao negativan utjecaj na sustav tijekom skokova 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 slobodnih resursa za pokretanje takvog broja podova (tj. čvor ne može pružiti zatražene resurse u modul zahtjeva) i ti moduli se prebacuju u stanje na čekanju.
U ovom slučaju, ako pružatelj ima odgovarajući IaaS/PaaS (na primjer, GKE/GCE, AKS, EKS itd.), alat poput Automatsko skaliranje čvorova. Omogućuje vam postavljanje maksimalnog i minimalnog broja čvorova u klasteru i automatsku prilagodbu trenutnog broja čvorova (pozivanjem API-ja pružatelja usluga oblaka za naručivanje/uklanjanje čvora) kada nedostaje resursa u klasteru i podovima nije moguće zakazati (u stanju su na čekanju).
Zaključak: Da biste mogli autoscale čvorove, potrebno je postaviti zahtjeve u pod kontejnere kako bi k8s mogao ispravno procijeniti opterećenje na čvorovima i sukladno tome izvijestiti da u klasteru nema resursa za pokretanje sljedećeg poda.
Zaključak
Treba napomenuti da postavljanje ograničenja resursa spremnika nije preduvjet za uspješno pokretanje aplikacije, no ipak je bolje to učiniti iz sljedećih razloga:
- Za precizniji rad planera u smislu uravnoteženja opterećenja između k8s čvorova
- Kako bi se smanjila vjerojatnost pojave događaja "izbacivanja mahune".
- Za rad horizontalnog automatskog skaliranja aplikacijskih grupa (HPA).
- Za horizontalno automatsko skaliranje čvorova (Cluster Autoscaling) za cloud providere
Također pročitajte ostale članke na našem blogu:
Izvor: www.habr.com