कुबर्नेट्स क्लस्टर्स डिझाइन करणे: किती असावेत?

नोंद. अनुवाद: ही सामग्री शैक्षणिक प्रकल्पातील आहे learnk8s Kubernetes-आधारित पायाभूत सुविधा डिझाइन करताना लोकप्रिय प्रश्नाचे उत्तर आहे. आम्हाला आशा आहे की प्रत्येक पर्यायाच्या साधक आणि बाधकांचे विस्तृत तपशीलवार वर्णन आपल्याला आपल्या प्रकल्पासाठी सर्वोत्तम निवड करण्यात मदत करेल.

TL; डॉ: वर्कलोड्सचा समान संच अनेक मोठ्या क्लस्टर्सवर (प्रत्येक क्लस्टरमध्ये मोठ्या संख्येने वर्कलोड्स असतील) किंवा अनेक छोट्यांवर (प्रत्येक क्लस्टरमध्ये थोड्या प्रमाणात लोडसह) चालवले जाऊ शकतात.

खाली एक सारणी आहे जी प्रत्येक पद्धतीच्या साधक आणि बाधकांचे मूल्यांकन करते:

कुबर्नेट्सचा वापर ॲप्लिकेशन्स चालवण्यासाठी प्लॅटफॉर्म म्हणून करतांना, पुष्कळदा अनेक मूलभूत प्रश्न क्लस्टर सेटअप करण्याच्या गुंतागुंतीबद्दल उद्भवतात:

• मी किती क्लस्टर्स वापरावे?
• मी त्यांना किती मोठे करावे?
• प्रत्येक क्लस्टरमध्ये काय समाविष्ट असावे?

या लेखात, मी प्रत्येक दृष्टिकोनाच्या साधक आणि बाधकांचे विश्लेषण करून या सर्व प्रश्नांची उत्तरे देण्याचा प्रयत्न करेन.

प्रश्नाचे विधान

सॉफ्टवेअर डेव्हलपर म्हणून, तुम्ही एकाच वेळी अनेक ॲप्लिकेशन विकसित आणि ऑपरेट करू शकता.

याव्यतिरिक्त, या अनुप्रयोगांची अनेक उदाहरणे वेगवेगळ्या वातावरणात चालण्याची शक्यता आहे - उदाहरणार्थ, हे असू शकतात देव, चाचणी и उन्नत.

परिणाम अनुप्रयोग आणि वातावरणाचा संपूर्ण मॅट्रिक्स आहे:

अनुप्रयोग आणि पर्यावरण

वरील उदाहरण 3 ऍप्लिकेशन्स आणि 3 वातावरणाचे प्रतिनिधित्व करते, परिणामी एकूण 9 संभाव्य पर्याय आहेत.

प्रत्येक ऍप्लिकेशन इन्स्टन्स एक स्वयंपूर्ण उपयोजन युनिट आहे जे इतरांसोबत स्वतंत्रपणे कार्य केले जाऊ शकते.

लक्षात ठेवा की अनुप्रयोग उदाहरण अनेकांचा समावेश असू शकतो घटक, जसे की फ्रंटएंड, बॅकएंड, डेटाबेस इ. मायक्रोसर्व्हिसेस ऍप्लिकेशनच्या बाबतीत, उदाहरणामध्ये सर्व मायक्रोसर्व्हिसेस समाविष्ट असतील.

परिणामी, कुबर्नेट्स वापरकर्त्यांना अनेक प्रश्न आहेत:

• सर्व ऍप्लिकेशन उदाहरणे एका क्लस्टरमध्ये ठेवली पाहिजेत?
• प्रत्येक अनुप्रयोग उदाहरणासाठी स्वतंत्र क्लस्टर असणे योग्य आहे का?
• किंवा कदाचित वरील पद्धतींचे संयोजन वापरले पाहिजे?

हे सर्व पर्याय बऱ्यापैकी व्यवहार्य आहेत, कारण कुबर्नेट्स ही एक लवचिक प्रणाली आहे जी वापरकर्त्याच्या क्षमतांवर मर्यादा घालत नाही.

येथे काही संभाव्य मार्ग आहेत:

• एक मोठा सामान्य क्लस्टर;
• अनेक लहान अत्यंत विशेष क्लस्टर्स;
• प्रति अर्ज एक क्लस्टर;
• प्रति वातावरण एक क्लस्टर.

खाली दर्शविल्याप्रमाणे, पहिल्या दोन पद्धती पर्यायांच्या स्केलच्या विरुद्ध टोकांवर आहेत:

काही मोठ्या क्लस्टर्सपासून (डावीकडे) अनेक लहान (उजवीकडे)

सर्वसाधारणपणे, जर नोड्स आणि पॉड्सची बेरीज जास्त असेल तर एक क्लस्टर दुसर्यापेक्षा "मोठा" मानला जातो. उदाहरणार्थ, 10 नोड्स आणि 100 पॉड्स असलेला क्लस्टर 1 नोड आणि 10 पॉड्स असलेल्या क्लस्टरपेक्षा मोठा आहे.

बरं, चला सुरुवात करूया!

1. एक मोठा सामान्य क्लस्टर

पहिला पर्याय म्हणजे सर्व वर्कलोड एका क्लस्टरमध्ये ठेवणे:

एक मोठा क्लस्टर

या दृष्टिकोनामध्ये, क्लस्टरचा वापर सार्वत्रिक म्हणून केला जातो पायाभूत सुविधा मंच — तुम्ही फक्त विद्यमान कुबर्नेट्स क्लस्टरमध्ये तुम्हाला आवश्यक असलेली प्रत्येक गोष्ट तैनात करता.

नेमस्पेसेस Kubernetes क्लस्टरच्या काही भागांना तार्किकदृष्ट्या एकमेकांपासून वेगळे करण्याची अनुमती देते, जेणेकरून प्रत्येक ऍप्लिकेशन उदाहरणाचे स्वतःचे नेमस्पेस असू शकते.

चला या दृष्टिकोनाचे फायदे आणि तोटे पाहू.

+ संसाधनांचा कार्यक्षम वापर

एकाच क्लस्टरसह, तुम्हाला कुबर्नेट्स क्लस्टर चालवण्यासाठी आणि व्यवस्थापित करण्यासाठी आवश्यक असलेल्या सर्व संसाधनांची फक्त एक प्रत हवी आहे.

उदाहरणार्थ, हे मास्टर नोड्ससाठी खरे आहे. सामान्यतः, प्रत्येक कुबर्नेट्स क्लस्टरमध्ये 3 मास्टर नोड्स असतात, त्यामुळे एका एकल क्लस्टरसाठी त्यांची संख्या तशीच राहील (तुलनेसाठी, 10 क्लस्टरला 30 मास्टर नोड्स आवश्यक असतील).

वरील सूक्ष्मता संपूर्ण क्लस्टरमध्ये कार्यरत असलेल्या इतर सेवांवर देखील लागू होते, जसे की लोड बॅलन्सर्स, इंग्रेस कंट्रोलर्स, प्रमाणीकरण, लॉगिंग आणि मॉनिटरिंग सिस्टम.

एकाच क्लस्टरमध्ये, या सर्व सेवा एकाच वेळी सर्व वर्कलोड्ससाठी वापरल्या जाऊ शकतात (त्याच्या प्रती तयार करण्याची आवश्यकता नाही, जसे अनेक क्लस्टर्सच्या बाबतीत आहे).

+ स्वस्त

वरील परिणाम म्हणून, कमी क्लस्टर्स सहसा स्वस्त असतात कारण कोणतेही ओव्हरहेड खर्च नसतात.

हे विशेषतः मास्टर नोड्ससाठी खरे आहे, ज्यांना ते कसे होस्ट केले जातात (ऑन-प्रिमाइसेस किंवा क्लाउडमध्ये) पर्वा न करता मोठ्या प्रमाणात पैसे खर्च होऊ शकतात.

काही व्यवस्थापित Kubernetes सेवा, जसे की Google Kubernetes Engine (GKE) किंवा Azure Kubernetes सेवा (AKS), नियंत्रण स्तर विनामूल्य प्रदान करा. या प्रकरणात, खर्च समस्या कमी तीव्र आहे.

अशा व्यवस्थापित सेवा देखील आहेत ज्या प्रत्येक कुबर्नेट्स क्लस्टरच्या ऑपरेशनसाठी निश्चित शुल्क आकारतात (उदाहरणार्थ, ऍमेझॉन लवचिक कुबर्नेट्स सेवा, ईकेएस).

+ कार्यक्षम प्रशासन

अनेक व्यवस्थापित करण्यापेक्षा एक क्लस्टर व्यवस्थापित करणे सोपे आहे.

प्रशासनात खालील कार्ये समाविष्ट असू शकतात:

• Kubernetes आवृत्ती अद्यतन;
• CI/CD पाइपलाइन सेट करणे;
• CNI प्लगइन स्थापित करणे;
• वापरकर्ता प्रमाणीकरण प्रणाली सेट करणे;
• ऍक्सेस कंट्रोलरची स्थापना;

आणि इतर अनेक…

एका क्लस्टरच्या बाबतीत, तुम्हाला हे सर्व एकदाच करावे लागेल.

बऱ्याच क्लस्टर्ससाठी, ऑपरेशन्सची अनेक वेळा पुनरावृत्ती करावी लागेल, ज्यासाठी प्रक्रियेत सुसंगतता आणि सुसंगतता सुनिश्चित करण्यासाठी प्रक्रिया आणि साधनांचे काही ऑटोमेशन आवश्यक असेल.

आणि आता बाधक बद्दल काही शब्द.

- अपयशाचा एकच मुद्दा

नकाराच्या बाबतीत फक्त एक क्लस्टर त्वरित कार्य करणे थांबवेल सर्व कामाचे ओझे!

गोष्टी चुकीच्या होऊ शकतात असे अनेक मार्ग आहेत:

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

अशा एका घटनेमुळे सामायिक क्लस्टरमध्ये होस्ट केलेल्या सर्व वर्कलोडचे गंभीर नुकसान होऊ शकते.

- कोणतेही कठोर इन्सुलेशन नाही

सामायिक क्लस्टरमध्ये चालणे म्हणजे अनुप्रयोग क्लस्टर नोड्सवर हार्डवेअर, नेटवर्किंग क्षमता आणि ऑपरेटिंग सिस्टम सामायिक करतात.

एका अर्थाने, एकाच नोडवर चालणारे दोन भिन्न ऍप्लिकेशन्स असलेले दोन कंटेनर समान OS कर्नलवर चालणाऱ्या एकाच मशीनवर चालणाऱ्या दोन प्रक्रियांसारखे आहेत.

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

ही सुरक्षा समस्या असू शकते: ही व्यवस्था सैद्धांतिकदृष्ट्या असंबंधित अनुप्रयोगांना एकमेकांशी संवाद साधण्याची परवानगी देते (एकतर हेतुपुरस्सर किंवा चुकून).

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

वरील सर्व मुद्द्यांचा अनुप्रयोग सुरक्षा आवश्यकतांवर अवलंबून भिन्न अर्थ असू शकतो.

कुबर्नेट्स सुरक्षा समस्या टाळण्यासाठी विविध साधने प्रदान करते जसे की PodSecurity Policies и नेटवर्क धोरणे. तथापि, त्यांना योग्यरित्या सेट करण्यासाठी काही अनुभव आवश्यक आहे; याव्यतिरिक्त, ते सर्व सुरक्षा छिद्र पूर्णपणे बंद करण्यास सक्षम नाहीत.

हे नेहमी लक्षात ठेवणे महत्त्वाचे आहे की कुबर्नेट्स मूळतः यासाठी डिझाइन केले गेले होते शेअरिंग, साठी नाही अलगाव आणि सुरक्षितता.

- कठोर मल्टी-टेनन्सीचा अभाव

कुबर्नेट्स क्लस्टरमध्ये सामायिक केलेल्या संसाधनांची मुबलकता लक्षात घेता, असे अनेक मार्ग आहेत की भिन्न अनुप्रयोग एकमेकांच्या पायावर पाऊल ठेवू शकतात.

उदाहरणार्थ, एखादे ॲप्लिकेशन शेअर केलेल्या संसाधनाची मक्तेदारी करू शकते (जसे की CPU किंवा मेमरी) आणि त्याच नोडवर चालणाऱ्या इतर ऍप्लिकेशन्सना त्यात प्रवेश नाकारू शकतो.

कुबर्नेट्स हे वर्तन नियंत्रित करण्यासाठी विविध यंत्रणा प्रदान करते, जसे की संसाधन विनंत्या आणि मर्यादा (लेख देखील पहा " CPU मर्यादा आणि Kubernetes मध्ये आक्रमक थ्रॉटलिंग "- अंदाजे. अनुवाद.), संसाधन कोटा и मर्यादा रेंज. तथापि, सुरक्षिततेच्या बाबतीत, त्यांचे कॉन्फिगरेशन अगदीच क्षुल्लक आहे आणि ते पूर्णपणे सर्व अनपेक्षित दुष्परिणाम टाळण्यास सक्षम नाहीत.

- मोठ्या संख्येने वापरकर्ते

एकाच क्लस्टरच्या बाबतीत, तुम्हाला त्यात अनेक लोकांसाठी प्रवेश खुला करावा लागेल. आणि त्यांची संख्या जितकी जास्त असेल तितका धोका जास्त असेल की ते काहीतरी "ब्रेक" करतील.

क्लस्टरमध्ये तुम्ही काय वापरून कोण करू शकते हे नियंत्रित करू शकता भूमिका-आधारित प्रवेश नियंत्रण (RBAC) (लेख पहा " Kubernetes मध्ये वापरकर्ते आणि अधिकृतता RBAC "- अंदाजे. अनुवाद.). तथापि, ते वापरकर्त्यांना त्यांच्या जबाबदारीच्या क्षेत्राच्या मर्यादेत काहीतरी "ब्रेक" करण्यापासून प्रतिबंधित करणार नाही.

- क्लस्टर्स अनिश्चित काळासाठी वाढू शकत नाहीत

सर्व वर्कलोड्ससाठी वापरला जाणारा क्लस्टर बहुधा मोठा असेल (नोड्स आणि पॉड्सच्या संख्येनुसार).

परंतु येथे आणखी एक समस्या उद्भवते: कुबर्नेट्समधील क्लस्टर्स अनिश्चित काळासाठी वाढू शकत नाहीत.

क्लस्टर आकारावर एक सैद्धांतिक मर्यादा आहे. Kubernetes मध्ये ते अंदाजे आहे 5000 नोड, 150 हजार शेंगा आणि 300 हजार कंटेनर.

तथापि, वास्तविक जीवनात, समस्या खूप पूर्वी सुरू होऊ शकतात - उदाहरणार्थ, फक्त सह 500 नॉट्स.

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

मूळ ब्लॉगवरील संबंधित लेखात या समस्येचा शोध घेतला आहे "Kubernetes क्लस्टर्सची रचना करणे — वर्कर नोड आकार निवडणे».

परंतु उलट दृष्टिकोन विचारात घेऊया: अनेक लहान क्लस्टर्स.

2. अनेक लहान, विशेष क्लस्टर्स

या दृष्टिकोनासह, तुम्ही तैनात करता त्या प्रत्येक घटकासाठी तुम्ही स्वतंत्र क्लस्टर वापरता:

अनेक लहान क्लस्टर्स

या लेखाच्या हेतूंसाठी, अंतर्गत उपयोज्य घटक अनुप्रयोगाच्या उदाहरणाचा संदर्भ देते - उदाहरणार्थ, वेगळ्या अनुप्रयोगाची डेव्ह आवृत्ती.

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

चला या दृष्टिकोनाचे फायदे आणि तोटे पाहू.

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

जेव्हा क्लस्टर अयशस्वी होतो, तेव्हा नकारात्मक परिणाम केवळ त्या क्लस्टरमध्ये तैनात केलेल्या वर्कलोड्सपुरते मर्यादित असतात. इतर सर्व वर्कलोड अस्पर्शित राहतात.

+ इन्सुलेशन

वैयक्तिक क्लस्टर्समध्ये होस्ट केलेले वर्कलोड प्रोसेसर, मेमरी, ऑपरेटिंग सिस्टम, नेटवर्क किंवा इतर सेवा यासारखी संसाधने शेअर करत नाहीत.

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

+ वापरकर्त्यांची कमी संख्या

प्रत्येक क्लस्टरमध्ये वर्कलोडचा केवळ मर्यादित संच असतो हे लक्षात घेता, त्यात प्रवेश असलेल्या वापरकर्त्यांची संख्या कमी झाली आहे.

क्लस्टरमध्ये जितक्या कमी लोकांना प्रवेश असेल, काहीतरी "ब्रेक" होण्याची जोखीम कमी होईल.

चला तोटे पाहू.

- संसाधनांचा अकार्यक्षम वापर

आधी सांगितल्याप्रमाणे, प्रत्येक कुबर्नेट्स क्लस्टरला व्यवस्थापन संसाधनांचा विशिष्ट संच आवश्यक असतो: मास्टर नोड्स, कंट्रोल लेयर घटक, मॉनिटरिंग आणि लॉगिंग सोल्यूशन्स.

मोठ्या संख्येने लहान क्लस्टर्सच्या बाबतीत, संसाधनांचा मोठा वाटा व्यवस्थापनाला वाटप करणे आवश्यक आहे.

- महाग

संसाधनांच्या अकार्यक्षम वापरामुळे आपोआप उच्च खर्च येतो.

उदाहरणार्थ, समान संगणन शक्तीसह तीन ऐवजी 30 मास्टर नोड्स राखणे अनिवार्यपणे खर्चावर परिणाम करेल.

- प्रशासनात अडचणी

एकाधिक कुबर्नेट्स क्लस्टर्स व्यवस्थापित करणे फक्त एक व्यवस्थापित करण्यापेक्षा खूप कठीण आहे.

उदाहरणार्थ, तुम्हाला प्रत्येक क्लस्टरसाठी प्रमाणीकरण आणि अधिकृतता कॉन्फिगर करावी लागेल. Kubernetes आवृत्ती देखील अनेक वेळा अद्यतनित करावी लागेल.

ही सर्व कार्ये अधिक कार्यक्षम करण्यासाठी तुम्हाला कदाचित ऑटोमेशन वापरण्याची आवश्यकता असेल.

आता कमी टोकाची परिस्थिती पाहू.

3. प्रति अर्ज एक क्लस्टर

या दृष्टिकोनामध्ये, तुम्ही विशिष्ट अनुप्रयोगाच्या सर्व उदाहरणांसाठी स्वतंत्र क्लस्टर तयार करता:

प्रति अर्ज क्लस्टर

हा मार्ग तत्त्वाचे सामान्यीकरण म्हणून मानले जाऊ शकते "प्रत्येक संघासाठी स्वतंत्र क्लस्टर", कारण सामान्यतः अभियंत्यांची एक टीम एक किंवा अधिक अनुप्रयोग विकसित करत असते.

चला या दृष्टिकोनाचे फायदे आणि तोटे पाहू.

+ क्लस्टर ऍप्लिकेशनमध्ये समायोजित केले जाऊ शकते

एखाद्या अनुप्रयोगाला विशेष गरजा असल्यास, ते इतर क्लस्टरवर परिणाम न करता क्लस्टरमध्ये लागू केले जाऊ शकतात.

अशा गरजांमध्ये GPU कामगार, विशिष्ट CNI प्लगइन, सेवा जाळी किंवा इतर काही सेवा समाविष्ट असू शकतात.

प्रत्येक क्लस्टरमध्ये चालत असलेल्या ऍप्लिकेशननुसार तयार केले जाऊ शकते जेणेकरून त्यात फक्त आवश्यक तेच समाविष्ट असेल.

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

या दृष्टिकोनाचा तोटा असा आहे की वेगवेगळ्या वातावरणातील अनुप्रयोग उदाहरणे एकाच क्लस्टरमध्ये एकत्र असतात.

उदाहरणार्थ, ॲप्लिकेशनची प्रोड आवृत्ती dev आवृत्ती सारख्याच क्लस्टरमध्ये चालते. याचा अर्थ असा की विकासक त्याच क्लस्टरमध्ये कार्य करतात ज्यामध्ये अनुप्रयोगाची उत्पादन आवृत्ती ऑपरेट केली जाते.

जर, डेव्हलपरच्या कृतींमुळे किंवा डेव्ह व्हर्जनमधील त्रुटींमुळे, क्लस्टरमध्ये बिघाड झाला, तर प्रोड व्हर्जनलाही याचा त्रास होऊ शकतो - या दृष्टिकोनाचा एक मोठा दोष.

आणि शेवटी, आमच्या यादीतील शेवटची परिस्थिती.

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

या परिस्थितीमध्ये प्रत्येक वातावरणासाठी स्वतंत्र क्लस्टर वाटप करणे समाविष्ट आहे:

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

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

या दृष्टिकोनाचे साधक आणि बाधक येथे आहेत.

+ उत्पादन वातावरणाचे अलगाव

या दृष्टिकोनामध्ये, सर्व वातावरण एकमेकांपासून वेगळे केले जातात. तथापि, सराव मध्ये हे उत्पादन वातावरणात विशेषतः महत्वाचे आहे.

अनुप्रयोगाच्या उत्पादन आवृत्त्या आता इतर क्लस्टर्स आणि वातावरणात काय घडत आहे त्यापेक्षा स्वतंत्र आहेत.

अशा प्रकारे, dev क्लस्टरमध्ये अचानक समस्या उद्भवल्यास, अनुप्रयोगांच्या प्रोड आवृत्त्या काही घडलेच नसल्याप्रमाणे कार्य करत राहतील.

+ क्लस्टर वातावरणात समायोजित केले जाऊ शकते

प्रत्येक क्लस्टर त्याच्या वातावरणात समायोजित केले जाऊ शकते. उदाहरणार्थ, तुम्ही हे करू शकता:

• डेव्हलपमेंट आणि डीबगिंगसाठी dev क्लस्टरमध्ये साधने स्थापित करा;
• क्लस्टरमध्ये चाचणी फ्रेमवर्क आणि साधने स्थापित करा चाचणी;
• क्लस्टरमध्ये अधिक शक्तिशाली हार्डवेअर आणि नेटवर्क चॅनेल वापरा उन्नत.

हे तुम्हाला ऍप्लिकेशन डेव्हलपमेंट आणि ऑपरेशन दोन्हीची कार्यक्षमता वाढविण्यास अनुमती देते.

+ उत्पादन क्लस्टरमध्ये प्रवेश प्रतिबंधित करणे

प्रॉड क्लस्टरसह थेट कार्य करण्याची आवश्यकता क्वचितच उद्भवते, म्हणून आपण त्यात प्रवेश असलेल्या लोकांच्या वर्तुळात लक्षणीय मर्यादा घालू शकता.

तुम्ही आणखी पुढे जाऊ शकता आणि लोकांना या क्लस्टरमध्ये प्रवेश नाकारू शकता आणि स्वयंचलित CI/CD टूल वापरून सर्व डिप्लॉयमेंट करू शकता. असा दृष्टीकोन मानवी चुकांचा धोका कमी करेल जिथे तो सर्वात संबंधित आहे.

आणि आता बाधक बद्दल काही शब्द.

- अनुप्रयोगांमध्ये वेगळेपणा नाही

दृष्टिकोनाचा मुख्य तोटा म्हणजे हार्डवेअरची कमतरता आणि अनुप्रयोगांमधील संसाधन अलग ठेवणे.

असंबंधित अनुप्रयोग क्लस्टर संसाधने सामायिक करतात: सिस्टम कोर, प्रोसेसर, मेमरी आणि काही इतर सेवा.

नमूद केल्याप्रमाणे, हे संभाव्य धोकादायक असू शकते.

- अनुप्रयोग अवलंबित्व स्थानिकीकरण करण्यास असमर्थता

जर एखाद्या ऍप्लिकेशनला विशेष आवश्यकता असतील, तर ते सर्व क्लस्टरमध्ये समाधानी असले पाहिजेत.

उदाहरणार्थ, जर एखाद्या ऍप्लिकेशनला GPU आवश्यक असेल, तर प्रत्येक क्लस्टरमध्ये GPU असलेला किमान एक कार्यकर्ता असणे आवश्यक आहे (जरी तो फक्त त्या ऍप्लिकेशनद्वारे वापरला जात असेल).

परिणामी, आम्हाला जास्त खर्च आणि संसाधनांचा अकार्यक्षम वापर धोका असतो.

निष्कर्ष

तुमच्याकडे ऍप्लिकेशन्सचा विशिष्ट संच असल्यास, ते अनेक मोठ्या क्लस्टर्समध्ये किंवा अनेक छोट्या क्लस्टरमध्ये ठेवता येतात.

लेख विविध दृष्टिकोनांच्या साधक आणि बाधकांची चर्चा करतो, एका जागतिक क्लस्टरपासून ते अनेक लहान आणि अत्यंत विशिष्ट गोष्टींपर्यंत:

• एक मोठा सामान्य क्लस्टर;
• अनेक लहान अत्यंत विशेष क्लस्टर्स;
• प्रति अर्ज एक क्लस्टर;
• प्रति वातावरण एक क्लस्टर.

तर तुम्ही कोणता दृष्टिकोन घ्यावा?

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

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

उदाहरणार्थ, तुम्ही प्रत्येक संघासाठी दोन क्लस्टर्स आयोजित करू शकता: एक विकास क्लस्टर (ज्यामध्ये वातावरण असेल देव и चाचणी) आणि क्लस्टर साठी उत्पादन (जेथे उत्पादन वातावरण असेल).

या लेखातील माहितीच्या आधारे, तुम्ही विशिष्ट परिस्थितीनुसार साधक आणि बाधकांना अनुकूल करू शकता. शुभेच्छा!

PS

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्सच्या समस्यानिवारणासाठी व्हिज्युअल मार्गदर्शक";
• «कुबर्नेट्स (आणि फक्त नाही) आज लॉग इन करा: अपेक्षा आणि वास्तव";
• «सेवा जाळी: प्रत्येक सॉफ्टवेअर अभियंत्यांना सर्वात लोकप्रिय तंत्रज्ञानाबद्दल काय माहित असणे आवश्यक आहे";
• «द एबीसी ऑफ सिक्युरिटी इन कुबर्नेट्स: ऑथेंटिकेशन, ऑथरायझेशन, ऑडिटिंग».

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