Kubernetes उत्कृष्ट अभ्यासहरू। स्रोत अनुरोध र सीमाहरू सेट अप गर्दै

Kubernetes उत्कृष्ट अभ्यासहरू। साना कन्टेनरहरू सिर्जना गर्दै
Kubernetes उत्कृष्ट अभ्यासहरू। नेमस्पेस संग Kubernetes को संगठन
Kubernetes उत्कृष्ट अभ्यासहरू। तत्परता र जीवन्तता परीक्षणहरूको साथ Kubernetes Liveness मान्य गर्दै

प्रत्येक Kubernetes स्रोतको लागि, तपाइँ दुई प्रकारका आवश्यकताहरू कन्फिगर गर्न सक्नुहुन्छ - अनुरोधहरू र सीमाहरू। पहिलोले कन्टेनर वा पोड चलाउन आवश्यक नि:शुल्क नोड स्रोतहरूको उपलब्धताको लागि न्यूनतम आवश्यकताहरू वर्णन गर्दछ, दोस्रोले कन्टेनरमा उपलब्ध स्रोतहरूलाई कडाइका साथ सीमित गर्दछ।

जब Kubernetes ले पोडहरू अनुसूचित गर्दछ, यो धेरै महत्त्वपूर्ण छ कि कन्टेनरहरूसँग राम्ररी काम गर्न पर्याप्त स्रोतहरू छन्। यदि तपाइँ स्रोत-प्रतिबन्धित नोडमा ठूलो एप्लिकेसन डिप्लोय गर्ने योजना गर्दै हुनुहुन्छ भने, नोड मेमोरीमा कम चलिरहेको वा CPU पावर समाप्त भएकोले यो नचल्ने सम्भावना छ। यस लेखमा, हामी संसाधन अनुरोध र सीमाहरू प्रयोग गरेर कम्प्युटिङ पावर अभाव कसरी समाधान गर्न सक्नुहुन्छ भनेर हेर्नेछौं।

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

कन्टेनरले आफ्नो कम्प्युटिङ पावरलाई निश्चित सीमासम्म मात्र बढाउन सक्छ, त्यसपछि यो सीमित हुनेछ। यो कसरी काम गर्छ हेरौं। त्यसोभए, त्यहाँ दुई प्रकारका स्रोतहरू छन् - प्रोसेसर र मेमोरी। Kubernetes अनुसूचकले तपाइँको पोडहरू कहाँ चलाउने भनेर पत्ता लगाउन यी स्रोतहरूको बारेमा डेटा प्रयोग गर्दछ। पोडको लागि एक विशिष्ट संसाधन विशिष्टता यस्तो देखिन्छ।

पोडमा प्रत्येक कन्टेनरले आफ्नै प्रश्नहरू र सीमाहरू सेट गर्न सक्छ, यो सबै additive छ। प्रोसेसर स्रोतहरू मिलिकोरमा परिभाषित छन्। यदि तपाइँको कन्टेनर चलाउन दुई पूर्ण कोर चाहिन्छ भने, तपाइँ 2000m मा मान सेट गर्नुहुन्छ। यदि कन्टेनरलाई केवल कोरको 1/4 को शक्ति चाहिन्छ भने, मान 250m हुनेछ। ध्यानमा राख्नुहोस् कि यदि तपाईंले सबैभन्दा ठूलो नोडको कोरको सङ्ख्याभन्दा ठूलो CPU स्रोत मान तोक्नुभयो भने, तपाईंको पोड सुरु हुनको लागि निर्धारित गरिने छैन। यदि तपाइँसँग चार कोर चाहिने पोड छ भने, र कुबेरनेट क्लस्टरमा केवल दुईवटा मुख्य भर्चुअल मेसिनहरू छन् भने यस्तै अवस्था देखा पर्नेछ।

जबसम्म तपाइँको एप्लिकेसन विशेष गरी धेरै कोरहरूको फाइदा लिन डिजाइन गरिएको छैन (जटिल वैज्ञानिक कम्प्युटि and र डाटाबेस अपरेशनहरू दिमागमा आउँछ), तब उत्तम अभ्यास भनेको CPU अनुरोधहरूलाई १ वा कममा सेट गर्नु हो र त्यसपछि स्केलेबिलिटीमा थप प्रतिकृतिहरू चलाउनु हो। यस समाधानले प्रणालीलाई थप लचिलोपन र विश्वसनीयता दिनेछ।

जब यो CPU सीमितताहरूको लागि आउँदछ, चीजहरू थप रोचक हुन्छन् किनभने यो एक संकुचित संसाधन मानिन्छ। यदि तपाइँको एप्लिकेसनले प्रोसेसर पावर लिमिटमा पुग्न थाल्छ भने, कुबेरनेटले तपाइँको कन्टेनरलाई CPU थ्रॉटलिङ प्रयोग गरेर ढिलो गर्न सुरु गर्नेछ - प्रोसेसर फ्रिक्वेन्सी घटाउँदै। यसको मतलब यो हो कि CPU कृत्रिम रूपमा थ्रोटल हुनेछ, अनुप्रयोगलाई सम्भावित रूपमा खराब प्रदर्शन प्रदान गर्दै, तर प्रक्रिया समाप्त वा बाहिर निकालिने छैन।

मेमोरी स्रोतहरू बाइटहरूमा परिभाषित छन्। सामान्यतया सेटिङ्हरूमा मान mebibytes Mib मा मापन गरिन्छ, तर तपाइँ बाइट्स देखि petabytes सम्म कुनै पनि मान सेट गर्न सक्नुहुन्छ। CPU मा जस्तै यहाँ पनि यही अवस्था लागू हुन्छ - यदि तपाईंले आफ्नो नोडहरूमा मेमोरीको मात्रा भन्दा बढी मेमोरीको लागि अनुरोध गर्नुभयो भने, त्यो पोड कार्यान्वयन गर्न निर्धारित गरिने छैन। तर CPU स्रोतहरूको विपरीत, मेमोरी कम्प्रेस गरिएको छैन किनभने यसको प्रयोगलाई सीमित गर्ने कुनै तरिका छैन। तसर्थ, कन्टेनरको कार्यान्वयन यसलाई छुट्याइएको मेमोरी भन्दा बाहिर जाने बित्तिकै रोकिनेछ।

यो याद गर्न महत्त्वपूर्ण छ कि तपाइँ अनुरोधहरू कन्फिगर गर्न सक्नुहुन्न जुन तपाइँको नोडहरूले प्रदान गर्न सक्ने स्रोतहरू भन्दा बढी छ। GKE भर्चुअल मेसिनहरूका लागि साझा संसाधन विशिष्टताहरू यस भिडियोको तलको लिङ्कहरूमा फेला पार्न सकिन्छ।

एक आदर्श संसारमा, कन्टेनरको पूर्वनिर्धारित सेटिङहरू कार्यप्रवाहहरू सहज रूपमा चलिरहेको राख्न पर्याप्त हुनेछ। तर वास्तविक संसार त्यस्तो छैन, मानिसहरू सजिलैसँग स्रोतहरूको प्रयोग कन्फिगर गर्न बिर्सन सक्छन्, वा ह्याकरहरूले पूर्वाधारको वास्तविक क्षमताहरू भन्दा बढी अनुरोध र प्रतिबन्धहरू सेट गर्नेछन्। त्यस्ता परिदृश्यहरू हुनबाट रोक्नको लागि, तपाईंले ResourceQuota र LimitRange स्रोत कोटाहरू कन्फिगर गर्न सक्नुहुन्छ।

एकपटक नेमस्पेस सिर्जना भएपछि, यसलाई कोटाहरू प्रयोग गरेर ब्लक गर्न सकिन्छ। उदाहरणका लागि, यदि तपाईंसँग prod र dev नेमस्पेसहरू छन् भने, ढाँचा यो हो कि त्यहाँ कुनै उत्पादन कोटाहरू छैनन् र धेरै कडा विकास कोटाहरू छन्। यसले प्रोडलाई ट्राफिकमा तीव्र वृद्धिको घटनामा, सम्पूर्ण उपलब्ध स्रोतहरू लिन, पूर्ण रूपमा dev लाई अवरुद्ध गर्न अनुमति दिन्छ।

स्रोत कोटा यस्तो देखिन सक्छ। यस उदाहरणमा 4 खण्डहरू छन् - यी कोडको 4 तल्लो रेखाहरू हुन्।

तिनीहरूमध्ये प्रत्येकलाई हेरौं। Requests.cpu संयुक्त CPU अनुरोधहरूको अधिकतम संख्या हो जुन नेमस्पेसका सबै कन्टेनरहरूबाट आउन सक्छ। यस उदाहरणमा, तपाईंसँग 50m अनुरोधहरू भएका 10 कन्टेनरहरू, 100m अनुरोधहरू भएका पाँचवटा कन्टेनरहरू, वा 500m अनुरोधहरू भएको एउटा मात्र कन्टेनर हुन सक्छ। जबसम्म दिइएको नेमस्पेसको requests.cpu को कुल संख्या 500m भन्दा कम छ, सबै कुरा ठीक हुनेछ।

मेमोरी अनुरोध गरिएको अनुरोधहरू।मेमोरी संयुक्त मेमोरी अनुरोधहरूको अधिकतम मात्रा हो जुन नेमस्पेसका सबै कन्टेनरहरूमा हुन सक्छ। अघिल्लो अवस्थामा जस्तै, नामस्थानमा अनुरोध गरिएको मेमोरीको कुल मात्रा १०० मेबिबाइट्सभन्दा कम भएसम्म तपाईंसँग ५० २ माइब कन्टेनरहरू, पाँच २० माइब कन्टेनरहरू, वा एकल १०० माइब कन्टेनर हुन सक्छन्।

Limits.cpu CPU पावरको अधिकतम संयुक्त मात्रा हो जुन नेमस्पेसका सबै कन्टेनरहरूले प्रयोग गर्न सक्छन्। हामी यसलाई प्रोसेसर पावर अनुरोधहरूको सीमा मान्न सक्छौं।

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

सीमा दायराले प्रतिबन्धहरू प्रदान गर्दछ जसले गर्न सक्छ:

• नेमस्पेसमा प्रत्येक मोड्युल वा कन्टेनरको लागि कम्प्युटिङ स्रोतहरूको न्यूनतम र अधिकतम प्रयोग सुनिश्चित गर्नुहोस्;
• नेमस्पेसमा प्रत्येक Persistent VolumeClaim को लागि न्यूनतम र अधिकतम Starage अनुरोध भण्डारण अनुरोधहरू लागू गर्नुहोस्;
• नाम स्थानमा स्रोतको लागि अनुरोध र सीमा बीचको सम्बन्ध लागू गर्नुहोस्;
• नामस्थानमा गणना स्रोतहरूको लागि पूर्वनिर्धारित अनुरोधहरू/सीमाहरू सेट गर्नुहोस् र रनटाइममा तिनीहरूलाई स्वचालित रूपमा कन्टेनरहरूमा इन्जेक्ट गर्नुहोस्।

यस तरिकाले तपाइँ आफ्नो नेमस्पेसमा सीमा दायरा सिर्जना गर्न सक्नुहुन्छ। कोटा विपरीत, जुन सम्पूर्ण नेमस्पेसमा लागू हुन्छ, सीमा दायरा व्यक्तिगत कन्टेनरहरूको लागि प्रयोग गरिन्छ। यसले प्रयोगकर्ताहरूलाई नेमस्पेस भित्र धेरै सानो वा, विपरित, विशाल कन्टेनरहरू सिर्जना गर्नबाट रोक्न सक्छ। सीमा दायरा यस्तो देखिन सक्छ।

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

पूर्वनिर्धारित अनुरोध खण्ड पूर्वनिर्धारित अनुरोधले पोडमा कन्टेनरका लागि पूर्वनिर्धारित अनुरोधहरू कन्फिगर गर्दछ। फेरि, यदि तपाईंले यी मानहरूलाई चरम दायरामा सेट गर्नुभयो भने, कुनै पनि कन्टेनरहरू जसले स्पष्ट रूपमा यी विकल्पहरू सेट गर्दैनन् यी मानहरूमा पूर्वनिर्धारित हुनेछन्।

अधिकतम खण्डले पोडमा कन्टेनरको लागि सेट गर्न सकिने अधिकतम सीमाहरू निर्दिष्ट गर्दछ। पूर्वनिर्धारित खण्ड र कन्टेनर सीमाहरूमा मानहरू यो सीमा भन्दा माथि सेट गर्न सकिँदैन। यो नोट गर्न महत्त्वपूर्ण छ कि यदि मान अधिकतममा सेट गरिएको छ र त्यहाँ कुनै पूर्वनिर्धारित खण्ड छैन भने, अधिकतम मान पूर्वनिर्धारित मान हुन्छ।

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

फेरि, यो नोट गर्न महत्त्वपूर्ण छ कि यदि यो मान सेट गरिएको छ, पूर्वनिर्धारित छैन, त्यसपछि न्यूनतम मान पूर्वनिर्धारित प्रम्प्ट हुन्छ।

यी स्रोत अनुरोधहरू अन्ततः तपाइँको कार्यभारहरू कार्यान्वयन गर्न Kubernetes अनुसूचक द्वारा प्रयोग गरिन्छ। तपाईंको कन्टेनरहरू सही रूपमा कन्फिगर गर्नको लागि, यसले कसरी काम गर्छ भनेर बुझ्न महत्त्वपूर्ण छ। मानौं तपाईं आफ्नो क्लस्टरमा धेरै पोडहरू चलाउन चाहनुहुन्छ। पोड विशिष्टताहरू मान्य छन् भनी मान्दै, Kubernetes तालिकाले कार्यभार चलाउनको लागि नोड चयन गर्न राउन्ड रोबिन ब्यालेन्सिङ प्रयोग गर्नेछ।

Kubernetes नोड 1 सँग पोड कन्टेनरहरूबाट अनुरोधहरू पूरा गर्न पर्याप्त स्रोतहरू छन् कि छैनन् भनेर जाँच गर्नेछ, र यदि यो छैन भने, यो अर्को नोडमा जान्छ। यदि प्रणालीमा कुनै पनि नोडहरूले अनुरोधहरू पूरा गर्न सक्षम भएन भने, पोडहरू पेन्डिङ अवस्थामा जानेछन्। Google Kubernetes इन्जिन सुविधाहरू जस्तै नोड अटोस्केलिङ्ग प्रयोग गरेर, GKE ले स्वतः प्रतीक्षा अवस्था पत्ता लगाउन सक्छ र धेरै थप नोडहरू सिर्जना गर्न सक्छ।

यदि तपाइँ पछि नोड क्षमता समाप्त भयो भने, स्वत: स्केलिङले तपाइँको पैसा बचत गर्न नोडहरूको संख्या घटाउनेछ। यही कारणले कुबर्नेट्सले अनुरोधहरूमा आधारित पोडहरू अनुसूचित गर्दछ। यद्यपि, सीमा अनुरोधहरू भन्दा बढी हुन सक्छ, र केहि अवस्थाहरूमा नोडले वास्तवमा स्रोतहरू समाप्त हुन सक्छ। यस राज्यलाई हामी ओभर कमिटमेन्ट स्टेट भन्छौं।

मैले भनेझैं, जब यो CPU को कुरा आउँछ, Kubernetes ले पोडहरू सीमित गर्न थाल्छ। प्रत्येक पोडले अनुरोध गरे जति प्राप्त गर्नेछ, तर यदि यो सीमामा पुगेन भने, थ्रॉटलिंग लागू हुन सुरु हुनेछ।

जब यो मेमोरी स्रोतहरूको कुरा आउँछ, कुबेरनेटलाई कुन पोडहरू मेटाउने र कुनलाई राख्ने भन्ने निर्णय गर्न बाध्य हुन्छ जबसम्म तपाइँ प्रणाली स्रोतहरू खाली गर्नुहुन्न वा सम्पूर्ण प्रणाली क्र्यास हुनेछ।

एउटा परिदृश्यको कल्पना गरौं जहाँ तपाईँको मेसिनको मेमोरी सकिएको छ - Kubernetes यसलाई कसरी ह्यान्डल गर्नेछ?

Kubernetes ले अनुरोध गरेको भन्दा बढी स्रोतहरू प्रयोग गर्ने पोडहरू खोज्नेछ। त्यसोभए यदि तपाइँका कन्टेनरहरूमा कुनै पनि अनुरोध छैन भने, यसको मतलब उनीहरूले मागेको भन्दा बढी प्रयोग गर्न पूर्वनिर्धारित छन्, केवल किनभने उनीहरूले केहि पनि मागेनन्! त्यस्ता कन्टेनरहरू बन्दका लागि प्रमुख उम्मेदवार बन्छन्। अर्को उम्मेद्वारहरू कन्टेनरहरू हुन् जसले तिनीहरूका सबै अनुरोधहरू पूरा गरेका छन् तर अझै पनि अधिकतम सीमाभन्दा तल छन्।

त्यसोभए यदि Kubernetes ले धेरै पोडहरू फेला पार्छ जसले उनीहरूको अनुरोध प्यारामिटरहरू पार गरेको छ, यसले तिनीहरूलाई प्राथमिकता अनुसार क्रमबद्ध गर्नेछ र त्यसपछि सबैभन्दा कम प्राथमिकता पोडहरू हटाउनेछ। यदि सबै पोडहरूमा समान प्राथमिकता छ भने, कुबेरनेटले ती पोडहरू समाप्त गर्नेछन् जुन अन्य पोडहरू भन्दा बढी उनीहरूको अनुरोधहरू छन्।

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

Kubernetes उत्कृष्ट अभ्यासहरू। सही बन्द समाप्त

केही विज्ञापनहरू 🙂

हामीसँग रहनु भएकोमा धन्यवाद। तपाईलाई हाम्रा लेखहरू मनपर्छ? थप रोचक सामग्री हेर्न चाहनुहुन्छ? हामीलाई अर्डर गरेर वा साथीहरूलाई सिफारिस गरेर समर्थन गर्नुहोस्, $4.99 बाट विकासकर्ताहरूको लागि क्लाउड VPS, प्रविष्टि-स्तर सर्भरहरूको एक अद्वितीय एनालग, जुन हामीले तपाईंको लागि आविष्कार गरेको हो: VPS (KVM) E5-2697 v3 (6 कोर) 10GB DDR4 480GB SSD 1Gbps $ 19 बाट वा कसरी सर्भर साझा गर्ने बारे सम्पूर्ण सत्य? (RAID1 र RAID10 सँग उपलब्ध, 24 कोर सम्म र 40GB DDR4 सम्म)।

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com