Kubernetes सर्वोत्तम पद्धती. नेमस्पेससह कुबर्नेट्सची संस्था

Kubernetes सर्वोत्तम पद्धती. लहान कंटेनर तयार करणे

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

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

बहुतेक Kubernetes वितरणांवर, क्लस्टर बॉक्समधून "डिफॉल्ट" नावाच्या नेमस्पेससह बाहेर येतो. प्रत्यक्षात तीन नेमस्पेस आहेत ज्यांच्याशी कुबर्नेट्स व्यवहार करते: डीफॉल्ट, क्युबे-सिस्टम आणि क्युबे-पब्लिक. सध्या, कुबे-पब्लिकचा वापर बर्याचदा केला जात नाही.

कुबे नेमस्पेस एकटे सोडणे ही चांगली कल्पना आहे, विशेषत: Google Kubernetes Engine सारख्या व्यवस्थापित प्रणालीवर. तुमच्या सेवा आणि ॲप्लिकेशन्स जेथे तयार केले जातात ते ठिकाण म्हणून ते "डीफॉल्ट" नेमस्पेस वापरते. कुबेरनेट्स वापरण्यासाठी बॉक्सच्या बाहेर कॉन्फिगर केले आहे आणि तुम्ही ते काढू शकत नाही याशिवाय यात काही विशेष नाही. हे प्रारंभ करण्यासाठी आणि कमी कार्यप्रदर्शन प्रणालीसाठी उत्तम आहे, परंतु मी मोठ्या उत्पादन प्रणालींवर डीफॉल्ट नेमस्पेस वापरण्याची शिफारस करणार नाही. नंतरच्या प्रकरणात, एक विकास कार्यसंघ सहजपणे दुसर्‍याचा कोड पुन्हा लिहू शकतो आणि दुसर्‍या संघाचे कार्य लक्षात न घेता खंडित करू शकतो.

म्हणून, तुम्ही एकाधिक नेमस्पेसेस तयार कराव्यात आणि त्यांचा वापर तुमच्या सेवा व्यवस्थापित करण्यायोग्य युनिट्समध्ये विभागण्यासाठी करा. एकाच कमांडने नेमस्पेस तयार करता येते. तुम्हाला चाचणी नावाचे नेमस्पेस तयार करायचे असल्यास, $ kubectl create namespace test ही कमांड वापरा किंवा फक्त YAML फाइल तयार करा आणि इतर कुबर्नेट्स रिसोर्सप्रमाणे वापरा.

तुम्ही $ kubectl get namespace कमांड वापरून सर्व नेमस्पेस पाहू शकता.

एकदा ते पूर्ण झाल्यावर, तुम्हाला तीन अंगभूत नेमस्पेस आणि "चाचणी" नावाची नवीन नेमस्पेस दिसेल. पॉड तयार करण्यासाठी एक साधी YAML फाईल पाहू. तुमच्या लक्षात येईल की नेमस्पेसचा उल्लेख नाही.

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

दुसरा मार्ग म्हणजे YAML घोषणेमध्ये नेमस्पेस निर्दिष्ट करणे.

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

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

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

सक्रिय नेमस्पेस चाचणी नेमस्पेसवर स्विच करण्यासाठी, तुम्ही फक्त $kubens चाचणी कमांड चालवा. तुम्ही $kubens कमांड पुन्हा चालवल्यास, तुम्हाला दिसेल की नवीन सक्रिय नेमस्पेस आता वाटप केले आहे - चाचणी.

याचा अर्थ चाचणी नेमस्पेसमध्ये पॉड पाहण्यासाठी तुम्हाला नेमस्पेस ध्वजाची आवश्यकता नाही.

अशा प्रकारे नेमस्पेस एकमेकांपासून लपलेली असतात, परंतु एकमेकांपासून वेगळी नसतात. एका नेमस्पेसमधील सेवा दुसर्‍या नेमस्पेसमधील सेवेशी अगदी सहज संवाद साधू शकते, जी सहसा खूप उपयुक्त असते. वेगवेगळ्या नेमस्पेसमध्ये संवाद साधण्याची क्षमता म्हणजे तुमच्या डेव्हलपरची सेवा दुसऱ्या डेव्हलपर्स टीमच्या सेवेशी वेगळ्या नेमस्पेसमध्ये संवाद साधू शकते.

सामान्यतः, जेव्हा तुमचा ॲप्लिकेशन कुबर्नेट्स सेवेत प्रवेश करू इच्छितो, तेव्हा तुम्ही अंगभूत DNS शोध सेवा वापरता आणि तुमच्या ॲप्लिकेशनला सेवेचे नाव देता. तथापि, असे करून, आपण एकाधिक नेमस्पेसेसमध्ये एकाच नावाने सेवा तयार करू शकता, जी स्वीकार्य नाही.

सुदैवाने, DNS पत्त्याचा विस्तारित फॉर्म वापरून हे करणे सोपे आहे. Kubernetes मधील सेवा सामान्य DNS टेम्पलेट वापरून त्यांचे अंतिम बिंदू उघड करतात. हे असे काहीतरी दिसते:

सामान्यतः, आपल्याला फक्त सेवेचे नाव आवश्यक आहे आणि DNS स्वयंचलितपणे पूर्ण पत्ता निर्धारित करेल.

तथापि, जर तुम्हाला वेगळ्या नेमस्पेसमध्ये सेवेमध्ये प्रवेश करण्याची आवश्यकता असेल, तर फक्त सेवा नाव आणि नेमस्पेस नाव वापरा:

उदाहरणार्थ, जर तुम्हाला चाचणी नेमस्पेसमधील सेवा डेटाबेसशी कनेक्ट करायचे असेल, तर तुम्ही डेटाबेस database.test पत्ता वापरू शकता.

तुम्हाला प्रोड नेमस्पेसमधील सर्व्हिस डेटाबेसशी कनेक्ट करायचे असल्यास, तुम्ही database.prod वापरता.

तुम्हाला नेमस्पेस अ‍ॅक्सेस खरोखरच वेगळे आणि प्रतिबंधित करायचे असल्यास, Kubernetes तुम्हाला Kubernetes नेटवर्क धोरणे वापरून हे करण्याची परवानगी देते. याबद्दल मी पुढच्या भागात बोलेन.

मला अनेकदा प्रश्न विचारला जातो की, मी किती नेमस्पेस तयार करावी आणि कोणत्या उद्देशाने? डेटाचा व्यवस्थापित भाग म्हणजे काय?

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

अशी कल्पना करा की तुम्ही एका छोट्या टीमचा भाग आहात जे 5-10 मायक्रोसर्व्हिसेस विकसित करण्यावर काम करत आहे आणि तुम्ही सर्व डेव्हलपरना एका खोलीत सहजपणे एकत्र करू शकता. या स्थितीत, सर्व उत्पादन सेवा डीफॉल्ट नेमस्पेसमध्ये चालवणे अर्थपूर्ण आहे. अर्थात, अधिक लवचिकतेसाठी, तुम्ही 2 नेमस्पेस वापरू शकता - prod आणि dev साठी स्वतंत्रपणे. आणि बहुधा, आपण Minikube सारखे काहीतरी वापरून आपल्या स्थानिक संगणकावर आपल्या विकासाची चाचणी करता.

समजा गोष्टी बदलल्या आहेत आणि आता तुमच्याकडे वेगाने वाढणारी टीम आहे जी एका वेळी 10 पेक्षा जास्त मायक्रो सर्व्हिसेसवर काम करत आहे. अशी वेळ येते जेव्हा प्रोड आणि डेव्हसाठी स्वतंत्रपणे अनेक क्लस्टर किंवा नेमस्पेस वापरणे आवश्यक असते. तुम्ही टीमला अनेक उप-संघांमध्ये विभाजित करू शकता जेणेकरून त्यांच्यापैकी प्रत्येकाची स्वतःची मायक्रोसर्व्हिसेस असेल आणि सॉफ्टवेअर डेव्हलपमेंट आणि रिलीझ व्यवस्थापित करण्याची प्रक्रिया सुलभ करण्यासाठी यापैकी प्रत्येक संघ स्वतःचे नेमस्पेस निवडू शकेल.

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

मोठ्या कंपन्यांमध्ये, विकासकांना सहसा माहित नसते की नक्की कोण काय काम करत आहे. कार्यसंघ सेवा करार वापरून संप्रेषण करतात किंवा सेवा जाळी तंत्रज्ञान वापरतात, जे नेटवर्कवर एक अमूर्त स्तर जोडते, जसे की Istio कॉन्फिगरेशन टूल. संपूर्ण स्टॅक स्थानिक पातळीवर चालवण्याचा प्रयत्न करणे केवळ शक्य नाही. मी Kubernetes वर Spinnaker सारखे सतत वितरण (CD) प्लॅटफॉर्म वापरण्याची शिफारस करतो. तर, असा एक मुद्दा येतो जिथे प्रत्येक कमांडला निश्चितपणे स्वतःच्या नेमस्पेसची आवश्यकता असते. प्रत्येक संघ देव वातावरण आणि उत्पादन वातावरणासाठी एकाधिक नेमस्पेस देखील निवडू शकतो.

शेवटी, अशा मोठ्या उद्योजक कंपन्या आहेत ज्यात विकासकांच्या एका गटाला इतर गटांच्या अस्तित्वाबद्दल देखील माहिती नसते. अशी कंपनी सामान्यतः तृतीय-पक्ष विकासकांना नियुक्त करू शकते जे चांगल्या-दस्तऐवजीकरण केलेल्या API द्वारे त्याच्याशी संवाद साधतात. अशा प्रत्येक गटामध्ये अनेक संघ आणि अनेक सूक्ष्म सेवा असतात. या प्रकरणात, मी पूर्वी बोललो त्या सर्व साधनांचा वापर करणे आवश्यक आहे.

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

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

Kubernetes सर्वोत्तम पद्धती. तत्परता आणि सजीवता चाचण्यांसह कुबर्नेट्स लाइव्हनेस प्रमाणित करणे

काही जाहिराती 🙂

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

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

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