🥇Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?

როგორც წესი, ყოველთვის არის საჭირო აპლიკაციისთვის რესურსების გამოყოფილი აუზის მიწოდება მისი სწორი და სტაბილური მუშაობისთვის. მაგრამ რა მოხდება, თუ რამდენიმე აპლიკაცია მუშაობს იმავე სიმძლავრეზე? როგორ მივაწოდოთ თითოეულ მათგანს მინიმალური საჭირო რესურსები? როგორ შეგიძლიათ შეზღუდოთ რესურსების მოხმარება? როგორ სწორად გავანაწილოთ დატვირთვა კვანძებს შორის? როგორ უზრუნველვყოთ ჰორიზონტალური სკალირების მექანიზმის მუშაობა, თუ განაცხადის დატვირთვა იზრდება?

თქვენ უნდა დაიწყოთ იმით, თუ რა ძირითადი ტიპის რესურსები არსებობს სისტემაში - ეს, რა თქმა უნდა, არის პროცესორის დრო და ოპერატიული მეხსიერება. k8s მანიფესტებში რესურსების ეს ტიპები იზომება შემდეგ ერთეულებში:

CPU - ბირთვებში
ოპერატიული მეხსიერება - ბაიტებში

უფრო მეტიც, თითოეული რესურსისთვის შესაძლებელია დაწესდეს ორი სახის მოთხოვნა - მოითხოვს и ლიმიტები. მოთხოვნები - აღწერს მინიმალურ მოთხოვნებს კვანძის თავისუფალი რესურსების მიმართ კონტეინერის (და მთლიანად pod) გასაშვებად, ხოლო ლიმიტები ადგენს მკაცრ ლიმიტს კონტეინერის ხელმისაწვდომ რესურსებზე.

მნიშვნელოვანია გვესმოდეს, რომ მანიფესტმა არ უნდა განსაზღვროს ორივე ტიპი, მაგრამ ქცევა იქნება შემდეგი:

თუ ცალსახად არის მითითებული მხოლოდ რესურსის ლიმიტები, მაშინ ამ რესურსის მოთხოვნა ავტომატურად იღებს ლიმიტების ტოლ მნიშვნელობას (შეგიძლიათ გადაამოწმოთ აღწერის ერთეულების გამოძახებით). იმათ. ფაქტობრივად, კონტეინერი შემოიფარგლება იმავე რაოდენობის რესურსებით, რაც მას სჭირდება.
თუ რესურსზე ცალსახად არის მითითებული მხოლოდ მოთხოვნები, მაშინ ამ რესურსზე ზედა შეზღუდვები არ არის დაწესებული - ე.ი. კონტეინერი შემოიფარგლება მხოლოდ თავად კვანძის რესურსებით.

ასევე შესაძლებელია რესურსების მართვის კონფიგურაცია არა მხოლოდ კონკრეტული კონტეინერის დონეზე, არამედ სახელთა სივრცის დონეზე შემდეგი ერთეულების გამოყენებით:

ლიმიტის დიაპაზონი — აღწერს შეზღუდვის პოლიტიკას კონტეინერის/პოდის დონეზე ns-ში და საჭიროა კონტეინერზე/პოდზე ნაგულისხმევი შეზღუდვების აღსაწერად, ასევე აშკარად ცხიმოვანი კონტეინერების/პოდების შექმნის თავიდან ასაცილებლად (ან პირიქით), მათი რაოდენობის შეზღუდვისთვის. და განსაზღვრეთ შესაძლო განსხვავება მნიშვნელობებში ლიმიტებსა და მოთხოვნებში
რესურსის კვოტები — აღწერეთ შეზღუდვის პოლიტიკა ზოგადად ყველა კონტეინერისთვის ns-ში და გამოიყენება, როგორც წესი, რესურსების საზღვრებისთვის გარემოში (სასარგებლოა, როდესაც გარემო არ არის მკაცრად გამოყოფილი კვანძის დონეზე)

ქვემოთ მოცემულია მანიფესტების მაგალითები, რომლებიც ადგენენ რესურსების ლიმიტებს:

კონკრეტული კონტეინერის დონეზე:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
იმათ. ამ შემთხვევაში, nginx-ით კონტეინერის გასაშვებად, დაგჭირდებათ მინიმუმ 1 გ თავისუფალი ოპერატიული მეხსიერება და 0.2 CPU კვანძზე, ხოლო მაქსიმუმ კონტეინერს შეუძლია მოიხმაროს 0.2 CPU და ყველა ხელმისაწვდომი ოპერატიული მეხსიერება კვანძზე.
მთელ დონეზე ns:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
იმათ. ყველა მოთხოვნის კონტეინერების ჯამი ნაგულისხმევ ns-ში არ უნდა აღემატებოდეს 300 მ-ს CPU-სთვის და 1G-ს OP-ისთვის და ყველა ლიმიტის ჯამი არის 700m CPU-სთვის და 2G OP-ისთვის.
ნაგულისხმევი ლიმიტები კონტეინერებისთვის 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
```
იმათ. ყველა კონტეინერის ნაგულისხმევ სახელთა სივრცეში მოთხოვნა დაყენდება 100 მ CPU-სთვის და 1G OP-ისთვის, ლიმიტი - 1 CPU და 2G. ამავდროულად, ასევე დაწესებულია ლიმიტი მოთხოვნის/ლიმიტის შესაძლო მნიშვნელობებზე CPU (50m < x <2) და ოპერატიული მეხსიერება (500M < x < 4G).
პოდ დონის შეზღუდვები ns:
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
იმათ. ნაგულისხმევი ns-ის თითოეული პოდისთვის იქნება ლიმიტი 4 vCPU და 1G.

ახლა მინდა გითხრათ, რა უპირატესობები შეიძლება მოგვცეს ამ შეზღუდვების დაწესებამ.

კვანძებს შორის დატვირთვის დაბალანსების მექანიზმი

მოგეხსენებათ, k8s კომპონენტი პასუხისმგებელია კვანძების განაწილებაზე კვანძებს შორის, მაგ scheduler, რომელიც მუშაობს კონკრეტული ალგორითმის მიხედვით. ეს ალგორითმი გადის ორ ეტაპს გასაშვებად ოპტიმალური კვანძის არჩევისას:

ფილტრაცია
რანჟირება

იმათ. აღწერილი პოლიტიკის მიხედვით, თავდაპირველად შეირჩევა კვანძები, რომლებზეც შესაძლებელია ნაკრების საფუძველზე გაშვება პრედიკატები (მათ შორის, შემოწმებას, აქვს თუ არა კვანძს საკმარისი რესურსი პოდის გასაშვებად - PodFitsResources), და შემდეგ თითოეული ამ კვანძისთვის, შესაბამისად პრიორიტეტები ქულები ენიჭება (მათ შორის, რაც უფრო მეტი თავისუფალი რესურსი აქვს კვანძს, მით მეტი ქულა ენიჭება მას - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) და პოდი გაშვებულია ყველაზე მეტი ქულის მქონე კვანძზე (თუ რამდენიმე კვანძი ერთდროულად აკმაყოფილებს ამ პირობას, მაშინ შერჩეულია შემთხვევითი).

ამავდროულად, თქვენ უნდა გესმოდეთ, რომ დამგეგმავი, კვანძის ხელმისაწვდომი რესურსების შეფასებისას, ხელმძღვანელობს მონაცემებით, რომლებიც ინახება etcd-ში - ე.ი. ამ კვანძზე გაშვებული თითოეული პოდის მოთხოვნილი/ლიმიტური რესურსის ოდენობისთვის, მაგრამ არა რესურსის ფაქტობრივი მოხმარებისთვის. ამ ინფორმაციის მიღება შესაძლებელია ბრძანების გამოსვლიდან kubectl describe node $NODE, მაგალითად:

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

აქ ჩვენ ვხედავთ ყველა პოდს, რომელიც მუშაობს კონკრეტულ კვანძზე, ისევე როგორც რესურსებს, რომლებსაც თითოეული პოდი ითხოვს. და აი, როგორ გამოიყურება დამგეგმავი ჟურნალები, როდესაც cronjob-cron-events-1573793820-xt6q9 pod გაშვებულია (ეს ინფორმაცია გამოჩნდება განრიგის ჟურნალში, როდესაც დააყენებთ მე-10 შესვლის დონეს გაშვების ბრძანების არგუმენტებში -v=10):

ჟურნალი

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

აქ ჩვენ ვხედავთ, რომ თავდაპირველად დაგეგმავი ფილტრავს და აგენერირებს 3 კვანძის სიას, რომლებზეც შეიძლება მისი გაშვება (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10). შემდეგ ის ითვლის ქულებს რამდენიმე პარამეტრზე (მათ შორის BalancedResourceAllocation, LeastResourceAllocation) თითოეული ამ კვანძისთვის, რათა დადგინდეს ყველაზე შესაფერისი კვანძი. საბოლოო ჯამში, პოდი დაგეგმილია ყველაზე მეტი ქულების მქონე კვანძზე (აქ ერთდროულად ორ კვანძს აქვს 100037 ქულების იგივე რაოდენობა, ასე რომ, შემთხვევითი არჩეულია - nxs-k8s-s10).

გამოყვანის: თუ კვანძი აწარმოებს პოდებს, რომლებისთვისაც არ არის დაწესებული შეზღუდვები, მაშინ k8-ებისთვის (რესურსების მოხმარების თვალსაზრისით) ეს იქნება ექვივალენტური, თითქოს ამ კვანძზე საერთოდ არ არსებობდეს ასეთი კვანძები. მაშასადამე, თუ თქვენ, პირობითად, გაქვთ გლუტუნური პროცესის მქონე პოდი (მაგალითად, wowza) და მისთვის არანაირი შეზღუდვა არ არის დაწესებული, მაშინ შეიძლება შეიქმნას სიტუაცია, როდესაც ამ პოდმა რეალურად შეჭამა კვანძის ყველა რესურსი, მაგრამ k8-ებისთვის ეს კვანძი განიხილება დატვირთული და მას მიენიჭება იგივე რაოდენობის ქულები რანჟირებისას (ზუსტად არსებული რესურსების შეფასებისას), როგორც კვანძს, რომელსაც არ აქვს სამუშაო კვანძები, რამაც საბოლოოდ შეიძლება გამოიწვიოს დატვირთვის არათანაბარი განაწილება კვანძებს შორის.

პოდის გამოსახლება

როგორც მოგეხსენებათ, თითოეულ პოდს ენიჭება 3 QoS კლასიდან ერთ-ერთი:

გარანტირებული - ენიჭება, როდესაც პოდში თითოეული კონტეინერისთვის მითითებულია მოთხოვნა და ლიმიტი მეხსიერებისა და პროცესორისთვის, და ეს მნიშვნელობები უნდა ემთხვეოდეს
აფეთქებადი — პოდში მინიმუმ ერთ კონტეინერს აქვს მოთხოვნა და ლიმიტი, მოთხოვნით < ლიმიტი
საუკეთესო ძალისხმევა - როდესაც ჭურჭელში არც ერთი კონტეინერი არ არის შეზღუდული რესურსით

ამავდროულად, როდესაც კვანძი განიცდის რესურსების ნაკლებობას (დისკი, მეხსიერება), kubelet იწყებს პოდების რანჟირებას და გამოდევნას კონკრეტული ალგორითმის მიხედვით, რომელიც ითვალისწინებს პოდის პრიორიტეტს და მის QoS კლასს. მაგალითად, თუ ვსაუბრობთ RAM-ზე, მაშინ QoS კლასიდან გამომდინარე, ქულები ენიჭება შემდეგი პრინციპის მიხედვით:

გარანტირებული: -998
Საუკეთესო ძალა: 1000
ადიდებული: min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

იმათ. იგივე პრიორიტეტით, კუბელეტი პირველ რიგში გამოასახლებს პოდებს საუკეთესო ძალისხმევით QoS კლასის კვანძიდან.

გამოყვანის: თუ გსურთ შეამციროთ სასურველი პოდის კვანძიდან გამოდევნის ალბათობა მასზე რესურსების ნაკლებობის შემთხვევაში, მაშინ პრიორიტეტთან ერთად უნდა იზრუნოთ მასზე მოთხოვნის/ლიმიტის დაყენებაზეც.

აპლიკაციის პოდების ჰორიზონტალური ავტოსკალირების მექანიზმი (HPA)

როდესაც ამოცანაა პოდების რაოდენობის ავტომატურად გაზრდა და შემცირება რესურსების გამოყენების მიხედვით (სისტემა - CPU/RAM ან მომხმარებელი - rps), k8s ერთეული, როგორიცაა HPA (Horizontal Pod Autoscaler). რომლის ალგორითმი შემდეგია:

დაკვირვებული რესურსის მიმდინარე წაკითხვები განისაზღვრება (currentMetricValue)
განსაზღვრულია რესურსისთვის სასურველი მნიშვნელობები (desiredMetricValue), რომლებიც სისტემის რესურსებისთვის დაყენებულია მოთხოვნის გამოყენებით
რეპლიკების მიმდინარე რაოდენობა განისაზღვრება (currentReplicas)
შემდეგი ფორმულა ითვლის რეპლიკების სასურველ რაოდენობას (სასურველი რეპლიკა)
სასურველირეპლიკა = [მიმდინარე რეპლიკა * (მიმდინარემეტრიკული მნიშვნელობა / სასურველი მეტრული მნიშვნელობა)]

ამ შემთხვევაში სკალირება არ მოხდება, როცა კოეფიციენტი (currentMetricValue / სასურველიMetricValue) 1-ს მიუახლოვდება (ამ შემთხვევაში დასაშვები შეცდომა ჩვენ თვითონ შეგვიძლია დავაყენოთ; ნაგულისხმევად არის 0.1).

მოდით შევხედოთ, თუ როგორ მუშაობს hpa აპლიკაციის ტესტის აპლიკაციის მაგალითის გამოყენებით (აღწერილია როგორც Deployment), სადაც აუცილებელია რეპლიკების რაოდენობის შეცვლა CPU მოხმარების მიხედვით:

განაცხადის მანიფესტი
```
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
```
იმათ. ჩვენ ვხედავთ, რომ განაცხადის პოდი თავდაპირველად გაშვებულია ორ შემთხვევაში, რომელთაგან თითოეული შეიცავს ორ nginx და nginx-ექსპორტიორის კონტეინერებს, რომელთაგან თითოეულისთვის მითითებულია მოითხოვს CPU-სთვის.
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: 30
```
იმათ. ჩვენ შევქმენით hpa, რომელიც მონიტორინგს გაუწევს განლაგების აპლიკაციის ტესტს და დაარეგულირებს პოდების რაოდენობას აპლიკაციასთან ერთად, Cpu ინდიკატორის საფუძველზე (მოველით, რომ პოდი უნდა მოიხმაროს მის მიერ მოთხოვნილი CPU-ის 30%-ს), ასლების რაოდენობასთან ერთად. დიაპაზონი 2-10.

ახლა გადავხედოთ hpa მოქმედების მექანიზმს, თუ ერთ-ერთ კერაზე დატვირთვას მივმართავთ:
```
 # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi
```

საერთო ჯამში გვაქვს შემდეგი:

სასურველი მნიშვნელობა (desiredMetricValue) - hpa პარამეტრების მიხედვით გვაქვს 30%
მიმდინარე მნიშვნელობა (currentMetricValue) - გამოთვლებისთვის კონტროლერ-მენეჯერი ითვლის რესურსების მოხმარების საშუალო მნიშვნელობას %-ში, ე.ი. პირობითად აკეთებს შემდეგს:
1. იღებს pod მეტრიკის აბსოლუტურ მნიშვნელობებს მეტრული სერვერიდან, ე.ი. 101მ და 4მ
2. ითვლის საშუალო აბსოლუტურ მნიშვნელობას, ე.ი. (101 მ + 4 მ) / 2 = 53 მ
3. იღებს აბსოლუტურ მნიშვნელობას სასურველი რესურსის მოხმარებისთვის (ამისთვის შეჯამებულია ყველა კონტეინერის მოთხოვნა) 60 მ + 30 მ = 90 მ
4. ითვლის CPU მოხმარების საშუალო პროცენტს მოთხოვნის პოდთან მიმართებაში, ე.ი. 53 მ / 90 მ * 100% = 59%

ახლა ჩვენ გვაქვს ყველაფერი, რაც გვჭირდება იმის დასადგენად, გვჭირდება თუ არა ასლების რაოდენობის შეცვლა; ამისათვის ჩვენ გამოვთვალოთ კოეფიციენტი:

ratio = 59% / 30% = 1.96

იმათ. რეპლიკების რაოდენობა უნდა გაიზარდოს ~ 2-ჯერ და შეადგინოს [2 * 1.96] = 4.

დასკვნა: როგორც ხედავთ, იმისთვის, რომ ამ მექანიზმმა იმუშაოს, აუცილებელი პირობაა ყველა კონტეინერისთვის მოთხოვნის არსებობა დაკვირვებულ პოდში.

კვანძების ჰორიზონტალური ავტოსკალირების მექანიზმი (Cluster Autoscaler)

დატვირთვის აწევის დროს სისტემაზე უარყოფითი ზემოქმედების განეიტრალების მიზნით, კონფიგურირებული hpa არ არის საკმარისი. მაგალითად, hpa კონტროლერის მენეჯერის პარამეტრების მიხედვით, ის წყვეტს, რომ რეპლიკების რაოდენობა უნდა გაიზარდოს 2-ჯერ, მაგრამ კვანძებს არ აქვთ თავისუფალი რესურსები ამ რაოდენობის პოდების გასაშვებად (ანუ კვანძი ვერ უზრუნველყოფს მოთხოვნილი რესურსები მოთხოვნის პოდში) და ეს პოდი გადადის მომლოდინე მდგომარეობაში.

ამ შემთხვევაში, თუ პროვაიდერს აქვს შესაბამისი IaaS/PaaS (მაგალითად, GKE/GCE, AKS, EKS და ა.შ.), ინსტრუმენტი, როგორიცაა კვანძის ავტოსკალერი. ის საშუალებას გაძლევთ დააყენოთ კლასტერში კვანძების მაქსიმალური და მინიმალური რაოდენობა და ავტომატურად დაარეგულიროთ კვანძების ამჟამინდელი რაოდენობა (ღრუბლოვანი პროვაიდერის API-ის გამოძახებით კვანძის შეკვეთის/წაშლის მიზნით), როდესაც კლასტერსა და პოდებში რესურსების ნაკლებობაა. ვერ დაიგეგმება (მოლოდინშია).

დასკვნა: იმისათვის, რომ შეძლოთ კვანძების ავტომატური მასშტაბირება, აუცილებელია მოთხოვნის დაყენება პოდ კონტეინერებში, რათა k8-ებმა სწორად შეაფასონ დატვირთვა კვანძებზე და შესაბამისად შეატყობინონ, რომ კლასტერში არ არის რესურსები შემდეგი პოდის გასაშვებად.

დასკვნა

უნდა აღინიშნოს, რომ კონტეინერის რესურსის ლიმიტების დაყენება არ არის მოთხოვნა განაცხადის წარმატებით გასაშვებად, მაგრამ მაინც უკეთესია ამის გაკეთება შემდეგი მიზეზების გამო:

გრაფიკის უფრო ზუსტი მუშაობისთვის k8s კვანძებს შორის დატვირთვის დაბალანსების თვალსაზრისით
შემცირდეს „პოდის გამოსახლების“ მოვლენის ალბათობა
აპლიკაციის პოდების (HPA) ჰორიზონტალური ავტომატური სკალირების მუშაობისთვის
ღრუბლოვანი პროვაიდერებისთვის კვანძების ჰორიზონტალური ავტოსკალინგისთვის (Cluster Autoscaling).

ასევე წაიკითხეთ სხვა სტატიები ჩვენს ბლოგზე:

წყარო: www.habr.com

Kubernetes: რატომ არის ასე მნიშვნელოვანი სისტემის რესურსების მართვის კონფიგურაცია?