🥇कुबर्नेट्स कार्यप्रदर्शन सुधारण्यासाठी नऊ टिपा

सर्वांना नमस्कार! माझे नाव ओलेग सिदोरेन्कोव्ह आहे, मी डोमक्लिक येथे इन्फ्रास्ट्रक्चर टीम लीडर म्हणून काम करतो. आम्ही तीन वर्षांहून अधिक काळ विक्रीसाठी क्यूब वापरत आहोत आणि या काळात आम्ही त्याच्यासोबत अनेक मनोरंजक क्षण अनुभवले आहेत. आज मी तुम्हाला सांगेन की, योग्य पध्दतीने, तुम्ही तुमच्या क्लस्टरसाठी व्हॅनिला कुबर्नेट्समधून आणखी परफॉर्मन्स कसे पिळून काढू शकता. एक दोन साडे माडे तीन!

तुम्हा सर्वांना हे चांगलंच माहीत आहे की कुबर्नेट्स ही कंटेनर ऑर्केस्ट्रेशनसाठी स्केलेबल ओपन सोर्स सिस्टीम आहे; तसेच, किंवा 5 बायनरीज जे सर्व्हर वातावरणात तुमच्या मायक्रोसर्व्हिसेसचे जीवन चक्र व्यवस्थापित करून जादू करतात. या व्यतिरिक्त, हे बर्‍यापैकी लवचिक साधन आहे जे विविध कार्यांसाठी जास्तीत जास्त सानुकूलित करण्यासाठी लेगो कन्स्ट्रक्टरसारखे एकत्र केले जाऊ शकते.

आणि सर्व काही ठीक आहे असे दिसते: सर्व्हरला क्लस्टरमध्ये टाका, जसे फायरबॉक्समध्ये सरपण, आणि दु: ख माहित नाही. परंतु जर आपण पर्यावरणासाठी असाल तर आपण विचार कराल: "मी स्टोव्हमध्ये आग कशी ठेवू आणि जंगलाबद्दल खेद कसा करू?". दुसऱ्या शब्दांत, पायाभूत सुविधा सुधारण्याचे आणि खर्च कमी करण्याचे मार्ग कसे शोधायचे.

1. कार्यसंघ आणि अनुप्रयोग संसाधनांचा मागोवा ठेवा

सर्वात सामान्य परंतु प्रभावी पद्धतींपैकी एक म्हणजे विनंत्या/मर्यादा सादर करणे. डेव्हलपमेंट टीम्सद्वारे नेमस्पेसेस आणि नेमस्पेसेसद्वारे वेगळे ऍप्लिकेशन्स. प्रोसेसर वेळ, मेमरी, क्षणिक स्टोरेजच्या वापरासाठी मूल्ये उपयोजित करण्यापूर्वी अनुप्रयोग सेट करा.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

अनुभवानुसार, आम्ही निष्कर्षापर्यंत पोहोचलो: मर्यादेच्या विनंत्या दोनपेक्षा जास्त वेळा वाढवणे फायदेशीर नाही. क्लस्टरच्या आकाराची गणना विनंत्यांवर आधारित केली जाते आणि जर तुम्ही अॅप्लिकेशनला संसाधनांमधील फरकावर सेट केले असेल, उदाहरणार्थ, 5-10 वेळा, तर कल्पना करा की जेव्हा तुमच्या नोडमध्ये शेंगा भरल्या जातात आणि अचानक लोड येतो तेव्हा त्याचे काय होईल. काहीही चांगले नाही. कमीतकमी, थ्रॉटलिंग आणि जास्तीत जास्त, कामगाराला निरोप द्या आणि शेंगा हलू लागल्यानंतर उर्वरित नोड्सवर चक्रीय भार मिळवा.

याव्यतिरिक्त, मदतीने limitranges आपण सुरुवातीला कंटेनरसाठी संसाधन मूल्ये सेट करू शकता - किमान, कमाल आणि डीफॉल्ट:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

नेमस्पेस संसाधने मर्यादित करण्याचे लक्षात ठेवा जेणेकरून एक कमांड क्लस्टरची सर्व संसाधने घेऊ शकत नाही:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

जसे आपण वर्णनावरून पाहू शकता resourcequotas, जर ops कमांडला पॉड्स तैनात करायचे असतील जे आणखी 10 cpu वापरतील, तर शेड्युलर ते करण्याची परवानगी देणार नाही आणि त्रुटी जारी करेल:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

तत्सम समस्येचे निराकरण करण्यासाठी, आपण एक साधन लिहू शकता, उदाहरणार्थ, म्हणून हे, जे कमांड संसाधनांची स्थिती संचयित आणि वचनबद्ध करू शकते.

2. सर्वोत्तम फाइल स्टोरेज निवडा

येथे मला पर्सिस्टंट व्हॉल्यूम्स आणि कुबर्नेट्स वर्कर नोड्सच्या डिस्क सबसिस्टमच्या विषयावर स्पर्श करायचा आहे. मला आशा आहे की उत्पादनात कोणीही एचडीडीवर "क्यूब" वापरत नाही, परंतु कधीकधी नियमित एसएसडी देखील पुरेसे नसते. आम्हाला अशा समस्येचा सामना करावा लागला की लॉग I/O ऑपरेशन्सद्वारे डिस्क नष्ट करत आहेत आणि येथे बरेच उपाय नाहीत:

उच्च-कार्यक्षमता SSDs वापरा किंवा NVMe वर स्विच करा (जर तुम्ही तुमचे स्वतःचे हार्डवेअर व्यवस्थापित करा).
लॉगिंगची पातळी कमी करा.
डिस्कवर बलात्कार करणाऱ्या पॉड्सचे "स्मार्ट" बॅलन्सिंग करा (podAntiAffinity).

जेव्हा access_logs सक्षम केले जाते (~12k logs/sec) तेव्हा डिस्कसह nginx-ingress-controller अंतर्गत काय होते हे वरील स्क्रीनशॉट दाखवते. अशा अवस्थेमुळे, अर्थातच, या नोडवरील सर्व ऍप्लिकेशन्सचे ऱ्हास होऊ शकते.

पीव्हीसाठी, अरेरे, मी सर्वकाही प्रयत्न केले नाही. प्रकार सतत खंड. आपल्यास अनुकूल असलेला सर्वोत्तम पर्याय वापरा. आपल्या देशात हे ऐतिहासिकदृष्ट्या घडले आहे की सेवांच्या एका छोट्या भागाला RWX व्हॉल्यूमची आवश्यकता आहे आणि बर्याच काळापूर्वी त्यांनी या कार्यासाठी NFS स्टोरेज वापरण्यास सुरुवात केली. स्वस्त आणि ... पुरेशी. नक्कीच, आम्ही त्याच्याबरोबर घाण खाल्ले - निरोगी रहा, परंतु आम्ही त्याला कसे ट्यून करावे हे शिकलो आणि त्याचे डोके यापुढे दुखत नाही. आणि शक्य असल्यास, S3 ऑब्जेक्ट स्टोरेजवर स्विच करा.

3. ऑप्टिमाइझ केलेल्या प्रतिमा तयार करा

कंटेनर-ऑप्टिमाइझ केलेल्या प्रतिमा वापरणे सर्वोत्तम आहे जेणेकरुन Kubernetes त्या जलद आणू शकतील आणि त्या अधिक कार्यक्षमतेने कार्यान्वित करू शकतील.

ऑप्टिमायझेशन म्हणजे प्रतिमा:

फक्त एक अनुप्रयोग समाविष्ट करा किंवा फक्त एक कार्य करा;
लहान आकार, कारण मोठ्या प्रतिमा नेटवर्कवर वाईट प्रसारित केल्या जातात;
कुबर्नेट्स डाउनटाइमच्या प्रसंगी कारवाई करण्यासाठी वापरू शकतील असे आरोग्य आणि तत्परतेचे अंतिम बिंदू आहेत;
कॉन्फिगरेशन त्रुटींना अधिक प्रतिरोधक असलेल्या कंटेनर-फ्रेंडली ऑपरेटिंग सिस्टम (जसे की अल्पाइन किंवा CoreOS) वापरा;
मल्टी-स्टेज बिल्ड्स वापरा जेणेकरून तुम्ही फक्त संकलित अनुप्रयोग तैनात करू शकता आणि सोबतचे स्त्रोत नाही.

अशी अनेक साधने आणि सेवा आहेत जी तुम्हाला फ्लायवर प्रतिमा तपासण्याची आणि ऑप्टिमाइझ करण्याची परवानगी देतात. त्यांना नेहमी अद्ययावत आणि सुरक्षित ठेवणे महत्त्वाचे आहे. परिणामी, तुम्हाला मिळेल:

संपूर्ण क्लस्टरवरील नेटवर्क लोड कमी केले.
कंटेनर स्टार्टअपची वेळ कमी झाली.
तुमच्या संपूर्ण डॉकर रेजिस्ट्रीचा लहान आकार.

4. DNS कॅशे वापरा

जर आपण उच्च भारांबद्दल बोललो, तर क्लस्टरची DNS प्रणाली ट्यून केल्याशिवाय, जीवन खूपच खराब आहे. एके काळी, कुबर्नेट्स डेव्हलपर्सनी त्यांच्या kube-dns सोल्यूशनला समर्थन दिले. हे आपल्या देशात देखील लागू केले गेले, परंतु या सॉफ्टवेअरने विशेषतः ट्यून केले नाही आणि आवश्यक कार्यप्रदर्शन दिले नाही, जरी असे दिसते की कार्य सोपे आहे. नंतर कॉर्डन्स दिसू लागले, ज्यावर आम्ही स्विच केले आणि दुःख माहित नव्हते, नंतर ती K8s मध्ये डीफॉल्ट डीएनएस सेवा बनली. काही क्षणी, आम्ही DNS सिस्टममध्ये 40 हजार आरपीएस पर्यंत वाढलो आणि हे समाधान देखील पुरेसे नव्हते. पण, एका भाग्यवान संधीने, Nodelocaldns बाहेर आले, उर्फ नोड लोकल कॅशे, उर्फ नोडलोकल DNSCache.

आम्ही ते का वापरत आहोत? लिनक्स कर्नलमध्ये एक बग आहे की, UDP वर कॉन्ट्रॅक NAT द्वारे एकाधिक प्रवेश केल्यावर, कॉन्ट्रॅक टेबलवर लिहिण्यासाठी शर्यतीची स्थिती निर्माण होते आणि NAT द्वारे रहदारीचा काही भाग गमावला जातो (सेवेद्वारे प्रत्येक ट्रिप NAT आहे). Nodelocaldns NAT मधून सुटका करून आणि TCP कनेक्टिव्हिटी अपस्ट्रीम DNS वर अपग्रेड करून, तसेच अपस्ट्रीम DNS क्वेरी स्थानिक पातळीवर कॅश करून (लहान 5 सेकंदाच्या नकारात्मक कॅशेसह) ही समस्या सोडवते.

5. शेंगा क्षैतिज आणि अनुलंब आपोआप स्केल करा

तुमच्या सर्व मायक्रोसर्व्हिसेस लोडमध्ये दोन-तीन पट वाढ होण्यास तयार आहेत असे तुम्ही आत्मविश्वासाने म्हणू शकता का? आपल्या ऍप्लिकेशन्ससाठी संसाधनांचे योग्यरित्या वाटप कसे करावे? कामाच्या ओझ्यापेक्षा काही पॉड्स चालू ठेवणे अनावश्यक असू शकते आणि त्यांना परत ठेवल्याने सेवेकडे अचानक वाढलेल्या रहदारीपासून डाउनटाइमचा धोका असतो. गोल्डन मीन गुणाकाराचे शब्दलेखन साध्य करण्यात मदत करते जसे की सेवा क्षैतिज पॉड ऑटोस्केलर и अनुलंब पॉड ऑटोस्केलर.

VPA वास्तविक वापरावर आधारित पॉडमध्ये तुम्हाला तुमच्या कंटेनरच्या विनंत्या/मर्यादा स्वयंचलितपणे वाढवण्याची परवानगी देते. त्याचा उपयोग कसा होऊ शकतो? जर तुमच्याकडे पॉड्स असतील जे काही कारणास्तव क्षैतिजरित्या मोजले जाऊ शकत नाहीत (जे पूर्णपणे विश्वासार्ह नाही), तर तुम्ही त्याचे संसाधने बदलण्यासाठी VPA वर विश्वास ठेवण्याचा प्रयत्न करू शकता. त्याचे वैशिष्ट्य मेट्रिक-सर्व्हरवरील ऐतिहासिक आणि वर्तमान डेटावर आधारित एक शिफारस प्रणाली आहे, म्हणून जर तुम्हाला विनंत्या/मर्यादा आपोआप बदलायची नसेल, तर तुम्ही तुमच्या कंटेनरसाठी शिफारस केलेल्या संसाधनांचे निरीक्षण करू शकता आणि CPU आणि मेमरी जतन करण्यासाठी सेटिंग्ज ऑप्टिमाइझ करू शकता. क्लस्टर मध्ये.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 वरून घेतलेली प्रतिमा

Kubernetes मधील शेड्युलर नेहमी विनंत्यांवर आधारित असतो. तुम्ही तेथे कोणतेही मूल्य ठेवले तरी शेड्युलर त्यावर आधारित योग्य नोड शोधेल. पॉड कधी थ्रॉटल करायचा किंवा मारायचा हे जाणून घेण्यासाठी कुबलेटला मर्यादा मूल्य आवश्यक आहे. आणि विनंत्या मूल्य हे एकमेव महत्त्वाचे पॅरामीटर असल्याने, VPA त्याच्यासह कार्य करेल. जेव्हा तुम्ही तुमचा अर्ज अनुलंब स्केल करता, तेव्हा तुम्ही विनंत्या कोणत्या असाव्यात ते परिभाषित करता. आणि मग मर्यादांचे काय होईल? हे पॅरामीटर देखील प्रमाणानुसार मोजले जाईल.

उदाहरणार्थ, येथे ठराविक पॉड सेटिंग्ज आहेत:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

शिफारशी इंजिन हे निर्धारित करते की तुमचा अनुप्रयोग योग्यरित्या चालण्यासाठी 300m CPU आणि 500Mi आवश्यक आहे. तुम्हाला या सेटिंग्ज मिळतील:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

वर नमूद केल्याप्रमाणे, हे मॅनिफेस्टमधील विनंत्या/मर्यादा गुणोत्तरावर आधारित आनुपातिक स्केलिंग आहे:

CPU: 200m → 300m: प्रमाण 1:1.75;
मेमरी: 250Mi → 500Mi: 1:2 गुणोत्तर.

संबंधित आहे एचपीए, नंतर ऑपरेशनची यंत्रणा अधिक पारदर्शक आहे. प्रोसेसर आणि मेमरी यांसारख्या मेट्रिक्ससाठी थ्रेशोल्ड सेट केले जातात आणि जर सर्व प्रतिकृतींची सरासरी थ्रेशोल्डपेक्षा जास्त असेल, तर मूल्य थ्रेशोल्डच्या खाली येईपर्यंत किंवा प्रतिकृतींची कमाल संख्या गाठेपर्यंत अनुप्रयोग +1 पॉडने स्केल करतो.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 वरून घेतलेली प्रतिमा

CPU आणि मेमरी सारख्या नेहमीच्या मेट्रिक्स व्यतिरिक्त, तुम्ही तुमच्या सानुकूल Prometheus मेट्रिक्सवर थ्रेशोल्ड सेट करू शकता आणि तुमचा अर्ज कधी स्केल करायचा हे ठरवण्याचा हा सर्वात अचूक मार्ग आहे असे तुम्हाला वाटत असल्यास त्यांच्यासोबत कार्य करू शकता. एकदा अर्ज निर्दिष्ट मेट्रिक थ्रेशोल्डच्या खाली स्थिर झाल्यावर, HPA पॉड्सना प्रतिकृतींच्या किमान संख्येपर्यंत किंवा लोड थ्रेशोल्ड पूर्ण करेपर्यंत स्केल करणे सुरू करेल.

6. नोड अॅफिनिटी आणि पॉड अॅफिनिटी बद्दल विसरू नका

सर्व नोड्स एकाच हार्डवेअरवर चालत नाहीत आणि सर्व पॉड्सला गणना-केंद्रित अनुप्रयोग चालवण्याची आवश्यकता नाही. कुबर्नेट्स आपल्याला वापरून नोड्स आणि पॉड्सचे स्पेशलायझेशन निर्दिष्ट करण्याची परवानगी देते नोड आत्मीयता и पॉड अॅफिनिटी.

तुमच्याकडे मोजणी-केंद्रित ऑपरेशन्ससाठी योग्य नोड्स असल्यास, जास्तीत जास्त कार्यक्षमतेसाठी, अनुप्रयोगांना योग्य नोड्सशी बांधणे चांगले आहे. हे करण्यासाठी, वापरा nodeSelector नोड लेबलसह.

समजा तुमच्याकडे दोन नोड आहेत: एक सह CPUType=HIGHFREQ आणि मोठ्या संख्येने जलद कोर, दुसरा सह MemoryType=HIGHMEMORY अधिक स्मृती आणि जलद कार्यप्रदर्शन. नोडला पॉड डिप्लॉयमेंट नियुक्त करणे हा सर्वात सोपा मार्ग आहे HIGHFREQविभागात जोडून spec यासारखा निवडकर्ता:

…
nodeSelector:
	CPUType: HIGHFREQ

हे करण्यासाठी अधिक महाग आणि विशिष्ट मार्ग वापरणे आहे nodeAffinity शेतात affinity राझडेला spec. दोन पर्याय आहेत:

requiredDuringSchedulingIgnoredDuringExecution: हार्ड सेटिंग (शेड्यूलर केवळ विशिष्ट नोड्सवर पॉड तैनात करेल (आणि इतर कुठेही नाही));
preferredDuringSchedulingIgnoredDuringExecution: सॉफ्ट सेटिंग (शेड्युलर विशिष्ट नोड्सवर उपयोजित करण्याचा प्रयत्न करेल, आणि तो अयशस्वी झाल्यास, तो पुढील उपलब्ध नोडवर तैनात करण्याचा प्रयत्न करेल).

नोड लेबल्स व्यवस्थापित करण्यासाठी तुम्ही विशिष्ट वाक्यरचना निर्दिष्ट करू शकता, उदाहरणार्थ, In, NotIn, Exists, DoesNotExist, Gt किंवा Lt. तथापि, लक्षात ठेवा की लेबलांच्या लांबलचक याद्यांमधील जटिल पद्धती गंभीर परिस्थितीत निर्णय घेण्यास मंद करतात. दुसऱ्या शब्दांत, जास्त गुंतागुंत करू नका.

वर नमूद केल्याप्रमाणे, कुबर्नेट्स तुम्हाला वर्तमान शेंगांचे बंधन सेट करण्याची परवानगी देते. म्हणजेच, तुम्ही विशिष्ट पॉड्स समान उपलब्धता झोन (ढगांसाठी संबंधित) किंवा नोड्समध्ये इतर पॉड्ससह एकत्र काम करू शकता.

В podAffinity फील्ड affinity राझडेला spec च्या बाबतीत समान फील्ड उपलब्ध आहेत nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. फरक एवढाच आहे matchExpressions पॉड्स एका नोडशी बांधेल जे आधीपासूनच त्या लेबलसह पॉड चालवत आहे.

अधिक Kubernetes एक फील्ड ऑफर podAntiAffinity, जे, याउलट, विशिष्ट शेंगा असलेल्या नोडला पॉड बांधत नाही.

अभिव्यक्ती बद्दल nodeAffinity समान सल्ला दिला जाऊ शकतो: नियम सोपे आणि तार्किक ठेवण्याचा प्रयत्न करा, नियमांच्या जटिल संचासह पॉड तपशील ओव्हरलोड करण्याचा प्रयत्न करू नका. क्लस्टरच्या परिस्थितीशी जुळत नसलेला नियम तयार करणे, शेड्युलरवर अतिरिक्त भार टाकणे आणि एकूण कार्यप्रदर्शन खराब करणे खूप सोपे आहे.

7. कलंक आणि सहनशीलता

शेड्यूलर व्यवस्थापित करण्याचा दुसरा मार्ग आहे. तुमच्याकडे शेकडो नोड्स आणि हजारो मायक्रोसर्व्हिसेस असलेले मोठे क्लस्टर असल्यास, विशिष्ट पॉड्स विशिष्ट नोड्सद्वारे होस्ट करण्यापासून रोखणे खूप कठीण आहे.

कलंकांची यंत्रणा - प्रतिबंधित नियम - यास मदत करते. उदाहरणार्थ, तुम्ही विशिष्ट परिस्थितींमध्ये काही नोड्सला पॉड्स चालवण्यापासून रोखू शकता. विशिष्ट नोडवर कलंक लागू करण्यासाठी, पर्याय वापरा taint kubectl मध्ये. की आणि मूल्य निर्दिष्ट करा आणि नंतर कलंकित करा NoSchedule किंवा NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

हे देखील लक्षात घेण्यासारखे आहे की कलंक यंत्रणा तीन मुख्य प्रभावांना समर्थन देते: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule म्हणजे पॉड स्पेसिफिकेशनमध्ये संबंधित एंट्री होईपर्यंत tolerations, ते नोडवर उपयोजित केले जाऊ शकत नाही (या उदाहरणात node10).
PreferNoSchedule - सरलीकृत आवृत्ती NoSchedule. या प्रकरणात, शेड्युलर मॅचिंग एंट्री नसलेल्या पॉड्सचे वाटप न करण्याचा प्रयत्न करेल. tolerations प्रति नोड, परंतु ही कठोर मर्यादा नाही. क्लस्टरमध्ये कोणतीही संसाधने नसल्यास, या नोडवर शेंगा तैनात करणे सुरू होईल.
NoExecute - या परिणामामुळे शेंगा तात्काळ बाहेर काढणे सुरू होते ज्यात जुळणारी नोंद नाही tolerations.

उत्सुकतेने, हे वर्तन सहन करण्याची यंत्रणा वापरून पूर्ववत केले जाऊ शकते. जेव्हा "निषिद्ध" नोड असेल तेव्हा हे सोयीस्कर आहे आणि तुम्हाला त्यावर फक्त पायाभूत सेवा ठेवण्याची आवश्यकता आहे. ते कसे करायचे? ज्या शेंगांसाठी योग्य सहिष्णुता आहे फक्त त्या शेंगांना परवानगी द्या.

पॉड स्पेक कसा दिसेल ते येथे आहे:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

याचा अर्थ असा नाही की पुढील पुनर्नियोजनादरम्यान, पॉड नेमका या नोडला मारेल, ही नोड अॅफिनिटी यंत्रणा नाही आणि nodeSelector. परंतु अनेक वैशिष्ट्ये एकत्र करून, तुम्ही अतिशय लवचिक शेड्युलर सेटअप प्राप्त करू शकता.

8. पॉड उपयोजन प्राधान्य सेट करा

तुम्ही पॉड-टू-नोड बाइंडिंग्ज कॉन्फिगर केल्यामुळे याचा अर्थ असा नाही की सर्व पॉड्सना समान प्राधान्याने हाताळले जावे. उदाहरणार्थ, तुम्ही इतरांपूर्वी काही पॉड्स तैनात करू इच्छित असाल.

कुबर्नेट्स पॉड प्रायॉरिटी आणि प्रीम्प्शन सेट करण्याचे वेगवेगळे मार्ग देतात. सेटिंगमध्ये अनेक भाग असतात: ऑब्जेक्ट PriorityClass आणि फील्ड वर्णन priorityClassName पॉड तपशीलात. एक उदाहरण विचारात घ्या:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

आम्ही तयार करतो PriorityClass, त्याला नाव, वर्णन आणि मूल्य द्या. उच्च value, प्राधान्य जास्त. मूल्य 32 पेक्षा कमी किंवा बरोबरीचे कोणतेही 1-बिट पूर्णांक असू शकते. उच्च मूल्ये मिशन-क्रिटिकल सिस्टम पॉड्ससाठी राखीव आहेत, ज्यांना विशेषत: प्रीम्प्ट केले जाऊ शकत नाही. उच्च-प्राथमिकता असलेल्या पॉडला कुठेही वळणे नसेल तरच निष्कासन होईल, नंतर विशिष्ट नोडमधील काही पॉड्स रिकामी केल्या जातील. जर ही यंत्रणा तुमच्यासाठी खूप कठोर असेल तर तुम्ही पर्याय जोडू शकता preemptionPolicy: Never, आणि नंतर कोणतीही पूर्वकल्पना होणार नाही, पॉड रांगेत प्रथम असेल आणि शेड्यूलरला त्यासाठी विनामूल्य संसाधने शोधण्याची प्रतीक्षा करा.

पुढे, आम्ही एक पॉड तयार करतो, ज्यामध्ये आम्ही नाव निर्दिष्ट करतो priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority

तुम्ही तुम्हाला आवडेल तितके प्राधान्य वर्ग तयार करू शकता, जरी यासह वाहून जाऊ नये अशी शिफारस केली जाते (म्हणजे, स्वतःला कमी, मध्यम आणि उच्च प्राधान्यापर्यंत मर्यादित करा).

अशा प्रकारे, आवश्यक असल्यास, आपण nginx-ingress-controller, coredns, इत्यादी गंभीर सेवा तैनात करण्याची कार्यक्षमता वाढवू शकता.

9. तुमचे ETCD क्लस्टर ऑप्टिमाइझ करा

ETCD ला संपूर्ण क्लस्टरचा मेंदू म्हणता येईल. या डेटाबेसचे ऑपरेशन उच्च स्तरावर राखणे फार महत्वाचे आहे, कारण "क्यूब" मधील ऑपरेशन्सची गती यावर अवलंबून असते. बऱ्यापैकी मानक, आणि त्याच वेळी, कुबे-एपिसर्व्हरला किमान विलंब होण्यासाठी मास्टर नोड्सवर ETCD क्लस्टर ठेवणे हा एक चांगला उपाय आहे. हे शक्य नसल्यास, ETCD शक्य तितक्या जवळ ठेवा, सहभागींमध्ये चांगली बँडविड्थ ठेवा. क्लस्टरला हानी न होता ETCD मधील किती नोड्स बाहेर पडू शकतात यावर देखील लक्ष द्या.

लक्षात ठेवा की क्लस्टरमधील सहभागींच्या संख्येत अत्याधिक वाढ कार्यक्षमतेच्या खर्चावर दोष सहिष्णुता वाढवू शकते, सर्वकाही संयमात असावे.

जर आम्ही सेवा सेट करण्याबद्दल बोललो तर काही शिफारसी आहेत:

क्लस्टरच्या आकारावर आधारित चांगले हार्डवेअर (तुम्ही वाचू शकता येथे).
जर तुम्ही डीसीच्या जोडीमध्ये किंवा तुमच्या नेटवर्कमध्ये क्लस्टर पसरवले असेल तर काही पॅरामीटर्स ट्वीक करा आणि डिस्क्समध्ये बरेच काही हवे असेल (तुम्ही वाचू शकता येथे).

निष्कर्ष

हा लेख आमचा कार्यसंघ ज्या मुद्द्यांचे पालन करण्याचा प्रयत्न करतो त्याचे वर्णन करतो. हे कृतींचे चरण-दर-चरण वर्णन नाही, परंतु क्लस्टरचे ओव्हरहेड ऑप्टिमाइझ करण्यासाठी उपयुक्त ठरणारे पर्याय आहेत. हे स्पष्ट आहे की प्रत्येक क्लस्टर त्याच्या स्वत: च्या मार्गाने अद्वितीय आहे, आणि ट्यूनिंग सोल्यूशन्स मोठ्या प्रमाणात बदलू शकतात, म्हणून तुमच्याकडून अभिप्राय मिळणे मनोरंजक असेल: तुम्ही तुमच्या कुबर्नेट्स क्लस्टरचे निरीक्षण कसे करता, तुम्ही त्याचे कार्यप्रदर्शन कसे सुधारता. टिप्पण्यांमध्ये आपला अनुभव सामायिक करा, हे जाणून घेणे मनोरंजक असेल.

स्त्रोत: www.habr.com

नऊ कुबर्नेट्स कामगिरी टिपा