🍨 👩🏾‍🎨 👇🏾 डिजाइनिंग कुबेरनेट क्लस्टर: कितने होने चाहिए? 👨🏼 😱 🕡

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

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

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

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

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

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

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

एक सॉफ्टवेयर निर्माता के रूप में, आप समानांतर में कई एप्लिकेशन विकसित और संचालित करने की संभावना रखते हैं।

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

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

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

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

प्रत्येक आवेदन उदाहरण एक स्व-निहित तैनाती इकाई है जिसे दूसरों से स्वतंत्र रूप से संचालित किया जा सकता है।

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

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

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

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

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

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

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

कई बड़े समूहों (बाईं तरफ) से लेकर कई छोटे वाले (दाईं ओर)

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

खैर, चलो शुरू हो जाओ!

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

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

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

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

Namespace'y Kubernetes, तार्किक रूप से क्लस्टर के एक दूसरे भाग को एक दूसरे से अलग करने की अनुमति देता है, ताकि इसका नाम स्पेस एप्लिकेशन के प्रत्येक उदाहरण के लिए उपयोग किया जा सके।

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

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

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

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

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

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

+ सस्ता

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

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

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

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

+ प्रभावी प्रशासन

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

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

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

और कई अन्य ...

एक क्लस्टर के मामले में, यह सब केवल एक बार करना होगा।

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

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

- असफलता की एक भी वजह

एकल क्लस्टर विफलता की स्थिति में , सभी कार्यभार तुरंत काम करना बंद कर देंगे !

कुछ गलत हो सकता है जब विकल्प के टन कर रहे हैं:

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

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

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

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

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

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

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

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

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

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

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

- तंग बहु का अभाव

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. कई छोटे, विशेष क्लस्टर

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

कई छोटे क्लस्टर

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

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

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

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

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

+ इन्सुलेशन

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

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

उपयोगकर्ताओं की छोटी संख्या

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

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

आइए विपक्ष पर नजर डालते हैं।

- संसाधनों का अक्षम उपयोग

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

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

- उच्च लागत

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

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

- प्रशासन की मुश्किलें

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

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

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

अब कम चरम परिदृश्य पर विचार करें।

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

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

क्लस्टर प्रति एप्लिकेशन

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

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

+ क्लस्टर आवेदन के लिए अनुकूलित किया जा सकता है

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

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

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

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

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

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

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

और अंत में, हमारी सूची की आखिरी स्क्रिप्ट।

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

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

पर्यावरण

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

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

+ ठंढे वातावरण का अलगाव

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

अनुप्रयोग के उत्पादन संस्करण अब अन्य समूहों और वातावरणों में क्या हो रहा है, उससे स्वतंत्र हैं।

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

+ क्लस्टर को पर्यावरण में समायोजित किया जा सकता है

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

देव क्लस्टर में विकास और डिबगिंग उपकरण स्थापित करें;
परीक्षण क्लस्टर में परीक्षण ढांचे और उपकरण स्थापित करें ;
ठेस क्लस्टर में अधिक शक्तिशाली उपकरण और नेटवर्क चैनल का उपयोग करें ।

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

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

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

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

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

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

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

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

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

- आवेदन निर्भरता को स्थानीय बनाने में असमर्थता

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

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

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

निष्कर्ष

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

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

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

तो, कौन सा दृष्टिकोण चुनना है?

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

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

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

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

पुनश्च

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

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