कुबेरनेत्स सर्वोत्तम प्रथाओं। नाम के साथ कुबेरनेट्स संगठन

कुबेरनेत्स सर्वोत्तम प्रथाओं। छोटे कंटेनरों का निर्माण

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

आइए नज़र डालते हैं कि कैसे नामस्थान नाम कुबेरनेट्स संसाधन प्रबंधन को आसान बनाता है। तो क्या वास्तव में एक नामस्थान है? Namespace को आपके Kubernetes क्लस्टर के अंदर एक वर्चुअल क्लस्टर के रूप में सोचा जा सकता है। आपके पास एक ही कुबेरनेट क्लस्टर के भीतर एक से अलग कई नामस्थान हो सकते हैं। वे वास्तव में आपकी और आपकी टीमों को संगठन, सुरक्षा और यहां तक ​​कि सिस्टम प्रदर्शन में मदद कर सकते हैं।



अधिकांश कुबेरनेट वितरण पर, क्लस्टर "बॉक्स से बाहर" है, जिसमें "डिफ़ॉल्ट" नामक एक नाम स्थान है। वास्तव में तीन नामस्थान हैं जो कुबेरनेट्स के साथ काम कर रहे हैं: डिफ़ॉल्ट, क्यूब-सिस्टम, और क्यूब-पब्लिक। वर्तमान में, क्यूब-पब्लिक का उपयोग अक्सर नहीं किया जाता है।



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

इसलिए, आपको कई नामस्थान बनाने चाहिए और अपनी सेवाओं को प्रबंधनीय लिंक में विभाजित करने के लिए उनका उपयोग करना चाहिए। एकल कमांड के साथ एक नाम स्थान बनाया जा सकता है। अगर आप टेस्ट नाम की नेमस्पेस बनाना चाहते हैं, तो $ kubectl क्रिएट नेमस्पेस टेस्ट कमांड का उपयोग करें या सिर्फ एक YAML फाइल बनाएं और किसी अन्य Kubernetes रिसोर्स की तरह इसका उपयोग करें।



आप $ kubectl get namespace कमांड का उपयोग करके सभी नामस्थान देख सकते हैं।



इसके निष्पादन के बाद, आपको तीन अंतर्निहित नामस्थान और एक नया नामस्थान दिखाई देगा जिसे "परीक्षण" कहा जाता है। आइए फली बनाने के लिए एक साधारण YAML फाइल देखें। आप देख सकते हैं कि इसमें किसी नामस्थान का उल्लेख नहीं है।



यदि आप इस फ़ाइल को चलाने के लिए kubectl का उपयोग करते हैं, तो यह वर्तमान सक्रिय नामस्थान में mypod मॉड्यूल बनाएगा। जब तक आप इसे नहीं बदलेंगे, यह डिफ़ॉल्ट नाम स्थान होगा। कुबेरनेट्स को बताने के लिए 2 तरीके हैं जिसमें आप अपना संसाधन बनाना चाहते हैं। पहला तरीका संसाधन बनाते समय नेमस्पेस फ्लैग का उपयोग करना है।



दूसरा तरीका YAML घोषणा में नाम स्थान को निर्दिष्ट करना है।



यदि आप YAML में एक नाम स्थान निर्दिष्ट करते हैं, तो संसाधन हमेशा इस स्थान पर बनाया जाएगा। यदि आप नामस्थान ध्वज का उपयोग करते समय किसी भिन्न नाम स्थान का उपयोग करने का प्रयास करते हैं, तो कमांड विफल हो जाएगी। अब, यदि आप अपना पॉड खोजने की कोशिश करते हैं, तो आप ऐसा नहीं कर सकते।



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



बॉक्स से बाहर, आपके सक्रिय नाम स्थान को डिफ़ॉल्ट कहा जाता है। यदि आप संसाधन के YAML में नाम स्थान निर्दिष्ट नहीं करते हैं, तो सभी Kubernetes कमांड इस सक्रिय डिफ़ॉल्ट नाम का उपयोग करेंगे। दुर्भाग्य से, kubectl का उपयोग करके सक्रिय नामस्थान का प्रबंधन करने का प्रयास विफल हो सकता है। हालांकि, कुबेंस नामक एक बहुत अच्छा उपकरण है, जो इस प्रक्रिया को बहुत सरल करता है। जब आप कुबेंस कमांड चलाते हैं, तो आप हाइलाइट किए गए एक्टिव नेमस्पेस के साथ सभी नेमस्पेस को देखते हैं।



सक्रिय नामस्थान को परीक्षण नामस्थान पर स्विच करने के लिए, आप बस $ kubens परीक्षण कमांड चलाते हैं। यदि इसके बाद आप $ kubens कमांड को फिर से दर्ज करते हैं, तो आप देख सकते हैं कि एक नया सक्रिय नाम स्थान अब आवंटित किया गया है - परीक्षण।



इसका मतलब यह है कि आपको टेस्ट नेमस्पेस में पॉड को देखने के लिए नेमस्पेस फ्लैग की जरूरत नहीं है।



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

आमतौर पर, जब आपका एप्लिकेशन कुबेरनेट सेवा का उपयोग करना चाहता है, तो आप अंतर्निहित DNS खोज सेवा का उपयोग करते हैं और बस अपने आवेदन को सेवा का नाम देते हैं। हालाँकि, आप कई नामस्थानों में एक ही नाम के तहत एक सेवा बना सकते हैं, जो अमान्य है।



सौभाग्य से, DNS पते के विस्तारित रूप का उपयोग करके इसे आसानी से दरकिनार कर दिया जाता है। Kubernetes की सेवाएँ एक सामान्य DNS पैटर्न का उपयोग करके अपने समापन बिंदुओं को उजागर करती हैं। यह कुछ इस तरह दिखता है:



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



हालाँकि, यदि आपको किसी अन्य नामस्थान में सेवा का उपयोग करने की आवश्यकता है, तो बस सेवा का नाम प्लस नेमस्पेस नाम का उपयोग करें:



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



आप कनेक्ट करना चाहते हैं। ठेस नामस्थान में सेवा डेटाबेस के लिए, आप database.prod का उपयोग कर रहे हैं।



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

मुझसे अक्सर पूछा जाता है कि कितने नामस्थान बनाने की जरूरत है और किन उद्देश्यों के लिए? डेटा का एक प्रबंधित टुकड़ा क्या है?

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

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

मान लीजिए कि स्थितियां बदल गई हैं और अब आपके पास एक तेजी से बढ़ती टीम है जो एक साथ 10 से अधिक माइक्रोसॉर्क्स पर काम कर रही है। एक समय आता है जब आपको कई समूहों या नामस्थानों का उपयोग करने की आवश्यकता होती है, अलग से ठेस और देव के लिए। आप एक टीम को कई उपसमूहों में विभाजित कर सकते हैं ताकि उनमें से प्रत्येक के पास स्वयं के माइक्रोसेवाएं हों और इनमें से प्रत्येक टीम सॉफ्टवेयर के विकास और रिलीज की प्रक्रिया को सुविधाजनक बनाने के लिए अपने स्वयं के नाम स्थान का चयन कर सके।



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

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

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



प्रोग्रामर को मैन्युअल रूप से सेवाओं को तैनात नहीं करना चाहिए और ऐसे नामस्थानों तक पहुंच नहीं होनी चाहिए जो उन्हें चिंता न करें। इस स्तर पर, बिलिंग और संसाधन प्रबंधन प्रक्रियाओं को सरल बनाने के लिए, खराब कॉन्फ़िगर किए गए अनुप्रयोगों के "विस्फोट त्रिज्या" को कम करने के लिए कई समूहों का होना उचित है।

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

कुबेरनेत्स सर्वोत्तम प्रथाओं। Kubernetes Readiness और Liveness परीक्षणों के साथ व्यवहार्यता परीक्षण

विज्ञापन का एक सा :)

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

डेल R730xd एम्स्टर्डम में इक्विनिक्स टीयर IV डेटा सेंटर में 2 गुना सस्ता है? केवल हमारे पास 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV नीदरलैंड के 199 डॉलर में से है!डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $ 99 से! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग सी?