ProHoster > blogg > administration > Kubernetes: varför är det så viktigt att ställa in systemresurshantering?

Kubernetes: varför är det så viktigt att ställa in systemresurshantering?

Som regel finns det alltid ett behov av att tillhandahålla en dedikerad pool av resurser till en applikation för att den ska fungera korrekt och stabil. Men vad händer om flera applikationer körs på samma ström? Hur ger man var och en av dem de minsta nödvändiga resurserna? Hur kan man begränsa resursförbrukningen? Hur fördelar man belastningen mellan noder korrekt? Hur säkerställer man att den horisontella skalningsmekanismen fungerar om applikationsbelastningen ökar?

Kubernetes: varför är det så viktigt att ställa in systemresurshantering?

Du måste börja med vilka huvudtyper av resurser som finns i systemet - detta är naturligtvis processortid och RAM. I k8s-manifest mäts dessa resurstyper i följande enheter:

  • CPU - i kärnor
  • RAM - i byte

Dessutom, för varje resurs är det möjligt att ställa två typer av krav - förfrågningar и gränser. Begäranden - beskriver minimikraven för fria resurser för en nod för att köra en behållare (och pod som helhet), medan limits sätter en hård gräns för de resurser som är tillgängliga för behållaren.

Det är viktigt att förstå att manifestet inte uttryckligen måste definiera båda typerna, men beteendet kommer att vara som följer:

  • Om endast gränserna för en resurs är explicit specificerade, får förfrågningar om denna resurs automatiskt ett värde som är lika med gränser (du kan verifiera detta genom att anropa beskriv entiteter). De där. i själva verket kommer behållaren att vara begränsad till samma mängd resurser som den kräver för att köras.
  • Om endast förfrågningar är explicit specificerade för en resurs, så sätts inga övre begränsningar för denna resurs - dvs. behållaren begränsas endast av själva nodens resurser.

Det är också möjligt att konfigurera resurshantering inte bara på nivån för en specifik behållare, utan också på namnområdesnivån med hjälp av följande entiteter:

  • LimitRange — beskriver begränsningspolicyn på behållare/kapselnivå i ns och behövs för att beskriva standardgränserna för behållaren/kapseln, samt förhindra skapandet av uppenbart feta behållare/kapslar (eller vice versa), begränsa antalet och bestäm den möjliga skillnaden i värdena i gränser och förfrågningar
  • Resurskvoter — beskriv begränsningspolicyn generellt för alla behållare i ns och används som regel för att avgränsa resurser mellan miljöer (användbart när miljöer inte är strikt avgränsade på nodnivå)

Följande är exempel på manifest som sätter resursgränser:

  • På den specifika behållarnivån:

    containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m

    De där. i det här fallet, för att köra en behållare med nginx, behöver du minst 1G ledigt RAM och 0.2 CPU på noden, medan behållaren som mest kan förbruka 0.2 CPU och allt tillgängligt RAM på noden.

  • På heltalsnivån ns:

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi

    De där. summan av alla begärandebehållare i standard-ns kan inte överstiga 300m för CPU och 1G för OP, och summan av alla gränser är 700m för CPU och 2G för OP.

  • Standardgränser för behållare 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: 4Gi

    De där. i standardnamnutrymmet för alla behållare, kommer begäran att ställas in på 100m för CPU och 1G för OP, gräns - 1 CPU och 2G. Samtidigt sätts också en gräns på möjliga värden i begäran/gräns för CPU (50m < x < 2) och RAM (500M < x < 4G).

  • Begränsningar på podnivå ns:

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

    De där. för varje pod i standard-ns kommer det att finnas en gräns på 4 vCPU och 1G.

Nu skulle jag vilja berätta vilka fördelar att sätta dessa begränsningar kan ge oss.

Lastbalanseringsmekanism mellan noder

Som ni vet är k8s-komponenten ansvarig för fördelningen av pods mellan noder, som t.ex schemaläggare, som fungerar enligt en specifik algoritm. Denna algoritm går igenom två steg när man väljer den optimala noden att starta:

  1. filtrering
  2. Rangering

De där. enligt den beskrivna policyn väljs initialt noder på vilka det är möjligt att starta en pod baserat på en uppsättning predikat (inklusive att kontrollera om noden har tillräckligt med resurser för att köra podden - PodFitsResources), och sedan för var och en av dessa noder, enligt prioriteter poäng tilldelas (inklusive, ju fler lediga resurser en nod har, desto fler poäng tilldelas den - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) och podden startas på noden med flest poäng (om flera noder uppfyller detta villkor samtidigt, då en slumpmässig en väljs).

Samtidigt måste du förstå att schemaläggaren, när den bedömer de tillgängliga resurserna för en nod, styrs av data som lagras i etcd - d.v.s. för mängden av den begärda/begränsningsresursen för varje pod som körs på denna nod, men inte för den faktiska resursförbrukningen. Denna information kan erhållas från kommandoutgången kubectl describe node $NODE, till exempel:

# 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%)

Här ser vi alla poddar som körs på en specifik nod, såväl som resurserna som varje pod begär. Och så här ser schemaläggningsloggarna ut när podden cronjob-cron-events-1573793820-xt6q9 startas (den här informationen kommer att visas i schemaläggningsloggen när du ställer in den tionde loggningsnivån i startkommandoargumenten -v=10):

logga

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-s10

Här ser vi att schemaläggaren initialt filtrerar och genererar en lista med 3 noder som den kan startas på (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Sedan beräknar den poäng baserat på flera parametrar (inklusive BalancedResourceAllocation, LeastResourceAllocation) för var och en av dessa noder för att bestämma den mest lämpliga noden. I slutändan är podden schemalagd på noden med det högsta antalet punkter (här har två noder samtidigt samma antal punkter 100037, så en slumpmässig en väljs - nxs-k8s-s10).

Utgång: om en nod kör pods för vilka inga restriktioner är satta, då för k8s (ur synvinkel av resursförbrukning) kommer detta att motsvara som om det inte fanns några sådana pods på denna nod alls. Därför, om du, villkorligt, har en pod med en frossande process (till exempel wowza) och inga begränsningar är satta för den, kan en situation uppstå när denna pod faktiskt åt upp alla resurserna i noden, men för k8s denna nod anses vara obelastad och den kommer att tilldelas samma antal poäng vid rankning (precis i poäng som bedömer tillgängliga resurser) som en nod som inte har fungerande pods, vilket i slutändan kan leda till ojämn fördelning av belastningen mellan noder.

Pods vräkning

Som ni vet är varje pod tilldelad en av tre QoS-klasser:

  1. garanterat — tilldelas när för varje behållare i podden en begäran och gräns anges för minne och cpu, och dessa värden måste matcha
  2. sprängbar — minst en behållare i podden har en begäran och en gräns, med begäran < gräns
  3. bästa ansträngningen — när inte en enda behållare i kapseln är resursbegränsad

Samtidigt, när en nod upplever brist på resurser (disk, minne), börjar kubelet rangordna och vräka pods enligt en specifik algoritm som tar hänsyn till poddens prioritet och dess QoS-klass. Till exempel, om vi pratar om RAM, baserat på QoS-klassen, tilldelas poäng enligt följande princip:

  • Garanterat:-998
  • Bästa insats: 1000
  • Sprängbar: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

De där. med samma prioritet kommer kubelet först att vräka ut poddar med den bästa QoS-klassen från noden.

Utgång: om du vill minska sannolikheten för att den önskade podden ska vräkas från noden i händelse av brist på resurser på den, så måste du tillsammans med prioriteringen också ta hand om att ställa in begäran/gränsen för den.

Mekanism för horisontell autoskalning av applikationskapslar (HPA)

När uppgiften är att automatiskt öka och minska antalet pods beroende på användningen av resurser (system - CPU/RAM eller användare - rps), till exempel en k8s-enhet som HPA (Horizontal Pod Autoscaler). Algoritmen är som följer:

  1. Aktuella avläsningar av den observerade resursen bestäms (currentMetricValue)
  2. De önskade värdena för resursen bestäms (desiredMetricValue), som för systemresurser ställs in med begäran
  3. Det aktuella antalet repliker bestäms (currentReplicas)
  4. Följande formel beräknar det önskade antalet repliker (önskade kopior)
    desireReplicas = [ currentReplicas * ( currentMetricValue / wantedMetricValue )]

I det här fallet kommer inte skalning att ske när koefficienten (currentMetricValue / ønsketMetricValue) är nära 1 (i det här fallet kan vi ställa in det tillåtna felet själva; som standard är det 0.1).

Låt oss titta på hur hpa fungerar med exemplet med app-testapplikationen (beskriven som Deployment), där det är nödvändigt att ändra antalet repliker beroende på CPU-förbrukning:

  • Ansökningsmanifest

    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

    De där. vi ser att applikationspodden initialt lanseras i två instanser, som var och en innehåller två nginx- och nginx-exporterbehållare, för var och en en specificerad förfrågningar för 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

    De där. Vi skapade en hpa som kommer att övervaka app-testet för Deployment och justera antalet poddar med programmet baserat på CPU-indikatorn (vi förväntar oss att podden ska förbruka 30 % av den CPU som den begär), med antalet repliker i intervallet 2-10.

    Låt oss nu titta på mekanismen för hpa-drift om vi applicerar en belastning på en av härdarna:

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

Totalt har vi följande:

  • Det önskade värdet (önskatMetricValue) - enligt hpa-inställningarna har vi 30%
  • Nuvarande värde (currentMetricValue) - för beräkning beräknar controller-manager medelvärdet av resursförbrukningen i %, d.v.s. villkorligt gör följande:
    1. Tar emot absoluta värden av pod-mått från metrisk server, d.v.s. 101m och 4m
    2. Beräknar det genomsnittliga absolutvärdet, dvs. (101m + 4m) / 2 = 53m
    3. Får det absoluta värdet för den önskade resursförbrukningen (för detta summeras förfrågningarna från alla containrar) 60m + 30m = 90m
    4. Beräknar den genomsnittliga procentandelen av CPU-förbrukningen i förhållande till begäran pod, dvs. 53 m / 90 m * 100 % = 59 %

Nu har vi allt vi behöver för att avgöra om vi behöver ändra antalet repliker; för att göra detta beräknar vi koefficienten:

ratio = 59% / 30% = 1.96

De där. antalet repliker bör ökas med ~2 gånger och uppgå till [2 * 1.96] = 4.

Slutsats: Som du kan se, för att denna mekanism ska fungera, är ett nödvändigt villkor närvaron av förfrågningar för alla behållare i den observerade poden.

Mekanism för horisontell autoskalning av noder (Cluster Autoscaler)

För att neutralisera den negativa påverkan på systemet under belastningsstörningar räcker det inte att ha en konfigurerad hpa. Till exempel, enligt inställningarna i hpa controller manager, beslutar den att antalet repliker måste ökas med 2 gånger, men noderna har inte lediga resurser för att köra ett sådant antal pods (dvs. noden kan inte tillhandahålla begärde resurser till förfrågningar pod) och dessa pods växlar till väntande tillstånd.

I det här fallet, om leverantören har en motsvarande IaaS/PaaS (till exempel GKE/GCE, AKS, EKS, etc.), ett verktyg som Node Autoscaler. Det låter dig ställa in det maximala och lägsta antalet noder i klustret och automatiskt justera det aktuella antalet noder (genom att anropa molnleverantörens API för att beställa/ta bort en nod) när det saknas resurser i klustret och poddarna kan inte schemaläggas (är i väntande läge).

Slutsats: För att kunna autoskala noder är det nödvändigt att ställa in förfrågningar i podcontainrarna så att k8s korrekt kan bedöma belastningen på noderna och följaktligen rapportera att det inte finns några resurser i klustret för att starta nästa pod.

Slutsats

Det bör noteras att det inte är ett krav att ställa in containerresursgränser för att applikationen ska köras, men det är ändå bättre att göra det av följande skäl:

  1. För mer exakt drift av schemaläggaren när det gäller lastbalansering mellan k8s noder
  2. För att minska sannolikheten för att en "pod eviction"-händelse inträffar
  3. För att horisontell automatisk skalning av applikationspods (HPA) ska fungera
  4. För horisontell autoskalning av noder (Cluster Autoscaling) för molnleverantörer

Läs även andra artiklar på vår blogg:

Källa: will.com

Lägg en kommentar