नौ कुबेरनेट्स प्रदर्शन युक्तियाँ

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

आप सभी अच्छी तरह से जानते हैं कि कुबेरनेट्स कंटेनर ऑर्केस्ट्रेशन के लिए एक स्केलेबल ओपन सोर्स सिस्टम है; ठीक है, या 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, यदि ऑप्स टीम ऐसे पॉड्स तैनात करना चाहती है जो अन्य 10 सीपीयू की खपत करेंगे, तो शेड्यूलर इसकी अनुमति नहीं देगा और एक त्रुटि देगा:

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. इष्टतम फ़ाइल भंडारण चुनें

यहां मैं लगातार वॉल्यूम और कुबेरनेट्स वर्कर नोड्स के डिस्क सबसिस्टम के विषय पर बात करना चाहूंगा। मुझे आशा है कि कोई भी उत्पादन में HDD पर "क्यूब" का उपयोग नहीं करेगा, लेकिन कभी-कभी एक नियमित SSD पर्याप्त नहीं होता है। हमें एक समस्या का सामना करना पड़ा जहां I/O संचालन के कारण लॉग डिस्क को बंद कर रहे थे, और कई समाधान नहीं थे:

• उच्च-प्रदर्शन SSDs का उपयोग करें या NVMe पर स्विच करें (यदि आप अपना स्वयं का हार्डवेयर प्रबंधित करते हैं)।

• लॉगिंग स्तर कम करें.

• पॉड्स का "स्मार्ट" संतुलन बनाएं जो डिस्क को रैप करता है (podAntiAffinity).

ऊपर दी गई स्क्रीन दिखाती है कि जब access_logs लॉगिंग सक्षम होती है (~12 हजार लॉग/सेकंड) तो डिस्क पर nginx-ingress-controller के तहत क्या होता है। यह स्थिति, निश्चित रूप से, इस नोड पर सभी अनुप्रयोगों के क्षरण का कारण बन सकती है।

जहां तक ​​पीवी का सवाल है, अफसोस, मैंने हर चीज की कोशिश नहीं की है प्रकार लगातार वॉल्यूम. सबसे अच्छे विकल्प का उपयोग करें जो आपके लिए उपयुक्त हो। ऐतिहासिक रूप से, हमारे देश में ऐसा हुआ है कि सेवाओं के एक छोटे हिस्से को आरडब्ल्यूएक्स वॉल्यूम की आवश्यकता होती है, और बहुत समय पहले उन्होंने इस कार्य के लिए एनएफएस स्टोरेज का उपयोग करना शुरू कर दिया था। सस्ता और...पर्याप्त। बेशक, उसने और मैंने गंदगी खा ली - आपका भला हो, लेकिन हमने इसे ठीक करना सीख लिया, और अब मेरे सिर में दर्द नहीं होता। और यदि संभव हो, तो S3 ऑब्जेक्ट स्टोरेज पर जाएँ।

3. अनुकूलित छवियाँ एकत्र करें

कंटेनर-अनुकूलित छवियों का उपयोग करना सबसे अच्छा है ताकि कुबेरनेट्स उन्हें तेज़ी से ला सकें और उन्हें अधिक कुशलता से निष्पादित कर सकें। 

अनुकूलित का अर्थ है कि छवियाँ:

• केवल एक एप्लिकेशन शामिल करें या केवल एक ही कार्य करें;

• आकार में छोटा, क्योंकि बड़ी छवियां नेटवर्क पर खराब तरीके से प्रसारित होती हैं;

• स्वास्थ्य और तत्परता समापन बिंदु हैं जो कुबेरनेट्स को डाउनटाइम की स्थिति में कार्रवाई करने की अनुमति देते हैं;

• कंटेनर-अनुकूल ऑपरेटिंग सिस्टम (जैसे अल्पाइन या कोरओएस) का उपयोग करें, जो कॉन्फ़िगरेशन त्रुटियों के प्रति अधिक प्रतिरोधी हैं;

• मल्टी-स्टेज बिल्ड का उपयोग करें ताकि आप केवल संकलित अनुप्रयोगों को तैनात कर सकें, न कि संबंधित स्रोतों को।

ऐसे कई उपकरण और सेवाएँ हैं जो आपको तुरंत छवियों की जाँच और अनुकूलन करने की अनुमति देती हैं। उन्हें हमेशा अद्यतन रखना और सुरक्षा के लिए परीक्षण करना महत्वपूर्ण है। परिणामस्वरूप आपको मिलता है:

1. पूरे क्लस्टर पर नेटवर्क लोड कम हो गया।

2. कंटेनर स्टार्टअप समय को कम करना।

3. आपकी संपूर्ण डॉकर रजिस्ट्री का छोटा आकार।

4. डीएनएस कैश का प्रयोग करें

यदि हम उच्च भार के बारे में बात करते हैं, तो क्लस्टर के DNS सिस्टम को ट्यून किए बिना जीवन बहुत घटिया है। एक बार, कुबेरनेट्स डेवलपर्स ने उनके क्यूब-डीएनएस समाधान का समर्थन किया था। इसे यहां भी लागू किया गया था, लेकिन यह सॉफ़्टवेयर विशेष रूप से ट्यून नहीं किया गया था और आवश्यक प्रदर्शन नहीं दे पाया, हालांकि यह एक सरल कार्य प्रतीत होता था। फिर coredns दिखाई दिए, जिसे हमने स्विच किया और हमें कोई दुख नहीं हुआ; यह बाद में K8s में डिफ़ॉल्ट DNS सेवा बन गई। कुछ बिंदु पर, हम DNS सिस्टम में 40 हजार आरपीएस तक बढ़ गए, और यह समाधान भी अपर्याप्त हो गया। लेकिन, भाग्य से, नोडेलोकल्डन्स बाहर आ गया, उर्फ ​​नोड स्थानीय कैश, उर्फ नोडलोकल DNSCache.

हम इसका उपयोग क्यों करते हैं? लिनक्स कर्नेल में एक बग है, जब यूडीपी पर कॉनट्रैक एनएटी के माध्यम से एकाधिक कॉल करते हैं, तो कॉनट्रैक तालिकाओं में प्रविष्टियों के लिए दौड़ की स्थिति पैदा होती है, और एनएटी के माध्यम से यातायात का हिस्सा खो जाता है (सेवा के माध्यम से प्रत्येक यात्रा एनएटी है)। Nodelocaldns NAT से छुटकारा पाकर और टीसीपी से कनेक्शन को अपस्ट्रीम DNS में अपग्रेड करके, साथ ही स्थानीय रूप से अपस्ट्रीम DNS क्वेरीज़ को कैशिंग करके (5-सेकंड के छोटे नकारात्मक कैश सहित) इस समस्या को हल करता है।

5. पॉड्स को क्षैतिज और लंबवत रूप से स्वचालित रूप से स्केल करें

क्या आप विश्वास के साथ कह सकते हैं कि आपके सभी माइक्रोसर्विसेज लोड में दो से तीन गुना वृद्धि के लिए तैयार हैं? अपने अनुप्रयोगों के लिए संसाधनों का उचित आवंटन कैसे करें? कार्यभार से परे कुछ पॉड्स को चालू रखना निरर्थक हो सकता है, लेकिन उन्हें लगातार चालू रखने से सेवा में ट्रैफ़िक में अचानक वृद्धि से डाउनटाइम का जोखिम रहता है। जैसी सेवाएं क्षैतिज पॉड ऑटोस्केलर и वर्टिकल पॉड ऑटोस्केलर.

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

छवि https://levelup.gitconnected.com/kubernetes-autoscaleing-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 से ली गई है

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

उदाहरण के लिए, यहां सामान्य पॉड सेटिंग्स हैं:

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

जैसा कि ऊपर बताया गया है, यह मेनिफेस्ट में अनुरोध/सीमा अनुपात के आधार पर आनुपातिक स्केलिंग है:

• सीपीयू: 200 मीटर → 300 मीटर: अनुपात 1:1.75;

• मेमोरी: 250Mi → 500Mi: अनुपात 1:2.

संबंध में एचपीए, तो संचालन का तंत्र अधिक पारदर्शी है। सीपीयू और मेमोरी जैसे मेट्रिक्स को थ्रेसहोल्ड किया जाता है, और यदि सभी प्रतिकृतियों का औसत सीमा से अधिक हो जाता है, तो एप्लिकेशन को +1 उप द्वारा स्केल किया जाता है जब तक कि मान सीमा से नीचे न आ जाए या जब तक प्रतिकृतियों की अधिकतम संख्या न पहुंच जाए।

छवि https://levelup.gitconnected.com/kubernetes-autoscaleing-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 से ली गई है

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

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 पॉड्स को एक नोड से बांध देगा जो पहले से ही उस लेबल के साथ एक पॉड चला रहा है।

कुबेरनेट्स एक फ़ील्ड भी प्रदान करता है 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-नियंत्रक, coredns, आदि जैसी महत्वपूर्ण सेवाओं को तैनात करने की दक्षता बढ़ा सकते हैं।

9. ETCD क्लस्टर को अनुकूलित करें

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

ध्यान रखें कि क्लस्टर में सदस्यों की संख्या अत्यधिक बढ़ाने से प्रदर्शन की कीमत पर दोष सहनशीलता बढ़ सकती है, सब कुछ संयमित होना चाहिए।

यदि हम सेवा स्थापित करने के बारे में बात करते हैं, तो कुछ सिफारिशें हैं:

1. क्लस्टर के आकार के आधार पर अच्छा हार्डवेयर रखें (आप पढ़ सकते हैं यहां).

2. यदि आपने डीसी की एक जोड़ी या अपने नेटवर्क और डिस्क के बीच एक क्लस्टर फैलाया है तो कुछ मापदंडों में बदलाव करें (आप पढ़ सकते हैं) यहां).

निष्कर्ष

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

स्रोत: www.habr.com