🥇Kubernetes: किन यो प्रणाली संसाधन व्यवस्थापन कन्फिगर गर्न महत्त्वपूर्ण छ?

एक नियमको रूपमा, त्यहाँ सधैं यसको सही र स्थिर सञ्चालनको लागि अनुप्रयोगलाई स्रोतहरूको समर्पित पूल प्रदान गर्न आवश्यक छ। तर के हुन्छ यदि धेरै अनुप्रयोगहरू एउटै शक्तिमा चलिरहेका छन्? तिनीहरूमध्ये प्रत्येकलाई न्यूनतम आवश्यक स्रोतहरू कसरी उपलब्ध गराउने? तपाईं कसरी स्रोत खपत सीमित गर्न सक्नुहुन्छ? नोडहरू बीचको लोडलाई कसरी सही रूपमा वितरण गर्ने? एप्लिकेसन लोड बढेमा तेर्सो स्केलिंग मेकानिजमले काम गर्छ भनेर कसरी सुनिश्चित गर्ने?

तपाईले प्रणालीमा कुन मुख्य प्रकारका स्रोतहरू अवस्थित छन् भनेर सुरू गर्न आवश्यक छ - यो, निस्सन्देह, प्रोसेसर समय र RAM हो। k8s मा यी स्रोत प्रकारहरूलाई निम्न एकाइहरूमा मापन गरिन्छ:

CPU - कोर मा
RAM - बाइट मा

यसबाहेक, प्रत्येक स्रोतको लागि दुई प्रकारका आवश्यकताहरू सेट गर्न सम्भव छ - अनुरोधहरू и सीमाहरू। अनुरोधहरू - कन्टेनर (र समग्र रूपमा पोड) चलाउनको लागि नोडको निःशुल्क स्रोतहरूको लागि न्यूनतम आवश्यकताहरू वर्णन गर्दछ, जबकि सीमाहरूले कन्टेनरमा उपलब्ध स्रोतहरूमा कडा सीमा सेट गर्दछ।

यो बुझ्न महत्त्वपूर्ण छ कि manifest ले स्पष्ट रूपमा दुबै प्रकारहरू परिभाषित गर्नुपर्दैन, तर व्यवहार निम्नानुसार हुनेछ:

यदि केवल एक स्रोतको सीमाहरू स्पष्ट रूपमा निर्दिष्ट गरिएको छ भने, त्यसपछि यस स्रोतको लागि अनुरोधहरूले स्वचालित रूपमा सीमा बराबर मान लिन्छ (तपाईले यसलाई वर्णन संस्थाहरू कल गरेर प्रमाणित गर्न सक्नुहुन्छ)। ती। वास्तवमा, कन्टेनर चलाउन आवश्यक पर्ने स्रोतहरूको समान मात्रामा सीमित हुनेछ।
यदि केवल अनुरोधहरू स्रोतको लागि स्पष्ट रूपमा निर्दिष्ट गरिएको छ भने, त्यसपछि यस स्रोतमा कुनै माथिल्लो प्रतिबन्धहरू सेट गरिएको छैन - अर्थात्। कन्टेनर केवल नोड को स्रोतहरु द्वारा सीमित छ।

स्रोत व्यवस्थापनलाई एक विशेष कन्टेनरको स्तरमा मात्र नभई निम्न निकायहरू प्रयोग गरेर नामस्थान स्तरमा पनि कन्फिगर गर्न सम्भव छ:

सीमा दायरा — ns मा कन्टेनर/पोड स्तरमा प्रतिबन्ध नीति वर्णन गर्दछ र कन्टेनर/पोडमा पूर्वनिर्धारित सीमाहरू वर्णन गर्न आवश्यक छ, साथै स्पष्ट रूपमा फ्याट कन्टेनर/पोडहरू (वा यसको विपरीत) को सिर्जना रोक्न, तिनीहरूको संख्या सीमित गर्नुहोस्। र सीमा र अनुरोधहरूमा मानहरूमा सम्भावित भिन्नता निर्धारण गर्नुहोस्
स्रोत कोटाहरू - ns मा सबै कन्टेनरहरूको लागि सामान्य रूपमा प्रतिबन्ध नीति वर्णन गर्नुहोस् र नियमको रूपमा, वातावरणहरू बीच स्रोतहरू सीमित गर्न प्रयोग गरिन्छ (नोड स्तरमा वातावरणहरू कडा रूपमा सीमाङ्कन नगरिएको अवस्थामा उपयोगी)

संसाधन सीमाहरू सेट गर्ने manifests को उदाहरणहरू निम्न छन्:

विशिष्ट कन्टेनर स्तरमा:
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
ती। यस अवस्थामा, nginx को साथ कन्टेनर चलाउन, तपाईंलाई नोडमा कम्तिमा 1G नि: शुल्क RAM र 0.2 CPU चाहिन्छ, जबकि कन्टेनरले 0.2 CPU र नोडमा उपलब्ध सबै RAM उपभोग गर्न सक्छ।
पूर्णांक स्तर ns मा:
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
ती। पूर्वनिर्धारित ns मा भएका सबै अनुरोध कन्टेनरहरूको योगफल OP को लागि CPU र 300G को लागि 1m भन्दा बढी हुन सक्दैन, र सबै सीमाको योगफल CPU को लागि 700m र OP को लागि 2G हो।
एनएसमा कन्टेनरहरूको लागि पूर्वनिर्धारित सीमाहरू:
```
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
```
ती। सबै कन्टेनरहरूको लागि पूर्वनिर्धारित नेमस्पेसमा, अनुरोधलाई CPU को लागि 100m र OP को लागि 1G, सीमा - 1 CPU र 2G मा सेट गरिनेछ। एकै समयमा, CPU (50m < x < 2) र RAM (500M < x < 4G) को लागि अनुरोध/सीमामा सम्भावित मानहरूमा पनि सीमा सेट गरिएको छ।
पोड-स्तर प्रतिबन्ध ns:
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
ती। पूर्वनिर्धारित एनएसमा प्रत्येक पोडको लागि 4 vCPU र 1G को सीमा हुनेछ।

अब म तपाईंलाई बताउन चाहन्छु कि यी प्रतिबन्धहरू सेट गर्दा हामीलाई के फाइदाहरू दिन सक्छन्।

नोडहरू बीच लोड सन्तुलन संयन्त्र

तपाईलाई थाहा छ, k8s कम्पोनेन्ट नोडहरू बीच पोडहरूको वितरणको लागि जिम्मेवार छ, जस्तै तालिकाकर्ता, जुन एक विशिष्ट एल्गोरिथ्म अनुसार काम गर्दछ। यो एल्गोरिदम सुरु गर्न इष्टतम नोड चयन गर्दा दुई चरणहरूमा जान्छ:

फिल्टरिङ
दायरा

ती। वर्णन गरिएको नीति अनुसार, नोडहरू प्रारम्भिक रूपमा चयन गरिन्छ जसमा सेटको आधारमा पोड सुरु गर्न सम्भव छ भविष्यवाणी गर्छ (पोड - 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 पोड सुरु हुँदा शेड्यूलर लगहरू कस्तो देखिन्छन् (यो जानकारी शेड्यूलर लगमा देखा पर्नेछ जब तपाईंले स्टार्टअप कमाण्ड आर्गुमेन्टहरूमा 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)।

निष्कर्षमा: यदि एउटा नोडले पोडहरू चलाउँछ जसको लागि कुनै प्रतिबन्धहरू सेट गरिएको छैन भने, k8s को लागि (स्रोत खपतको दृष्टिकोणबाट) यो यो नोडमा कुनै पनि त्यस्ता पोडहरू थिएनन् भने बराबर हुनेछ। तसर्थ, यदि तपाइँसँग, सशर्त रूपमा, पेटी प्रक्रिया भएको पोड छ (उदाहरणका लागि, wowza) र यसको लागि कुनै प्रतिबन्धहरू सेट गरिएको छैन, तब स्थिति उत्पन्न हुन सक्छ जब यो पोडले वास्तवमा नोडका सबै स्रोतहरू खायो, तर k8s को लागि यो नोड। अनलोड गरिएको मानिन्छ र यसलाई र्याङ्किङ गर्दा (उपलब्ध स्रोतहरूको मूल्याङ्कन गर्ने बिन्दुहरूमा) काम गर्ने पोडहरू नभएको नोडको रूपमा उस्तै अंकहरू दिइनेछ, जसले अन्ततः नोडहरू बीचको लोडको असमान वितरण निम्त्याउन सक्छ।

पोडको निष्कासन

तपाईलाई थाहा छ, प्रत्येक पोडलाई 3 QoS कक्षाहरू मध्ये एक तोकिएको छ:

ग्यारेन्टी गरिएको - तोकिएको छ जब पोडमा प्रत्येक कन्टेनरको लागि मेमोरी र सीपीयूको लागि अनुरोध र सीमा निर्दिष्ट गरिन्छ, र यी मानहरू मिल्नुपर्छ।
फुट्न मिल्ने - पोडमा कम्तिमा एउटा कन्टेनरमा अनुरोध र सीमा हुन्छ, अनुरोध < सीमासँग
उत्तम प्रयास - जब पोडमा एकल कन्टेनर संसाधन सीमित छैन

एकै समयमा, जब एक नोडले स्रोतहरू (डिस्क, मेमोरी) को अभाव अनुभव गर्दछ, कुबेलेटले पोड र यसको QoS वर्गको प्राथमिकतालाई ध्यानमा राखेको एक विशेष एल्गोरिथ्म अनुसार पोडहरू क्रमबद्ध गर्न र बाहिर निकाल्न थाल्छ। उदाहरणका लागि, यदि हामी RAM को बारेमा कुरा गर्दैछौं, त्यसपछि QoS वर्गको आधारमा, निम्न सिद्धान्त अनुसार अंकहरू प्रदान गरिन्छ:

ग्यारेन्टी: -998.००
उत्तम प्रयास: 1000
फुट्न मिल्ने: न्यूनतम(अधिकतम(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

ती। उही प्राथमिकताका साथ, कुबेलेटले नोडबाट सबै भन्दा राम्रो प्रयास QoS वर्गको साथ पोडहरू बाहिर निकाल्नेछ।

निष्कर्षमा: यदि तपाईं यसमा स्रोतको कमीको अवस्थामा नोडबाट इच्छित पोड हटाउने सम्भावना कम गर्न चाहनुहुन्छ भने, प्राथमिकताको साथसाथै, तपाईंले यसको लागि अनुरोध/सीमा सेट गर्ने कुरामा पनि ध्यान दिन आवश्यक छ।

एप्लिकेसन पोड (HPA) को तेर्सो अटोस्केलिंगको लागि संयन्त्र

जब कार्य स्रोतहरूको प्रयोग (प्रणाली - CPU/RAM वा प्रयोगकर्ता - rps) को आधारमा पोडहरूको संख्या स्वचालित रूपमा बढाउने र घटाउने हो, जस्तै k8s इकाई। HPA (तेर्सो पोड अटोस्केलर)। जसको एल्गोरिथ्म निम्नानुसार छ:

अवलोकन गरिएको स्रोतको हालको पठनहरू निर्धारण गरिन्छ (currentMetricValue)
स्रोतका लागि वांछित मानहरू निर्धारण गरिन्छ (desiredMetricValue), जुन प्रणाली स्रोतहरूको लागि अनुरोध प्रयोग गरेर सेट गरिन्छ।
प्रतिकृतिहरूको हालको संख्या निर्धारण गरिएको छ (वर्तमान प्रतिकृतिहरू)
निम्न सूत्रले प्रतिकृतिहरूको वांछित संख्या गणना गर्दछ (इच्छित प्रतिकृतिहरू)
वांछित प्रतिकृति = [वर्तमान प्रतिकृति * (वर्तमानमेट्रिक मान / वांछितमेट्रिक मान)]

यस अवस्थामा, गुणांक (currentMetricValue / desiredMetricValue) 1 को नजिक हुँदा मापन हुने छैन (यस अवस्थामा, हामी आफैले अनुमतियोग्य त्रुटि सेट गर्न सक्छौं; पूर्वनिर्धारित रूपमा यो 0.1 हो)।

एप-टेस्ट एप्लिकेसन (डिप्लोयमेन्टको रूपमा वर्णन गरिएको) को उदाहरण प्रयोग गरेर hpa कसरी काम गर्छ हेरौं, जहाँ 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
```
ती। हामीले एउटा एचपीए सिर्जना गर्यौं जसले डिप्लोयमेन्ट एप-टेस्टलाई निगरानी गर्नेछ र सीपीयू सूचकको आधारमा एप्लिकेसनसँग पोडहरूको संख्यालाई विनियमित गर्नेछ (हामी आशा गर्छौं कि पोडले सीपीयूको 30% प्रतिशत खपत गर्नुपर्छ), प्रतिकृतिहरूको संख्याको साथ। 2-10 को दायरामा।

अब, एचपीए अपरेशनको मेकानिजम हेरौं यदि हामीले चूल्हा मध्ये एकमा भार लागू गर्छौं:
```
 # 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. मेट्रिक सर्भरबाट पोड मेट्रिक्सको निरपेक्ष मानहरू प्राप्त गर्दछ, अर्थात् १०१ मिटर र ४ मि
2. औसत निरपेक्ष मान गणना गर्दछ, अर्थात् (101m + 4m) / 2 = 53m
3. वांछित स्रोत उपभोगको लागि निरपेक्ष मान प्राप्त गर्दछ (यसको लागि, सबै कन्टेनरहरूको अनुरोधहरू संक्षेप गरिएको छ) 60m + 30m = 90m
4. अनुरोध पोडको सापेक्ष CPU खपतको औसत प्रतिशत गणना गर्दछ, अर्थात्। 53m / 90m * 100% = 59%

अब हामीसँग प्रतिकृतिहरूको संख्या परिवर्तन गर्न आवश्यक छ कि भनेर निर्धारण गर्न आवश्यक सबै छ; यो गर्नको लागि, हामी गुणांक गणना गर्छौं:

ratio = 59% / 30% = 1.96

ती। प्रतिकृतिहरूको संख्या ~2 गुणा र रकम [2 * 1.96] = 4 मा बढाउनुपर्छ।

निष्कर्ष: तपाईले देख्न सक्नुहुने रूपमा, यो संयन्त्रले काम गर्नको लागि, एक आवश्यक अवस्था अवलोकन गरिएको पोडमा सबै कन्टेनरहरूको लागि अनुरोधहरूको उपस्थिति हो।

नोडहरूको तेर्सो अटोस्केलिंगको लागि संयन्त्र (क्लस्टर अटोस्केलर)

लोड सर्जेसको समयमा प्रणालीमा नकारात्मक प्रभावलाई बेअसर गर्न, कन्फिगर गरिएको hpa हुनु पर्याप्त छैन। उदाहरणका लागि, hpa नियन्त्रक प्रबन्धकमा सेटिङहरू अनुसार, यसले प्रतिकृतिहरूको संख्या 2 गुणाले बढाउन आवश्यक छ भनेर निर्णय गर्दछ, तर नोडहरूसँग त्यस्ता धेरै पोडहरू चलाउनको लागि नि:शुल्क स्रोतहरू छैनन् (अर्थात् नोडले प्रदान गर्न सक्दैन। रिक्वेस्ट पोडमा रिक्वेस्ट गरिएको स्रोतहरू) र यी पोडहरू पेन्डिङ स्टेटमा स्विच हुन्छन्।

यस अवस्थामा, यदि प्रदायकसँग सम्बन्धित IaaS/PaaS छ (उदाहरणका लागि, GKE/GCE, AKS, EKS, आदि), जस्तै उपकरण नोड अटोस्केलर। यसले तपाईंलाई क्लस्टरमा नोडहरूको अधिकतम र न्यूनतम संख्या सेट गर्न र क्लस्टर र पोडहरूमा स्रोतहरूको अभाव हुँदा नोडहरूको हालको संख्या (क्लाउड प्रदायक API लाई अर्डर गर्न/हटाउन कल गरेर) समायोजन गर्न अनुमति दिन्छ। अनुसूचित गर्न सकिँदैन (बाँकी अवस्थामा छन्)।

निष्कर्ष: नोडहरू अटोस्केल गर्न सक्षम हुनको लागि, पोड कन्टेनरहरूमा अनुरोधहरू सेट गर्न आवश्यक छ ताकि k8s ले नोडहरूमा लोडको सही मूल्याङ्कन गर्न सक्छ र तदनुसार अर्को पोड सुरु गर्न क्लस्टरमा कुनै स्रोतहरू छैनन् भनी रिपोर्ट गर्नुहोस्।

निष्कर्षमा

यो ध्यान दिनुपर्छ कि कन्टेनर स्रोत सीमाहरू सेटिङ अनुप्रयोग सफलतापूर्वक चलाउनको लागि आवश्यकता होइन, तर निम्न कारणहरूको लागि यो अझै राम्रो छ:

k8s नोडहरू बीच लोड सन्तुलनको सन्दर्भमा अनुसूचकको थप सटीक सञ्चालनको लागि
"पोड बेदखल" घटना हुने सम्भावना कम गर्न
काम गर्नको लागि एप्लिकेसन पोडहरू (HPA) को तेर्सो अटोस्केलिंगको लागि
क्लाउड प्रदायकहरूका लागि नोडहरू (क्लस्टर अटोस्केलिङ्) को तेर्सो अटोस्केलिंगको लागि

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

स्रोत: www.habr.com

Kubernetes: किन यो प्रणाली संसाधन व्यवस्थापन सेट अप गर्न महत्त्वपूर्ण छ?