🥇कुबेरनेट्स: सिस्टम संसाधन प्रबंधन को कॉन्फ़िगर करना इतना महत्वपूर्ण क्यों है?

एक नियम के रूप में, किसी एप्लिकेशन को उसके सही और स्थिर संचालन के लिए हमेशा संसाधनों का एक समर्पित पूल प्रदान करने की आवश्यकता होती है। लेकिन क्या होगा यदि कई एप्लिकेशन एक ही शक्ति पर चल रहे हों? उनमें से प्रत्येक को न्यूनतम आवश्यक संसाधन कैसे प्रदान करें? आप संसाधन खपत को कैसे सीमित कर सकते हैं? नोड्स के बीच लोड को सही ढंग से कैसे वितरित करें? यदि एप्लिकेशन लोड बढ़ता है तो क्षैतिज स्केलिंग तंत्र कैसे काम करता है यह सुनिश्चित करें?

आपको सिस्टम में मौजूद मुख्य प्रकार के संसाधनों से शुरुआत करने की आवश्यकता है - यह, निश्चित रूप से, प्रोसेसर का समय और रैम है। K8s मेनिफ़ेस्ट में इन संसाधन प्रकारों को निम्नलिखित इकाइयों में मापा जाता है:

सीपीयू - कोर में
रैम - बाइट्स में

इसके अलावा, प्रत्येक संसाधन के लिए दो प्रकार की आवश्यकताएँ निर्धारित करना संभव है - अनुरोधों и सीमाएं. अनुरोध - एक कंटेनर (और समग्र रूप से पॉड) को चलाने के लिए नोड के मुक्त संसाधनों के लिए न्यूनतम आवश्यकताओं का वर्णन करता है, जबकि सीमाएं कंटेनर के लिए उपलब्ध संसाधनों पर एक कठिन सीमा निर्धारित करती हैं।

यह समझना महत्वपूर्ण है कि मेनिफेस्ट में दोनों प्रकारों को स्पष्ट रूप से परिभाषित करने की आवश्यकता नहीं है, लेकिन व्यवहार इस प्रकार होगा:

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

न केवल विशिष्ट कंटेनर के स्तर पर, बल्कि निम्नलिखित संस्थाओं का उपयोग करके नेमस्पेस स्तर पर भी संसाधन प्रबंधन को कॉन्फ़िगर करना संभव है:

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

संसाधन सीमाएँ निर्धारित करने वाले मैनिफ़ेस्ट के उदाहरण निम्नलिखित हैं:

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

अब मैं आपको बताना चाहूंगा कि इन प्रतिबंधों को लगाने से हमें क्या फायदे हो सकते हैं।

नोड्स के बीच लोड संतुलन तंत्र

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

छानने
लेकर

वे। वर्णित नीति के अनुसार, प्रारंभ में नोड्स का चयन किया जाता है जिस पर सेट के आधार पर पॉड लॉन्च करना संभव है विधेय (यह जाँचने सहित कि नोड के पास पॉड को चलाने के लिए पर्याप्त संसाधन हैं - PodFitsResources), और फिर इनमें से प्रत्येक नोड के लिए, के अनुसार प्राथमिकताओं अंक प्रदान किए जाते हैं (इसमें, एक नोड के पास जितने अधिक मुक्त संसाधन होते हैं, उसे उतने ही अधिक अंक दिए जाते हैं - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) और पॉड को सबसे अधिक अंकों के साथ नोड पर लॉन्च किया जाता है (यदि कई नोड एक साथ इस शर्त को पूरा करते हैं, तो) एक यादृच्छिक चयन किया जाता है)।

उसी समय, आपको यह समझने की आवश्यकता है कि शेड्यूलर, किसी नोड के उपलब्ध संसाधनों का आकलन करते समय, उस डेटा द्वारा निर्देशित होता है जो आदि में संग्रहीत होता है - यानी। इस नोड पर चल रहे प्रत्येक पॉड के अनुरोधित/सीमा संसाधन की मात्रा के लिए, लेकिन वास्तविक संसाधन खपत के लिए नहीं। यह जानकारी कमांड आउटपुट से प्राप्त की जा सकती है 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 पॉड लॉन्च किया जाता है तो शेड्यूलर लॉग कैसा दिखता है (यह जानकारी शेड्यूलर लॉग में तब दिखाई देगी जब आप स्टार्टअप कमांड तर्क -v=10 में 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)। फिर यह सबसे उपयुक्त नोड निर्धारित करने के लिए इनमें से प्रत्येक नोड के लिए कई मापदंडों (बैलेंस्ड रिसोर्स एलोकेशन, लीस्ट रिसोर्स एलोकेशन सहित) के आधार पर स्कोर की गणना करता है। अंततः, पॉड को सबसे अधिक अंकों वाले नोड पर शेड्यूल किया जाता है (यहां दो नोड्स में एक साथ अंकों की समान संख्या 100037 होती है, इसलिए एक यादृच्छिक चुना जाता है - nxs-k8s-s10)।

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

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

जैसा कि आप जानते हैं, प्रत्येक पॉड को 3 QoS वर्गों में से एक सौंपा गया है:

गारंटीशुदा - तब असाइन किया जाता है जब पॉड में प्रत्येक कंटेनर के लिए मेमोरी और सीपीयू के लिए एक अनुरोध और सीमा निर्दिष्ट की जाती है, और ये मान मेल खाने चाहिए
फटने योग्य - पॉड में कम से कम एक कंटेनर में एक अनुरोध और एक सीमा होती है, अनुरोध <सीमा के साथ
सबसे अच्छा प्रयास - जब पॉड में एक भी कंटेनर संसाधन सीमित न हो

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

गारंटीकृत: -998
सर्वश्रेष्ठ प्रयास: 1000
फटने योग्य: न्यूनतम(अधिकतम(2, 1000 - (1000 * मेमोरी रिक्वेस्ट बाइट्स) / मशीन मेमोरी कैपेसिटी बाइट्स), 999)

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

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

एप्लिकेशन पॉड्स की क्षैतिज ऑटोस्केलिंग के लिए तंत्र (एचपीए)

जब कार्य संसाधनों (सिस्टम - सीपीयू/रैम या उपयोगकर्ता - आरपीएस) के उपयोग के आधार पर पॉड्स की संख्या को स्वचालित रूप से बढ़ाना और घटाना है, तो ऐसी k8s इकाई एचपीए (क्षैतिज पॉड ऑटोस्केलर)। जिसका एल्गोरिदम इस प्रकार है:

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

इस मामले में, स्केलिंग तब नहीं होगी जब गुणांक (currentMetricValue / DesiredMetricValue) 1 के करीब हो (इस मामले में, हम अनुमेय त्रुटि स्वयं सेट कर सकते हैं; डिफ़ॉल्ट रूप से यह 0.1 है)।

आइए देखें कि ऐप-टेस्ट एप्लिकेशन (परिनियोजन के रूप में वर्णित) के उदाहरण का उपयोग करके एचपीए कैसे काम करता है, जहां सीपीयू खपत के आधार पर प्रतिकृतियों की संख्या को बदलना आवश्यक है:

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

अब हमारे पास वह सब कुछ है जो हमें यह निर्धारित करने के लिए चाहिए कि क्या हमें प्रतिकृतियों की संख्या बदलने की आवश्यकता है; ऐसा करने के लिए, हम गुणांक की गणना करते हैं:

ratio = 59% / 30% = 1.96

वे। प्रतिकृतियों की संख्या ~2 गुना और राशि [2 * 1.96] = 4 तक बढ़ाई जानी चाहिए।

निष्कर्ष: जैसा कि आप देख सकते हैं, इस तंत्र के काम करने के लिए, एक आवश्यक शर्त प्रेक्षित पॉड में सभी कंटेनरों के लिए अनुरोधों की उपस्थिति है।

नोड्स के क्षैतिज ऑटोस्केलिंग के लिए तंत्र (क्लस्टर ऑटोस्केलर)

लोड बढ़ने के दौरान सिस्टम पर पड़ने वाले नकारात्मक प्रभाव को बेअसर करने के लिए, कॉन्फ़िगर एचपीए होना पर्याप्त नहीं है। उदाहरण के लिए, एचपीए नियंत्रक प्रबंधक में सेटिंग्स के अनुसार, यह निर्णय लेता है कि प्रतिकृतियों की संख्या को 2 गुना बढ़ाने की आवश्यकता है, लेकिन नोड्स के पास इतनी संख्या में पॉड्स चलाने के लिए मुफ्त संसाधन नहीं हैं (यानी नोड प्रदान नहीं कर सकता है) अनुरोधित संसाधन अनुरोध पॉड में) और ये पॉड लंबित स्थिति में स्विच हो जाते हैं।

इस मामले में, यदि प्रदाता के पास संबंधित IaaS/PaaS (उदाहरण के लिए, GKE/GCE, AKS, EKS, आदि) है, तो एक उपकरण जैसे नोड ऑटोस्केलर. यह आपको क्लस्टर में अधिकतम और न्यूनतम संख्या में नोड्स सेट करने की अनुमति देता है और क्लस्टर और पॉड्स में संसाधनों की कमी होने पर नोड्स की वर्तमान संख्या को स्वचालित रूप से समायोजित करने की अनुमति देता है (नोड को ऑर्डर करने/हटाने के लिए क्लाउड प्रदाता एपीआई को कॉल करके) शेड्यूल नहीं किया जा सकता (लंबित स्थिति में हैं)।

निष्कर्ष: नोड्स को ऑटोस्केल करने में सक्षम होने के लिए, पॉड कंटेनरों में अनुरोध सेट करना आवश्यक है ताकि k8s नोड्स पर लोड का सही आकलन कर सके और तदनुसार रिपोर्ट कर सके कि अगले पॉड को लॉन्च करने के लिए क्लस्टर में कोई संसाधन नहीं हैं।

निष्कर्ष

यह ध्यान दिया जाना चाहिए कि एप्लिकेशन को सफलतापूर्वक चलाने के लिए कंटेनर संसाधन सीमा निर्धारित करना एक आवश्यकता नहीं है, लेकिन निम्नलिखित कारणों से ऐसा करना अभी भी बेहतर है:

K8s नोड्स के बीच लोड संतुलन के संदर्भ में शेड्यूलर के अधिक सटीक संचालन के लिए
"पॉड निष्कासन" घटना घटित होने की संभावना को कम करने के लिए
एप्लिकेशन पॉड्स (एचपीए) की क्षैतिज ऑटोस्केलिंग के लिए काम करना
क्लाउड प्रदाताओं के लिए नोड्स की क्षैतिज ऑटोस्केलिंग (क्लस्टर ऑटोस्केलिंग) के लिए

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

स्रोत: www.habr.com

कुबेरनेट्स: सिस्टम संसाधन प्रबंधन स्थापित करना इतना महत्वपूर्ण क्यों है?