Praviloma je za pravilno in stabilno delovanje aplikacije vedno treba zagotoviti namensko zbirko virov. Kaj pa, če več aplikacij deluje na isto moč? Kako vsakemu od njih zagotoviti minimalna potrebna sredstva? Kako lahko omejite porabo virov? Kako pravilno porazdeliti obremenitev med vozlišči? Kako zagotoviti, da mehanizem horizontalnega skaliranja deluje, če se obremenitev aplikacije poveča?
Začeti morate s tem, katere glavne vrste virov obstajajo v sistemu - to je seveda procesorski čas in RAM. V manifestih k8s se te vrste virov merijo v naslednjih enotah:
- CPE - v jedrih
- RAM - v bajtih
Poleg tega je za vsak vir mogoče nastaviti dve vrsti zahtev - zahteva и Meje. Zahteve – opisuje minimalne zahteve za proste vire vozlišča za zagon vsebnika (in sklopa kot celote), medtem ko omejitve določajo strogo omejitev virov, ki so na voljo vsebniku.
Pomembno je razumeti, da manifestu ni treba izrecno definirati obeh vrst, vendar bo vedenje naslednje:
- Če so izrecno podane samo omejitve vira, potem zahteve za ta vir samodejno prevzamejo vrednost, ki je enaka omejitvam (to lahko preverite s klicem opisnih entitet). Tisti. pravzaprav bo vsebnik omejen na enako količino virov, ki jih potrebuje za delovanje.
- Če so za vir izrecno podane samo zahteve, za ta vir niso nastavljene zgornje omejitve – tj. vsebnik je omejen le z viri samega vozlišča.
Prav tako je mogoče konfigurirati upravljanje virov ne le na ravni določenega vsebnika, temveč tudi na ravni imenskega prostora z uporabo naslednjih entitet:
- LimitRange — opisuje politiko omejevanja na ravni vsebnika/stroka v ns in je potreben za opis privzetih omejitev na vsebniku/stroku ter za preprečevanje ustvarjanja očitno mastnih posod/stroka (ali obratno), omejitev njihovega števila in ugotovi morebitno razliko v vrednostih v limitih in zahtevah
- ResourceQuotas — opisuje politiko omejitev na splošno za vse vsebnike v ns in se praviloma uporablja za razmejitev virov med okolji (uporabno, ko okolja niso strogo razmejena na ravni vozlišča)
Sledijo primeri manifestov, ki določajo omejitve virov:
-
Na ravni določenega vsebnika:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mTisti. v tem primeru boste za zagon vsebnika z nginxom potrebovali vsaj 1 G prostega RAM-a in 0.2 CPE na vozlišču, medtem ko lahko vsebnik porabi največ 0.2 CPU in ves razpoložljivi RAM na vozlišču.
-
Na ravni celega števila ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiTisti. vsota vseh vsebnikov zahtev v privzetem ns ne more preseči 300 m za CPE in 1G za OP, vsota vseh omejitev pa je 700 m za CPE in 2G za OP.
-
Privzete omejitve za vsebnike v 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: 4GiTisti. v privzetem imenskem prostoru za vse vsebnike bo zahteva nastavljena na 100m za CPE in 1G za OP, omejitev - 1 CPU in 2G. Hkrati je postavljena tudi omejitev možnih vrednosti v zahtevku/omejitev za CPU (50m < x < 2) in RAM (500M < x < 4G).
-
Omejitve na ravni sklopa ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiTisti. za vsak pod v privzetem ns bo veljala omejitev 4 vCPE in 1G.
Zdaj bi vam rad povedal, kakšne prednosti nam lahko da nastavitev teh omejitev.
Mehanizem za uravnoteženje obremenitve med vozlišči
Kot veste, je komponenta k8s odgovorna za porazdelitev podov med vozlišči, kot je npr scheduler, ki deluje po določenem algoritmu. Ta algoritem gre skozi dve stopnji pri izbiri optimalnega vozlišča za zagon:
- filtriranje
- Razpon
Tisti. v skladu z opisano politiko se na začetku izberejo vozlišča, na katerih je možno zagnati pod na podlagi nabora predikati (vključno s preverjanjem, ali ima vozlišče dovolj virov za zagon sklopa – PodFitsResources), nato pa za vsako od teh vozlišč glede na prednostne naloge se dodelijo točke (vključno s tem, da več prostih virov ima vozlišče, več točk mu je dodeljenih - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) in pod se zažene na vozlišču z največ točkami (če več vozlišč hkrati izpolnjuje ta pogoj, potem izbrana je naključna).
Hkrati morate razumeti, da načrtovalec pri ocenjevanju razpoložljivih virov vozlišča vodi podatke, ki so shranjeni v etcd - tj. za količino zahtevanega/omejenega vira vsakega sklopa, ki se izvaja na tem vozlišču, vendar ne za dejansko porabo vira. Te informacije je mogoče pridobiti iz izhoda ukaza kubectl describe node $NODE, na primer:
# 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%)Tukaj vidimo vse pode, ki se izvajajo na določenem vozlišču, kot tudi vire, ki jih vsak pod zahteva. In tako izgledajo dnevniki razporejevalnika, ko se zažene pod cronjob-cron-events-1573793820-xt6q9 (ta informacija se bo pojavila v dnevniku razporejevalnika, ko nastavite 10. raven beleženja v argumentih zagonskega ukaza -v=10):
dnevnik
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-s10Tukaj vidimo, da razporejevalnik na začetku filtrira in ustvari seznam treh vozlišč, na katerih se lahko zažene (nxs-k3s-s8, nxs-k8s-s8, nxs-k9s-s8). Nato izračuna rezultate na podlagi več parametrov (vključno z BalancedResourceAllocation, LeastResourceAllocation) za vsako od teh vozlišč, da določi najprimernejše vozlišče. Na koncu je pod načrtovan na vozlišču z največjim številom točk (tu imata dve vozlišči hkrati enako število točk 10, zato je izbrano naključno - nxs-k100037s-s8).
Izhod: če vozlišče izvaja pode, za katere niso nastavljene nobene omejitve, potem bo za k8s (z vidika porabe virov) to enakovredno, kot da takih podov na tem vozlišču sploh ne bi bilo. Torej, če imate pogojno pod s požrešnim procesom (na primer wowza) in zanj niso določene nobene omejitve, lahko pride do situacije, ko ta pod dejansko poje vse vire vozlišča, vendar za k8s to vozlišče se šteje za neobremenjeno in bo pri rangiranju (prav v točkah, ki ocenjujejo razpoložljive vire) dobilo enako število točk kot vozlišče, ki nima delujočih podov, kar lahko na koncu povzroči neenakomerno porazdelitev obremenitve med vozlišči.
Podova izselitev
Kot veste, je vsakemu podu dodeljen eden od 3 razredov QoS:
- zajamčeno — je dodeljen, ko sta za vsak vsebnik v podu določena zahteva in omejitev za pomnilnik in procesor, ti vrednosti pa se morata ujemati
- razpočen — vsaj en vsebnik v sklopu ima zahtevo in omejitev, pri čemer je zahteva < omejitev
- najboljši trud — ko noben vsebnik v sklopu ni omejen z viri
Istočasno, ko vozlišču primanjkuje sredstev (disk, pomnilnik), začne kubelet razvrščati in izrivati pode v skladu s specifičnim algoritmom, ki upošteva prednost poda in njegov razred QoS. Na primer, če govorimo o RAM-u, se na podlagi razreda QoS točke dodelijo po naslednjem načelu:
- Zajamčena: -998
- BestEffort: 1000
- Razpočen: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
Tisti. z enako prioriteto bo kubelet najprej iz vozlišča izgnal pode z najboljšim razredom QoS.
Izhod: če želite zmanjšati verjetnost, da bo želeni pod izgnan iz vozlišča v primeru pomanjkanja sredstev na njem, potem morate poleg prioritete poskrbeti tudi za nastavitev zahteve/omejitve zanj.
Mehanizem za vodoravno samodejno skaliranje podov aplikacij (HPA)
Ko je naloga samodejno povečati in zmanjšati število podov glede na uporabo virov (sistem - CPU/RAM ali uporabnik - rps), je takšna entiteta k8s, kot je HPA (Horizontalni pod Autoscaler). Algoritem tega je naslednji:
- Določeni so trenutni odčitki opazovanega vira (currentMetricValue)
- Določijo se želene vrednosti za vir (desiredMetricValue), ki se za sistemske vire nastavijo z uporabo zahteve
- Določeno je trenutno število replik (currentReplicas)
- Naslednja formula izračuna želeno število replik (desiredReplicas)
zaželene replike = [ trenutne replike * ( trenutnaMetricValue / zaželenaMetricValue )]
V tem primeru do skaliranja ne bo prišlo, ko je koeficient (currentMetricValue / desireMetricValue) blizu 1 (v tem primeru lahko sami nastavimo dovoljeno napako; privzeto je 0.1).
Poglejmo, kako deluje hpa na primeru aplikacije za testiranje aplikacije (opisane kot Deployment), kjer je treba spremeniti število replik glede na porabo procesorja:
-
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-statusTisti. vidimo, da se programski sklop na začetku zažene v dveh instancah, od katerih vsaka vsebuje dva vsebnika nginx in nginx-exporter, za vsakega od njih pa zahteva za procesor.
-
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: 30Tisti. Ustvarili smo hpa, ki bo spremljal preizkus aplikacije za uvedbo in prilagodil število podov z aplikacijo na podlagi indikatorja procesorja (pričakujemo, da bi pod moral porabiti 30 % zahtevanega procesorja), pri čemer je število replik v razpon 2-10.
Zdaj pa poglejmo mehanizem delovanja hpa, če obremenimo eno od kurišč:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
Skupno imamo naslednje:
- Želena vrednost (desiredMetricValue) - glede na nastavitve hpa imamo 30%
- Trenutna vrednost (currentMetricValue) - za izračun krmilnik-upravitelj izračuna povprečno vrednost porabe virov v %, tj. pogojno naredi naslednje:
- Prejema absolutne vrednosti metrik sklopov iz strežnika metrik, tj. 101m in 4m
- Izračuna povprečno absolutno vrednost, tj. (101 m + 4 m) / 2 = 53 m
- Dobi absolutno vrednost za želeno porabo virov (za to se seštejejo zahteve vseh vsebnikov) 60m + 30m = 90m
- Izračuna povprečni odstotek porabe procesorja glede na pod zahtevo, tj. 53 m / 90 m * 100 % = 59 %
Zdaj imamo vse, kar potrebujemo, da ugotovimo, ali moramo spremeniti število replik; za to izračunamo koeficient:
ratio = 59% / 30% = 1.96
Tisti. število replik je treba povečati za ~2-krat in znašati [2 * 1.96] = 4.
Zaključek: Kot lahko vidite, je za delovanje tega mehanizma nujen pogoj prisotnost zahtev za vse vsebnike v opazovanem sklopu.
Mehanizem za horizontalno samodejno skaliranje vozlišč (Cluster Autoscaler)
Da bi nevtralizirali negativni vpliv na sistem med skokovitimi obremenitvami, konfiguriran hpa ni dovolj. Na primer, glede na nastavitve v upravljalniku krmilnika hpa se odloči, da je treba število replik povečati za 2-krat, vendar vozlišča nimajo prostih virov za zagon takšnega števila podov (tj. vozlišče ne more zagotoviti zahtevane vire v sklop zahtev) in ti sklopi preklopijo v stanje čakanja.
V tem primeru, če ima ponudnik ustrezen IaaS/PaaS (na primer GKE/GCE, AKS, EKS itd.), orodje kot Vozlišče Autoscaler. Omogoča vam nastavitev največjega in najmanjšega števila vozlišč v gruči in samodejno prilagajanje trenutnega števila vozlišč (s klicem API-ja ponudnika oblaka za naročilo/odstranitev vozlišča), ko v gruči in podih primanjkuje virov. ni mogoče načrtovati (so v stanju čakanja).
Zaključek: Za možnost samodejnega skaliranja vozlišč je treba nastaviti zahteve v vsebnikih podov, tako da lahko k8s pravilno oceni obremenitev vozlišč in ustrezno sporoči, da v gruči ni sredstev za zagon naslednjega poda.
Zaključek
Upoštevati je treba, da nastavitev omejitev virov vsebnika ni pogoj za uspešno delovanje aplikacije, vendar je vseeno bolje, da to storite iz naslednjih razlogov:
- Za natančnejše delovanje razporejevalnika v smislu uravnoteženja obremenitve med vozlišči k8s
- Za zmanjšanje verjetnosti dogodka "izselitev pod".
- Za delovanje horizontalnega samodejnega skaliranja sklopov aplikacij (HPA).
- Za horizontalno samodejno skaliranje vozlišč (Cluster Autoscaling) za ponudnike v oblaku
Preberite tudi druge članke na našem blogu:
Vir: www.habr.com