डिजाइनिंग कुबेरनेट क्लस्टर: कितने होने चाहिए?

टिप्पणी। अनुवाद।: यह सामग्री एक शैक्षिक परियोजना से है 8s - कुबेरनेट्स पर आधारित बुनियादी ढांचे को डिजाइन करते समय एक लोकप्रिय प्रश्न का उत्तर। हम आशा करते हैं कि प्रत्येक विकल्प के पेशेवरों और विपक्षों के पर्याप्त विस्तृत विवरण से आपको अपनी परियोजना के लिए सर्वोत्तम विकल्प बनाने में मदद मिलेगी।

TL, डॉ: वर्कलोड का एक ही सेट कई बड़े क्लस्टर्स पर चलाया जा सकता है (प्रत्येक क्लस्टर में बड़ी संख्या में वर्कलोड होंगे) या कई छोटे क्लस्टर्स पर (प्रत्येक क्लस्टर में वर्कलोड की एक छोटी संख्या के साथ)।

नीचे एक तालिका है जो प्रत्येक दृष्टिकोण के पेशेवरों और विपक्षों का मूल्यांकन करती है:

अनुप्रयोगों को चलाने के लिए एक मंच के रूप में कुबेरनेट्स का उपयोग करते समय, क्लस्टर को कॉन्फ़िगर करने की पेचीदगियों के बारे में अक्सर कई मूलभूत प्रश्न होते हैं:

• कितने क्लस्टर का उपयोग करना है?
• आपको उन्हें कितना बड़ा बनाना चाहिए?
• प्रत्येक क्लस्टर में क्या शामिल होना चाहिए?

इस लेख में, मैं प्रत्येक दृष्टिकोण के पेशेवरों और विपक्षों का विश्लेषण करके इन सभी सवालों का जवाब देने का प्रयास करूंगा।

एक प्रश्न का कथन

एक सॉफ्टवेयर डेवलपर के रूप में, आप समानांतर में कई अनुप्रयोगों को विकसित और संचालित कर सकते हैं।

इसके अलावा, इन अनुप्रयोगों के कई उदाहरणों के विभिन्न वातावरणों में चलने की संभावना है - उदाहरण के लिए, ये हो सकते हैं देव, परीक्षण и ठेस.

परिणाम अनुप्रयोगों और वातावरणों का एक संपूर्ण मैट्रिक्स है:

अनुप्रयोग और वातावरण

उपरोक्त उदाहरण में, 3 अनुप्रयोग और 3 वातावरण हैं, जिसके परिणामस्वरूप कुल 9 संभावित विकल्प हैं।

प्रत्येक एप्लिकेशन इंस्टेंस एक स्व-निहित परिनियोजन इकाई है जिसे आप दूसरों से स्वतंत्र रूप से काम कर सकते हैं।

ध्यान दें कि आवेदन उदाहरण बहुत से शामिल हो सकते हैं घटकोंजैसे फ्रंटएंड, बैकएंड, डेटाबेस आदि। एक माइक्रोसर्विस एप्लिकेशन के मामले में, उदाहरण में सभी माइक्रोसर्विसेज शामिल होंगे।

परिणामस्वरूप, कुबेरनेट्स उपयोगकर्ताओं के पास कई प्रश्न हैं:

• क्या सभी एप्लिकेशन इंस्टेंस को एक ही क्लस्टर पर होस्ट किया जाना चाहिए?
• क्या प्रत्येक एप्लिकेशन इंस्टेंस के लिए एक अलग क्लस्टर शुरू करना उचित है?
• या शायद उपर्युक्त दृष्टिकोणों का संयोजन इस्तेमाल किया जाना चाहिए?

ये सभी विकल्प व्यवहार्य हैं, क्योंकि कुबेरनेट्स एक लचीली प्रणाली है जो उपयोगकर्ता के विकल्पों को सीमित नहीं करती है।

यहाँ कुछ संभावित तरीके दिए गए हैं:

• एक बड़ा सामान्य समूह;
• कई छोटे अति विशिष्ट क्लस्टर;
• प्रति आवेदन एक क्लस्टर;
• प्रति पर्यावरण एक क्लस्टर।

जैसा कि नीचे दिखाया गया है, पहले दो दृष्टिकोण विकल्पों के पैमाने के विपरीत छोर पर हैं:

कुछ बड़े समूहों (बाएं) से कई छोटे समूहों (दाएं) तक

सामान्य तौर पर, यह माना जाता है कि एक क्लस्टर दूसरे की तुलना में "बड़ा" होता है यदि इसमें नोड्स और पॉड के योग से अधिक हो। उदाहरण के लिए, 10 नोड्स और 100 पॉड्स वाला क्लस्टर 1 नोड और 10 पॉड्स वाले क्लस्टर से बड़ा होता है।

खैर, चलिए शुरू करते हैं!

1. एक बड़ा साझा क्लस्टर

पहला विकल्प सभी वर्कलोड को एक क्लस्टर में रखना है:

एक बड़ा क्लस्टर

इस दृष्टिकोण के भीतर, क्लस्टर का उपयोग सार्वभौमिक के रूप में किया जाता है बुनियादी ढांचा मंच - आप मौजूदा कुबेरनेट्स क्लस्टर में बस अपनी जरूरत की हर चीज को तैनात करते हैं।

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

आइए इस दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

+ संसाधनों का कुशल उपयोग

एकल क्लस्टर के मामले में, कुबेरनेट्स क्लस्टर को चलाने और प्रबंधित करने के लिए आवश्यक सभी संसाधनों की केवल एक प्रति की आवश्यकता होगी।

उदाहरण के लिए, यह मास्टर नोड्स के लिए सही है। आमतौर पर, प्रति कुबेरनेट्स क्लस्टर में 3 मास्टर नोड होते हैं, इसलिए एक क्लस्टर के लिए, उनकी संख्या उतनी ही रहेगी (तुलना के लिए, 10 क्लस्टर को 30 मास्टर नोड की आवश्यकता होगी)।

उपरोक्त सूक्ष्मता अन्य सेवाओं पर भी लागू होती है जो पूरे क्लस्टर में काम करती हैं, जैसे कि लोड बैलेंसर्स, इनग्रेड कंट्रोलर, ऑथेंटिकेशन, लॉगिंग और मॉनिटरिंग सिस्टम।

एक ही क्लस्टर में, इन सभी सेवाओं का उपयोग एक साथ सभी वर्कलोड के लिए किया जा सकता है (कई क्लस्टर के मामले में इनकी प्रतियां बनाने की आवश्यकता नहीं है)।

+ सस्ता

उपरोक्त के परिणामस्वरूप, कम क्लस्टर आमतौर पर सस्ते होते हैं क्योंकि अतिरिक्त संसाधनों की कोई कीमत नहीं होती है।

यह मास्टर्नोड्स के लिए विशेष रूप से सच है, जिसके लिए ऑन-प्रिमाइसेस या क्लाउड में होस्ट किए जाने पर काफी पैसा खर्च हो सकता है।

कुछ प्रबंधित कुबेरनेट्स सेवाएं जैसे Google कुबेरनेट्स इंजन (GKE) या Azure Kubernetes सेवा (AKS), मुफ्त में नियंत्रण परत प्रदान करें। इस मामले में, लागत का मुद्दा कम तीव्र है।

ऐसी प्रबंधित सेवाएँ भी हैं जो प्रत्येक कुबेरनेट क्लस्टर के संचालन के लिए एक निश्चित शुल्क लेती हैं (उदाहरण के लिए, अमेज़ॅन लोचदार कुबेरनेट्स सेवा, ईकेएस).

+ कुशल प्रशासन

एक क्लस्टर को कई की तुलना में प्रबंधित करना आसान है।

प्रशासन में निम्नलिखित कार्य शामिल हो सकते हैं:

• कुबेरनेट्स के संस्करण को अद्यतन करना;
• सीआई/सीडी पाइपलाइन को विन्यस्त करना;
• सीएनआई प्लगइन स्थापित करना;
• एक उपयोगकर्ता प्रमाणीकरण प्रणाली की स्थापना;
• प्रवेश नियंत्रक की स्थापना;

और बहुत सारे…

सिंगल क्लस्टर के मामले में आपको यह सब सिर्फ एक बार करना होगा।

कई समूहों के लिए, संचालन को कई बार दोहराना होगा, जिसके लिए एक व्यवस्थित और समान प्रक्रिया सुनिश्चित करने के लिए संभवतः प्रक्रियाओं और उपकरणों के कुछ स्वचालन की आवश्यकता होगी।

और अब विपक्ष के बारे में कुछ शब्द।

- विफलता का एकल बिंदु

मना करने की स्थिति में एकमात्र क्लस्टर तुरंत काम करना बंद कर देंगे सब काम का बोझ!

जब कुछ गलत हो सकता है तो उसके लिए कई विकल्प हैं:

• कुबेरनेट्स के उन्नयन से अप्रत्याशित दुष्प्रभाव होते हैं
• एक क्लस्टर-वाइड घटक (उदाहरण के लिए, एक CNI प्लगइन) अपेक्षा के अनुरूप काम करना शुरू नहीं करता है;
• क्लस्टर घटकों में से एक गलत तरीके से कॉन्फ़िगर किया गया है;
• अंतर्निहित बुनियादी ढांचे में विफलता।

इस तरह की एक घटना एक सामान्य क्लस्टर में होस्ट किए गए सभी वर्कलोड को गंभीर नुकसान पहुंचा सकती है।

- कठोर इन्सुलेशन का अभाव

एक साझा क्लस्टर में चलने का मतलब है कि एप्लिकेशन हार्डवेयर, नेटवर्किंग क्षमताओं और ऑपरेटिंग सिस्टम को क्लस्टर नोड्स पर साझा करते हैं।

एक मायने में, एक ही होस्ट पर चलने वाले दो अलग-अलग एप्लिकेशन वाले दो कंटेनर एक ही OS कर्नेल पर चलने वाली एक ही मशीन पर चलने वाली दो प्रक्रियाओं की तरह हैं।

लिनक्स कंटेनर अलगाव का कुछ रूप प्रदान करते हैं, लेकिन यह कहीं भी उतना मजबूत नहीं है जितना कि, वर्चुअल मशीन प्रदान करते हैं। संक्षेप में, एक कंटेनर में एक प्रक्रिया होस्ट ऑपरेटिंग सिस्टम पर चलने वाली एक ही प्रक्रिया है।

यह एक सुरक्षा समस्या हो सकती है: यह संगठन सैद्धांतिक रूप से असंबंधित अनुप्रयोगों को एक दूसरे के साथ संवाद करने की अनुमति देता है (जानबूझकर या गलती से)।

इसके अलावा, कुबेरनेट्स क्लस्टर में सभी वर्कलोड कुछ क्लस्टर-व्यापी सेवाओं को साझा करते हैं जैसे डीएनएस - यह एप्लिकेशन को क्लस्टर में अन्य एप्लिकेशन की सेवाएं खोजने की अनुमति देता है।

एप्लिकेशन सुरक्षा आवश्यकताओं के आधार पर उपरोक्त सभी बिंदुओं के अलग-अलग अर्थ हो सकते हैं।

सुरक्षा मुद्दों को रोकने के लिए कुबेरनेट्स विभिन्न उपकरण प्रदान करता है जैसे पॉड सुरक्षा नीतियां и नेटवर्क नीतियां. हालाँकि, उन्हें ठीक से कॉन्फ़िगर करने के लिए कुछ अनुभव की आवश्यकता होती है, और वे सभी सुरक्षा छेदों को बंद करने में सक्षम नहीं होते हैं।

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

- हार्ड मल्टी-टेनेंसी का अभाव

कुबेरनेट्स क्लस्टर में साझा संसाधनों की प्रचुरता को देखते हुए, ऐसे कई तरीके हैं जिनसे विभिन्न एप्लिकेशन एक दूसरे के पैर की उंगलियों पर कदम रख सकते हैं।

उदाहरण के लिए, एक एप्लिकेशन एक साझा संसाधन (जैसे एक प्रोसेसर या मेमोरी) पर एकाधिकार कर सकता है और उसी होस्ट एक्सेस पर चल रहे अन्य एप्लिकेशन को इससे वंचित कर सकता है।

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

- बड़ी संख्या में उपयोगकर्ता

एकल क्लस्टर के मामले में, आपको कई लोगों तक इसकी पहुंच खोलनी होगी। और उनकी संख्या जितनी बड़ी होगी, उतना ही अधिक जोखिम होगा कि वे कुछ "तोड़" देंगे।

क्लस्टर के अंदर, आप यह नियंत्रित कर सकते हैं कि कौन किसके साथ क्या कर सकता है रोल-बेस्ड एक्सेस कंट्रोल (RBAC) (लेख देखें " Kubernetes में उपयोगकर्ता और प्राधिकरण RBAC "- लगभग। अनुवाद।). हालांकि, यह उपयोगकर्ताओं को उनकी जिम्मेदारी के क्षेत्र में कुछ "तोड़ने" से नहीं रोकेगा।

- क्लस्टर अनिश्चित काल तक नहीं बढ़ सकते

सभी वर्कलोड के लिए उपयोग किया जाने वाला क्लस्टर काफी बड़ा हो सकता है (नोड्स और पॉड की संख्या के संदर्भ में)।

लेकिन यहाँ एक और समस्या उत्पन्न होती है: कुबेरनेट्स में क्लस्टर अनिश्चित काल तक नहीं बढ़ सकते।

क्लस्टर आकार पर एक सैद्धांतिक सीमा है। कुबेरनेट्स में, यह लगभग है 5000 नोड्स, 150k पॉड और 300k कंटेनर.

हालाँकि, वास्तविक जीवन में, समस्याएँ बहुत पहले शुरू हो सकती हैं - उदाहरण के लिए, जब 500 समुद्री मील.

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

इस मुद्दे को मूल ब्लॉग "शीर्षक" पर संबंधित लेख में खोजा गया है।कुबेरनेट्स समूहों की वास्तुकला - एक कार्यकर्ता नोड आकार चुनना'.

लेकिन इसके विपरीत दृष्टिकोण पर विचार करें: कई छोटे समूह।

2. कई छोटे, विशेष समूह

इस दृष्टिकोण के साथ, आप अपने द्वारा परिनियोजित प्रत्येक आइटम के लिए एक अलग क्लस्टर का उपयोग करते हैं:

कई छोटे समूह

इस लेख के प्रयोजनों के तहत तैनात करने योग्य तत्व एप्लिकेशन के एक उदाहरण के रूप में समझा जाता है - उदाहरण के लिए, एक अलग एप्लिकेशन का देव संस्करण।

इस रणनीति में, कुबेरनेट्स को एक विशेषज्ञ के रूप में उपयोग किया जाता है क्रम व्यक्तिगत आवेदन उदाहरणों के लिए।

आइए इस दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

+ सीमित "विस्फोट त्रिज्या"

जब एक क्लस्टर "टूट" जाता है, तो नकारात्मक परिणाम केवल उन वर्कलोड तक सीमित होते हैं जो इस क्लस्टर में तैनात किए गए थे। अन्य सभी कार्यभार अछूते रहते हैं।

+ इन्सुलेशन

अलग-अलग समूहों में होस्ट किए गए वर्कलोड सामान्य संसाधनों जैसे प्रोसेसर, मेमोरी, ऑपरेटिंग सिस्टम, नेटवर्क या अन्य सेवाओं को साझा नहीं करते हैं।

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

+ कम संख्या में उपयोगकर्ता

यह देखते हुए कि प्रत्येक क्लस्टर में केवल वर्कलोड का एक सीमित सेट होता है, इसे एक्सेस करने वाले उपयोगकर्ताओं की संख्या कम हो जाती है।

क्लस्टर तक जितने कम लोगों की पहुंच होगी, जोखिम उतना ही कम होगा कि कुछ "टूट" जाएगा।

आइए विपक्ष को देखें।

- संसाधनों का अकुशल उपयोग

जैसा कि पहले उल्लेख किया गया है, प्रत्येक कुबेरनेट्स क्लस्टर को प्रबंधन संसाधनों के एक निश्चित सेट की आवश्यकता होती है: मास्टर नोड्स, नियंत्रण परत घटक, निगरानी और लॉगिंग समाधान।

बड़ी संख्या में छोटे समूहों के मामले में, संसाधनों का एक बड़ा हिस्सा प्रबंधन को आवंटित किया जाना चाहिए।

- महँगा

संसाधनों का अकुशल उपयोग स्वचालित रूप से उच्च लागतों पर जोर देता है।

उदाहरण के लिए, समान कंप्यूटिंग शक्ति के साथ तीन के बजाय 30 मास्टर्नोड्स को बनाए रखना निश्चित रूप से लागत को प्रभावित करेगा।

- प्रशासन की कठिनाइयाँ

एकाधिक कुबेरनेट समूहों का प्रबंधन एक को प्रबंधित करने की तुलना में कहीं अधिक कठिन है।

उदाहरण के लिए, आपको प्रत्येक क्लस्टर के लिए प्रमाणीकरण और प्राधिकरण को कॉन्फ़िगर करना होगा। कुबेरनेट्स संस्करण का उन्नयन भी कई बार करना होगा।

सबसे अधिक संभावना है, आपको इन सभी कार्यों की दक्षता बढ़ाने के लिए स्वचालन लागू करने की आवश्यकता होगी।

अब कम चरम स्थितियों पर विचार करें।

3. प्रति आवेदन एक क्लस्टर

इस दृष्टिकोण के साथ, आप किसी विशेष एप्लिकेशन के सभी उदाहरणों के लिए एक अलग क्लस्टर बनाते हैं:

क्लस्टर प्रति आवेदन

इस तरह सिद्धांत के सामान्यीकरण के रूप में माना जा सकता है "प्रति टीम अलग क्लस्टर” क्योंकि आमतौर पर इंजीनियरों की एक टीम एक या एक से अधिक अनुप्रयोगों के विकास में शामिल होती है।

आइए इस दृष्टिकोण के पेशेवरों और विपक्षों को देखें।

+ क्लस्टर को एप्लिकेशन के लिए अनुकूलित किया जा सकता है

यदि किसी एप्लिकेशन की विशेष आवश्यकताएं हैं, तो उन्हें अन्य क्लस्टर को प्रभावित किए बिना एक क्लस्टर में लागू किया जा सकता है।

ऐसी ज़रूरतों में जीपीयू वर्कर, कुछ सीएनआई प्लगइन्स, एक सर्विस मेश या कुछ अन्य सर्विस शामिल हो सकती हैं।

प्रत्येक क्लस्टर को उस पर चल रहे एप्लिकेशन के अनुरूप बनाया जा सकता है, जिसमें केवल वही हो जो आवश्यक हो।

- एक क्लस्टर में विभिन्न वातावरण

इस दृष्टिकोण का नुकसान यह है कि एक ही क्लस्टर में विभिन्न वातावरणों से आवेदन के उदाहरण एक साथ मौजूद हैं।

उदाहरण के लिए, किसी एप्लिकेशन का प्रोड संस्करण देव संस्करण के समान क्लस्टर पर चलता है। इसका मतलब यह भी है कि डेवलपर्स उसी क्लस्टर में काम करते हैं जो एप्लिकेशन के उत्पादन संस्करण के रूप में होता है।

यदि डेवलपर्स के कार्यों के कारण क्लस्टर विफल हो जाता है या देव संस्करण में गड़बड़ हो जाती है, तो ठेस संस्करण भी संभावित रूप से पीड़ित हो सकता है - इस दृष्टिकोण का एक बड़ा नुकसान।

और अंत में, हमारी सूची में अंतिम परिदृश्य।

4. प्रति पर्यावरण एक क्लस्टर

यह परिदृश्य प्रत्येक वातावरण के लिए एक अलग क्लस्टर के आवंटन के लिए प्रदान करता है:

प्रति वातावरण एक क्लस्टर

उदाहरण के लिए, आपके पास क्लस्टर हो सकते हैं देव, परीक्षण и ठेस, जिसमें आप उस एप्लिकेशन के सभी उदाहरण चलाएंगे जो किसी विशेष वातावरण के लिए अभिप्रेत हैं।

यहाँ इस दृष्टिकोण के पक्ष और विपक्ष हैं।

+ प्रोड-पर्यावरण का अलगाव

इस दृष्टिकोण के भीतर, सभी वातावरण एक दूसरे से अलग-थलग हैं। हालांकि, व्यवहार में, यह उत्पादन पर्यावरण के लिए विशेष रूप से महत्वपूर्ण है।

एप्लिकेशन के उत्पादन संस्करण अब इस बात से स्वतंत्र हैं कि अन्य समूहों और परिवेशों में क्या हो रहा है।

इस प्रकार, यदि विकास क्लस्टर में अचानक कोई समस्या उत्पन्न होती है, तो अनुप्रयोगों के ठेस संस्करण काम करना जारी रखेंगे जैसे कि कुछ भी नहीं हुआ था।

+ क्लस्टर को पर्यावरण के अनुकूल बनाया जा सकता है

प्रत्येक क्लस्टर को उसके पर्यावरण के अनुरूप बनाया जा सकता है। उदाहरण के लिए, आप यह कर सकते हैं:

• देव क्लस्टर में विकास और डिबगिंग के लिए उपकरण स्थापित करें;
• क्लस्टर पर टेस्ट फ्रेमवर्क और टूल्स इंस्टॉल करें परीक्षण;
• क्लस्टर में अधिक शक्तिशाली हार्डवेयर और नेटवर्क लिंक का उपयोग करें ठेस.

यह अनुप्रयोग विकास और संचालन दोनों की दक्षता में सुधार करता है।

+ उत्पादन क्लस्टर तक पहुंच को प्रतिबंधित करना

प्रोड क्लस्टर के साथ सीधे काम करने की आवश्यकता अक्सर उत्पन्न नहीं होती है, इसलिए आप उन लोगों के सर्कल को महत्वपूर्ण रूप से सीमित कर सकते हैं जिनके पास इसकी पहुंच है।

आप और भी आगे बढ़ सकते हैं और लोगों को इस क्लस्टर तक पहुंच से पूरी तरह वंचित कर सकते हैं, और एक स्वचालित सीआई / सीडी उपकरण का उपयोग करके सभी परिनियोजन कर सकते हैं। इस तरह का दृष्टिकोण मानवीय त्रुटियों के जोखिम को ठीक उसी जगह कम करेगा जहां यह सबसे अधिक प्रासंगिक है।

और अब विपक्ष के बारे में कुछ शब्द।

- अनुप्रयोगों के बीच अलगाव का अभाव

दृष्टिकोण का मुख्य नुकसान अनुप्रयोगों के बीच हार्डवेयर और संसाधन अलगाव की कमी है।

असंबद्ध अनुप्रयोग क्लस्टर संसाधनों को साझा करते हैं: सिस्टम कोर, प्रोसेसर, मेमोरी और कुछ अन्य सेवाएं।

जैसा कि पहले ही उल्लेख किया गया है, यह संभावित रूप से खतरनाक हो सकता है।

- एप्लिकेशन निर्भरताओं को स्थानीयकृत करने में असमर्थता

यदि आवेदन की विशेष आवश्यकताएं हैं, तो उन्हें सभी समूहों में संतुष्ट होना चाहिए।

उदाहरण के लिए, यदि किसी एप्लिकेशन को GPU की आवश्यकता है, तो प्रत्येक क्लस्टर में GPU के साथ कम से कम एक कार्यकर्ता होना चाहिए (भले ही यह केवल इस एप्लिकेशन द्वारा उपयोग किया जाता हो)।

नतीजतन, हम उच्च लागत और संसाधनों के अक्षम उपयोग का जोखिम उठाते हैं।

निष्कर्ष

यदि आपके पास अनुप्रयोगों का एक निश्चित सेट है, तो उन्हें कई बड़े समूहों या कई छोटे समूहों में रखा जा सकता है।

लेख विभिन्न दृष्टिकोणों के पेशेवरों और विपक्षों पर चर्चा करता है, जिसमें एक वैश्विक समूह से लेकर कई छोटे और अत्यधिक विशिष्ट हैं:

• एक बड़ा सामान्य समूह;
• कई छोटे अति विशिष्ट क्लस्टर;
• प्रति आवेदन एक क्लस्टर;
• प्रति पर्यावरण एक क्लस्टर।

तो आपको कौन सा तरीका चुनना चाहिए?

हमेशा की तरह, उत्तर उपयोग के मामले पर निर्भर करता है: आपको विभिन्न दृष्टिकोणों के पेशेवरों और विपक्षों को तौलना होगा और सबसे अच्छा विकल्प चुनना होगा।

हालाँकि, विकल्प ऊपर दिए गए उदाहरणों तक ही सीमित नहीं है - आप उनमें से किसी भी संयोजन का उपयोग कर सकते हैं!

उदाहरण के लिए, आप प्रत्येक टीम के लिए समूहों की एक जोड़ी व्यवस्थित कर सकते हैं: विकास के लिए एक क्लस्टर (जिसमें वातावरण होगा देव и परीक्षण) और के लिए एक क्लस्टर उत्पादन (जहां उत्पादन का माहौल होगा)।

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

पुनश्च

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

• «कुबेरनेट्स की समस्या निवारण के लिए एक विज़ुअल गाइड";
• «कुबेरनेट्स में लॉग इन करें (और न केवल) आज: उम्मीदें और वास्तविकता";
• «सर्विस मेश: हॉटेस्ट टेक्नोलॉजी के बारे में हर सॉफ्टवेयर इंजीनियर को क्या जानना चाहिए";
• «कुबेरनेट्स में सुरक्षा का एबीसी: प्रमाणीकरण, प्राधिकरण, लेखा परीक्षा'.

स्रोत: www.habr.com