Som regel er der altid behov for at levere en dedikeret pulje af ressourcer til en applikation for dens korrekte og stabile drift. Men hvad hvis flere applikationer kører på samme strøm? Hvordan giver man hver af dem de mindst nødvendige ressourcer? Hvordan kan du begrænse ressourceforbruget? Hvordan fordeles belastningen korrekt mellem noder? Hvordan sikrer man, at den horisontale skaleringsmekanisme fungerer, hvis applikationsbelastningen stiger?
Du skal starte med, hvilke hovedtyper af ressourcer der findes i systemet - dette er selvfølgelig processortid og RAM. I k8s manifester måles disse ressourcetyper i følgende enheder:
- CPU - i kerner
- RAM - i bytes
Desuden er det for hver ressource muligt at stille to typer krav - anmodninger и grænser. Anmodninger - beskriver minimumskravene til frie ressourcer for en node til at køre en container (og pod som helhed), mens limits sætter en hård grænse for de ressourcer, der er tilgængelige for containeren.
Det er vigtigt at forstå, at manifestet ikke eksplicit behøver at definere begge typer, men adfærden vil være som følger:
- Hvis kun grænserne for en ressource er eksplicit angivet, antager anmodninger om denne ressource automatisk en værdi svarende til grænser (du kan bekræfte dette ved at kalde beskriv entiteter). De der. faktisk vil containeren være begrænset til den samme mængde ressourcer, som den kræver for at køre.
- Hvis kun anmodninger er eksplicit angivet for en ressource, så er der ingen øvre restriktioner sat på denne ressource - dvs. beholderen er kun begrænset af ressourcerne i selve noden.
Det er også muligt at konfigurere ressourcestyring ikke kun på niveauet af en specifik container, men også på navnerumsniveauet ved hjælp af følgende entiteter:
- LimitRange — beskriver begrænsningspolitikken på container/pod-niveau i ns og er nødvendig for at beskrive standardgrænserne for containeren/pods, samt forhindre oprettelsen af åbenlyst fede containere/pods (eller omvendt), begrænse deres antal og bestemme den mulige forskel i værdierne i grænser og anmodninger
- Ressourcekvoter — beskriv begrænsningspolitikken generelt for alle containere i ns og bruges som regel til at afgrænse ressourcer mellem miljøer (nyttigt når miljøer ikke er strengt afgrænset på nodeniveau)
Følgende er eksempler på manifester, der sætter ressourcegrænser:
-
På det specifikke beholderniveau:
containers: - name: app-nginx image: nginx resources: requests: memory: 1Gi limits: cpu: 200mDe der. i dette tilfælde, for at køre en container med nginx, skal du have mindst 1G ledig RAM og 0.2 CPU på noden, mens containeren højst kan forbruge 0.2 CPU og al tilgængelig RAM på noden.
-
På heltalsniveauet ns:
apiVersion: v1 kind: ResourceQuota metadata: name: nxs-test spec: hard: requests.cpu: 300m requests.memory: 1Gi limits.cpu: 700m limits.memory: 2GiDe der. summen af alle anmodningsbeholdere i standard-ns kan ikke overstige 300m for CPU'en og 1G for OP'en, og summen af alle grænser er 700m for CPU'en og 2G for OP'en.
-
Standardgrænser for containere i 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: 4GiDe der. i standardnavneområdet for alle containere vil anmodningen blive sat til 100m for CPU og 1G for OP, grænse - 1 CPU og 2G. Samtidig sættes der også en grænse for de mulige værdier i request/limit for CPU (50m < x < 2) og RAM (500M < x < 4G).
-
Begrænsninger på pod-niveau ns:
apiVersion: v1 kind: LimitRange metadata: name: nxs-limit-pod spec: limits: - type: Pod max: cpu: 4 memory: 1GiDe der. for hver pod i standard ns vil der være en grænse på 4 vCPU og 1G.
Nu vil jeg gerne fortælle dig, hvilke fordele det kan give os ved at sætte disse begrænsninger.
Belastningsbalanceringsmekanisme mellem noder
Som du ved, er k8s-komponenten ansvarlig for fordelingen af pods blandt noder, som f.eks scheduler, som fungerer efter en bestemt algoritme. Denne algoritme gennemgår to trin, når du vælger den optimale node, der skal startes:
- filtrering
- Rangering
De der. i henhold til den beskrevne politik vælges der i første omgang noder, hvorpå det er muligt at starte en pod baseret på et sæt prædikater (inklusive kontrol af, om noden har nok ressourcer til at køre poden - PodFitsResources), og derefter for hver af disse noder, iflg. prioriteter point tildeles (inklusive, jo flere ledige ressourcer en node har, jo flere point tildeles den - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation), og poden startes på den node med flest point (hvis flere noder opfylder denne betingelse på én gang, så en tilfældig er valgt).
Samtidig skal du forstå, at skemalæggeren, når den vurderer de tilgængelige ressourcer i en node, er styret af de data, der er gemt i etcd - dvs. for mængden af den anmodede/begrænse ressource for hver pod, der kører på denne node, men ikke for det faktiske ressourceforbrug. Denne information kan fås fra kommandoudgangen kubectl describe node $NODE, for eksempel:
# 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%)Her ser vi alle pods, der kører på en specifik node, såvel som de ressourcer, som hver pod anmoder om. Og her er, hvordan planlægningsloggene ser ud, når cronjob-cron-events-1573793820-xt6q9 pod'en startes (denne information vises i planlægningsloggen, når du indstiller det 10. logningsniveau i opstartskommando-argumenterne -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-s10Her ser vi, at skemalæggeren i første omgang filtrerer og genererer en liste med 3 noder, som den kan startes på (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Derefter beregner den score baseret på flere parametre (inklusive BalancedResourceAllocation, LeastResourceAllocation) for hver af disse noder for at bestemme den bedst egnede node. I sidste ende er poden planlagt på noden med det højeste antal point (her har to noder på én gang det samme antal point 100037, så en tilfældig vælges - nxs-k8s-s10).
Output: hvis en node kører pods, for hvilke der ikke er sat restriktioner, så vil dette for k8s (ud fra et ressourceforbrugssynspunkt) svare til, som om der overhovedet ikke var sådanne pods på denne node. Derfor, hvis du, betinget, har en pod med en frådsende proces (for eksempel wowza), og der ikke er sat begrænsninger for det, så kan der opstå en situation, hvor denne pod faktisk spiste alle nodens ressourcer, men for k8s denne node betragtes som ubelastet, og det vil blive tildelt det samme antal point ved rangering (præcis i point, der vurderer tilgængelige ressourcer) som en node, der ikke har arbejdende pods, hvilket i sidste ende kan føre til ujævn fordeling af belastningen mellem noder.
Pods udsættelse
Som du ved, er hver pod tildelt en af 3 QoS-klasser:
- garanteret — tildeles, når der for hver beholder i poden er angivet en anmodning og grænse for hukommelse og cpu, og disse værdier skal matche
- sprængbar — mindst én beholder i poden har en anmodning og en grænse, med anmodning < limit
- bedste indsats — når ikke en eneste beholder i poden er ressourcebegrænset
På samme tid, når en node oplever mangel på ressourcer (disk, hukommelse), begynder kubelet at rangere og fjerne pods i henhold til en specifik algoritme, der tager højde for podens prioritet og dens QoS-klasse. For eksempel, hvis vi taler om RAM, så tildeles point baseret på QoS-klassen efter følgende princip:
- Garanteret: -998
- Bedste forsøg: 1000
- Sprængbar: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
De der. med samme prioritet, vil kubelet først fordrive pods med den bedste QoS-klasse fra noden.
Output: hvis du vil reducere sandsynligheden for, at den ønskede pod bliver smidt ud af noden i tilfælde af manglende ressourcer på den, så skal du sammen med prioriteringen også sørge for at sætte anmodningen/grænsen for den.
Mekanisme til horisontal autoskalering af applikationspuder (HPA)
Når opgaven er automatisk at øge og mindske antallet af pods afhængigt af brugen af ressourcer (system - CPU/RAM eller bruger - rps), f.eks. en k8s-entitet som HPA (Horizontal Pod Autoscaler). Algoritmen er som følger:
- De aktuelle aflæsninger af den observerede ressource bestemmes (currentMetricValue)
- De ønskede værdier for ressourcen bestemmes (desiredMetricValue), som for systemressourcer indstilles ved hjælp af anmodning
- Det aktuelle antal replikaer bestemmes (currentReplicas)
- Følgende formel beregner det ønskede antal replikaer (ønskede replikaer)
ønsketReplicas = [ nuværendeReplicas * ( currentMetricValue / ønsketMetricValue )]
I dette tilfælde vil skalering ikke forekomme, når koefficienten (currentMetricValue / ønsketMetricValue) er tæt på 1 (i dette tilfælde kan vi selv indstille den tilladte fejl; som standard er den 0.1).
Lad os se på, hvordan hpa fungerer ved at bruge eksemplet med app-test-applikationen (beskrevet som Deployment), hvor det er nødvendigt at ændre antallet af replikaer afhængigt af CPU-forbrug:
-
Ansøgningsmanifest
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-statusDe der. vi ser, at applikationspoden i første omgang lanceres i to tilfælde, som hver indeholder to nginx- og nginx-eksportørbeholdere, for hver af dem en specificeret anmodninger til 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: 30De der. Vi oprettede en hpa, der vil overvåge implementeringsapp-testen og justere antallet af pods med applikationen baseret på cpu-indikatoren (vi forventer, at poden skal forbruge 30 % af den CPU, den anmoder om), med antallet af replikaer i intervallet 2-10.
Lad os nu se på mekanismen for hpa-drift, hvis vi påfører en belastning på en af ildstederne:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
I alt har vi følgende:
- Den ønskede værdi (desiredMetricValue) - i henhold til hpa-indstillingerne har vi 30%
- Aktuel værdi (currentMetricValue) - til beregning beregner controller-manager gennemsnitsværdien af ressourceforbrug i %, dvs. betinget gør følgende:
- Modtager absolutte værdier af pod-metrics fra metric-serveren, dvs. 101m og 4m
- Beregner den gennemsnitlige absolutte værdi, dvs. (101m + 4m) / 2 = 53m
- Får den absolutte værdi for det ønskede ressourceforbrug (til dette opsummeres anmodningerne fra alle containere) 60m + 30m = 90m
- Beregner den gennemsnitlige procentdel af CPU-forbruget i forhold til anmodningspoden, dvs. 53 m / 90 m * 100 % = 59 %
Nu har vi alt, hvad vi behøver for at bestemme, om vi skal ændre antallet af replikaer; For at gøre dette beregner vi koefficienten:
ratio = 59% / 30% = 1.96
De der. antallet af replikaer skal øges med ~2 gange og beløbe sig til [2 * 1.96] = 4.
Konklusion: Som du kan se, for at denne mekanisme skal fungere, er en nødvendig betingelse tilstedeværelsen af anmodninger om alle beholdere i den observerede pod.
Mekanisme til horisontal autoskalering af noder (Cluster Autoscaler)
For at neutralisere den negative påvirkning af systemet under belastningsstigninger er det ikke nok at have en konfigureret hpa. I henhold til indstillingerne i hpa controller manager beslutter den for eksempel, at antallet af replikaer skal øges med 2 gange, men noderne har ikke ledige ressourcer til at køre et sådant antal pods (dvs. noden kan ikke levere anmodede ressourcer til anmodningspoden), og disse pods skifter til tilstanden Afventer.
I dette tilfælde, hvis udbyderen har en tilsvarende IaaS/PaaS (f.eks. GKE/GCE, AKS, EKS osv.), vil et værktøj som f.eks. Node Autoscaler. Det giver dig mulighed for at indstille det maksimale og minimum antal noder i klyngen og automatisk justere det aktuelle antal noder (ved at kalde cloud-udbyderens API for at bestille/fjerne en node), når der mangler ressourcer i klyngen og pods kan ikke planlægges (er i afventende tilstand).
Konklusion: For at kunne autoskalere noder er det nødvendigt at indstille anmodninger i pod-beholderne, så k8s korrekt kan vurdere belastningen på noderne og følgelig rapportere, at der ikke er ressourcer i klyngen til at starte den næste pod.
Konklusion
Det skal bemærkes, at indstilling af containerressourcegrænser ikke er et krav for, at applikationen kan køre med succes, men det er stadig bedre at gøre det af følgende årsager:
- For mere nøjagtig drift af skemalæggeren med hensyn til belastningsbalancering mellem k8s noder
- For at reducere sandsynligheden for, at en "pod-eviction"-hændelse indtræffer
- For at horisontal autoskalering af applikationspuder (HPA) skal fungere
- Til horisontal autoskalering af noder (Cluster Autoscaling) for cloud-udbydere
Læs også andre artikler på vores blog:
Kilde: www.habr.com