Kubernetes: Varför är det så viktigt att konfigurera systemresursförvaltning?

I regel uppstår behovet av att tillhandahålla en dedikerad resurspool för någon applikation för att säkerställa dess korrekta och stabila drift. Men vad händer om flera applikationer körs på samma kapacitet? Hur kan man ge varje applikation minimalt nödvändiga resurser? Hur kan man begränsa resursanvändningen? Hur kan man smart fördela lasten mellan noderna? Hur kan man säkerställa att mekanismen för horisontell skalning fungerar vid ökad belastning på applikationerna?

Vi börjar med att definiera de huvudsakliga typerna av resurser i systemet — det handlar förstås om CPU-tid och RAM. I k8s-manifesten mäts dessa resurstyper i följande enheter:

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

För varje resurs finns det möjlighet att ställa in två typer av krav — requests och limits. Requests — beskriver deminimala kraven på fria resurser i noden för att köra en container (och podden i stort), medan limits sätter en strikt begränsning på de resurser som är tillgängliga för containern.

Det är viktigt att förstå att det i manifestet inte är nödvändigt att uttryckligen definiera båda typerna, och beteendet blir då följande:

• Om endast limits för resursen är uttryckligen angivet, så antar requests för denna resurs automatiskt värdet som är lika med limits (detta kan verifieras genom att anropa describe på enheten). Det vill säga, faktiska driften av containern kommer att begränsas till precis så mycket resurser som den kräver för att starta.
• Om endast requests för resursen är uttryckligen angivet, så sätts inga begränsningar för denna resurs — det vill säga, containern är begränsad enbart av nodens resurser.

Det finns också möjlighet att justera resurshanteringen inte bara på nivån för enskild container, utan även på nivå av namespace genom hjälp av följande enheter:

• LimitRange — beskriver begränsningspolitiken på nivån för containern/podden inom ns och behövs för att beskriva standardbegränsningar för en container/podd, samt förhindra skapandet av överdrivet stora containrar/poddar (eller tvärtom), begränsa antalet de kan ha och definiera den möjliga skillnaden i värden mellan limits och requests.
• ResourceQuotas — beskriver restriktionspolitiken överlag för alla containrar i ns och används vanligtvis för att avgränsa resurser efter miljöer (användbart när miljöerna inte är strikt avgränsade på nodnivå)

Nedan följer exempel på manifester där resursbegränsningar sätts:

• På niveau av en specifik container:

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

  Det vill säga, i det här fallet för att starta en container med nginx behöver det finnas minst 1G RAM och 0.2 CPU på noden, och container kan maximalt använda 0.2 CPU och all tillgänglig RAM på noden.

• På niveau av hela ns:

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

  Det vill säga, summan av alla container-request i standard ns får inte överstiga 300m för CPU och 1G för RAM, och summan av alla limit får vara 700m för CPU och 2G för RAM.

• Standardbegränsningar för containrar 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

  Det vill säga, i standard-namespacet för alla containrar kommer en begäran som standard att ställas in på 100m för CPU och 1G för RAM, limit — 1 CPU och 2G. Det finns också en begränsning för möjliga värden i request/limit för CPU (50m < x < 2) och RAM (500M < x < 4G).

• Begränsningar på pod-nivå i ns:

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

  Det vill säga, för varje pod i standard-ns kommer en begränsning att sättas till 4 vCPU och 1G.

Nu skulle jag vilja berätta om vilka fördelar vi kan få av att sätta dessa begränsningar.

Lastbalanseringsmekanism mellan noder

Som bekant ansvarar en sådan komponent i k8s som scheduler, som fungerar enligt en specifik algoritm. Denna algoritm går igenom två steg för att välja den optimala noden för uppstart:

1. Filtrering
2. Rankning

Det vill säga, enligt den beskrivna policyn väljs ursprungligen de noder där det är möjligt att starta en pod baserat på en uppsättning predicates (däribland kontrollen om noden har tillräckligt med resurser för att starta podden — PodFitsResources), och sedan för var och en av dessa noder, enligt priorities poäng tilldelas (inklusive ju fler fria resurser noden har — desto fler poäng ges — LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) och startas på noden med flest poäng (om flera noder uppfyller detta villkor väljs en slumpmässigt).

Det är viktigt att förstå att schemaläggaren vid bedömning av tillgängliga resurser på noden baserar sig på data som lagras i etcd — d.v.s. summan av begärda/reserverade resurser för varje podd som körs på denna nod, men inte på den faktiska resursanvändningen. Denna information kan erhållas genom kommandot 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, samt de resurser som efterfrågas av varje podd. Så här ser loggarna från schemaläggaren ut vid start av podden cronjob-cron-events-1573793820-xt6q9 (denna information i schemaläggarens logg visas vid inställning av loggnivå 10 i kommandoradens argument —v=10):

logg

I1115 07:57:21.637791       1 scheduling_queue.go:908] Försöker att schemalägga podd nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Försöker att schemalägga podd: nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s5 är tillåten, noden kör endast 16 av 110 poddar.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s6 är tillåten, noden kör endast 20 av 110 poddar.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s3 är tillåten, noden kör endast 20 av 110 poddar.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s4 är tillåten, noden kör endast 17 av 110 poddar.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s10 är tillåten, noden kör endast 16 av 110 poddar.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s12 är tillåten, noden kör endast 9 av 110 poddar.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s11 är tillåten, noden kör endast 11 av 110 poddar.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s1 är tillåten, noden kör endast 19 av 110 poddar.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s2 är tillåten, noden kör endast 21 av 110 poddar.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s9 är tillåten, noden kör endast 16 av 110 poddar.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s8 är tillåten, noden kör endast 18 av 110 poddar.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s13 är tillåten, noden kör endast 8 av 110 poddar.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s10 är tillåten, existerande poddar anti-affinity villkor är uppfyllda.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s8 är tillåten, existerande poddar anti-affinity villkor är uppfyllda.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s9 är tillåten, existerande poddar anti-affinity villkor är uppfyllda.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Schemalägg podd nxs-stage/cronjob-cron-events-1573793820-xt6q9 på nod nxs-k8s-s7 är tillåten, noden kör endast 25 av 110 poddar.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, kapacitet 39900 millicores 66620178432 minnesbyte, totalt begäran 2343 millicores 9640186880 minnesbyte, poäng 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, kapacitet 39900 millicores 66620178432 minnesbyte, totalt begäran 2343 millicores 9640186880 minnesbyte, poäng 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, kapacitet 39900 millicores 66620170240 minnesbyte, totalt begäran 4107 millicores 11307422720 minnesbyte, poäng 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, kapacitet 39900 millicores 66620178432 minnesbyte, totalt begäran 5847 millicores 24333637120 minnesbyte, poäng 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, kapacitet 39900 millicores 66620170240 minnesbyte, totalt begäran 4107 millicores 11307422720 minnesbyte, poäng 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, kapacitet 39900 millicores 66620178432 minnesbyte, totalt begäran 5847 millicores 24333637120 minnesbyte, poäng 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Poäng: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Poäng: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Poäng: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Poäng: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Poäng: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Poäng: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Poäng: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Poäng: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Poäng: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Poäng: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Poäng: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Poäng: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Poäng: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Poäng: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Poäng: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Värd nxs-k8s-s10 => Poäng 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Värd nxs-k8s-s8 => Poäng 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Värd nxs-k8s-s9 => Poäng 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AntaPodVolymer för podd "nxs-stage/cronjob-cron-events-1573793820-xt6q9", nod "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AntaPodVolymer för podd "nxs-stage/cronjob-cron-events-1573793820-xt6q9", nod "nxs-k8s-s10": alla PVC:er är bundna och inget att göra                                                                             
I1115 07:57:21.639333       1 factory.go:733] Försöker att binda cronjob-cron-events-1573793820-xt6q9 till nxs-k8s-s10

Här ser vi att schemaläggaren från början filtrerar och skapar en lista på 3 noder där en start är möjlig (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). Det gör sedan en poängsättning baserat på flera parametrar (inklusive BalancedResourceAllocation, LeastResourceAllocation) för var och en av dessa noder för att avgöra den mest lämpliga noden. I slutändan planeras på noden med flest poäng (här har två noder samma poäng 100037, så en av dem, nxs-k8s-s10, väljs slumpmässigt).

Utdata: Om det finns pods på noden för vilka inga begränsningar är angivna, så kommer det för k8s (utifrån resursanvändning) att motsvara att dessa pods egentligen inte finns på noden. Därför, om du har en pod med en resurskrävande process (t.ex. wowza) och inga begränsningar är angivna, kan det hända att denna pod faktiskt har tagit all resurs på noden, men för k8s räknas noden som outnyttjad och får samma poäng i rangordningen (just i punkterna för tillgängliga resurser) som en nod utan arbetande pods, vilket i slutändan kan leda till en ojämn belastning mellan noderna.

Utkast av pod

Som känt tilldelas varje pod en av 3 QoS-klasser:

1. guaranuted — tilldelas då för varje container i podden för minne och cpu en begäran och begränsning är angiven, och dessa värden måste överensstämma
2. burstable — minst en container i podden har en begäran och en begränsning, där begäran < begränsning
3. best effort — när ingen container i podden är begränsad när det gäller resurser

Vid brist på resurser (disk, minne) på noden börjar kubelet rangordna och utvisa pods enligt en viss algoritm som tar hänsyn till poddens prioritet och dess QoS-klass. Till exempel, när det handlar om RAM, tilldelas poäng baserat på QoS-klassen enligt följande princip:

• Guaranteed: -998
• BestEffort: 1000
• Burstable: min(max(2, 1000 — (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

Dvs, vid samma prioritet kommer kubelet först att utvisa pods med QoS-klassen best effort från noden.

Utdata: Om du vill minska sannolikheten för att en nödvändig pod ska utvisas från noden vid brist på resurser, måste du också se till att för den ges en begäran/begränsning, på lika villkor med prioritet.

Horinzontell autoskalering av applikationspods (HPA)

När uppgiften kräver automatisk ökning och minskning av antalet pods beroende på resursanvändning (systemresurser — CPU/RAM eller användarresurser — rps) kan en sådan enhet i k8s hjälpa till HPA (Horizontal Pod Autoscaler). Algoritmen går till följande:

1. Aktuella värden av den observerade resursen (currentMetricValue) definieras
2. Önskade värden för resursen (desiredMetricValue) definieras, vilka för systemresurser sätts med hjälp av request
3. Det aktuella antalet replikat (currentReplicas) definieras
4. Det önskade antalet replikat (desiredReplicas) beräknas med följande formel
   desiredReplicas = [ currentReplicas * ( currentMetricValue / desiredMetricValue )]

Vid detta tillfälle sker ingen skala om förhållandet (currentMetricValue / desiredMetricValue) är nära 1 (vi kan själva ange det tillåtna felet, vilket som standard är 0.1).

Låt oss överväga hur hpa fungerar med exemplet på applikationen app-test (beskriven som Deployment), där antalet replikat måste ändras beroende på CPU-användning:

• Applikationsmanifest

  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

  Det vill säga, vi ser att podden med applikationen ursprungligen startas i två exemplar, där varje innehåller två containrar, nginx och nginx-exporter, för vilka en requests 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

  Det vill säga, vi har skapat en hpa som kommer att övervaka Deployment app-test och reglera antalet pods med applikationen baserat på cpu-mätningen (vi förväntar oss att podden ska konsumera 30% av det begärda CPU-n)

  Nu, låt oss överväga hur hpa fungerar om vi lägger belastning på en av pods:

   # 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:

• Önskat värde (desiredMetricValue) — enligt hpa-inställningarna är lika med 30%
• Nuvarande värde (currentMetricValue) — för att beräkna controller-manager beräknar det genomsnittliga resursanvändningen i %, dvs. gör ungefär följande:
  1. Tar absoluta värden för podmetrics från metric-servern, dvs. 101m och 4m
  2. Beräknar det genomsnittliga absoluta värdet, dvs. (101m + 4m) / 2 = 53m
  3. Tar det absoluta värdet för önskad resursanvändning (för detta summeras request för alla containrar) 60m + 30m = 90m
  4. Beräknar genomsnittlig procentandel av CPU-användningen relativt podens request, dvs. 53m / 90m * 100% = 59%

Nu har vi allt som behövs för att avgöra om antalet repliker behöver ändras, för att göra det beräknar vi förhållandet:

ratio = 59% / 30% = 1.96

Det vill säga, antalet repliker bör ökas med ~2 gånger och bli [2 * 1.96] = 4.

Slutsats: Som man kan se, för att denna mekanism ska fungera är det nödvändigt att det också finns requests för alla containrar i den observerade podden.

Mekanismen för horisontell automatisk skalning av noder (Cluster Autoscaler)

För att mildra den negativa påverkan på systemet vid belastningsspikar, är det ibland otillräckligt att ha en konfigurerad hpa. Till exempel, enligt inställningarna i hpa, beslutar controller-manager att antalet repliker måste ökas med 2 gånger, men det finns inte tillräckligt med fria resurser på noderna för att köra så många pods (dvs. noden kan inte tillhandahålla de begärda resurserna för podens requests) och dessa pods går in i tillståndet Pending.

I detta fall, om leverantören har motsvarande IaaS/PaaS (t.ex. GKE/GCE, AKS, EKS m.fl.), kan vi få hjälp av ett verktyg som Node Autoscaler. Det tillåter att ställa in ett maximalt och minimalt antal noder i klustret och automatiskt justera det aktuella antalet noder (genom att anropa API:t för molnleverantören för att beställa/ta bort en nod), när det är brist på resurser i klustret och pods inte kan schemaläggas (är i tillståndet Pending).

Slutsats: För möjligheten till automatisk skalning av noder är det nödvändigt att ange requests i containrarna i pods, så att k8s kan utvärdera noderna korrekt och därmed meddela att det inte finns några resurser i klustret för att starta en ny pod.

Slutsats

Det är värt att notera att installation av resursbegränsningar för containern inte är ett krav för att framgångsrikt starta applikationen, men det är ändå bättre att göra det av följande skäl:

1. För att den schemaläggning ska fungera mer exakt när det gäller att balansera belastningen mellan noderna i k8s
2. För att minska risken för att händelsen "podutdrivning" inträffar
3. För att arbeta med horisontell automatisk skalning av applikationens pods (HPA)
4. För att arbeta med horisontell automatisk skalning av noder (Cluster Autoscaling) hos molnleverantörer

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

• Tekton Pipeline - Kubernetes-nativa pipelines
• Bygg dynamiska moduler för Nginx
• Vad migreringen från ClickHouse utan autentisering till ClickHouse med autentisering ledde till
• Förstå paketet Context i Golang
• Tre enkla knep för att minska Docker-bilder
• Backup av ett stort antal heterogena web-projekt

Källa: habr.com