🥇DEVOXX यूके। कुबेरनेट्स उत्पादन में: नीला/हरा परिनियोजन, ऑटोस्केलिंग और परिनियोजन स्वचालन। भाग 2

क्लस्टर्ड उत्पादन वातावरण में डॉकर कंटेनरों को चलाने के लिए कुबेरनेट्स एक बेहतरीन उपकरण है। हालाँकि, ऐसी समस्याएं हैं जिन्हें कुबेरनेट्स हल नहीं कर सकता है। लगातार उत्पादन परिनियोजन के लिए, प्रक्रिया में डाउनटाइम से बचने के लिए हमें पूरी तरह से स्वचालित ब्लू/ग्रीन परिनियोजन की आवश्यकता होती है, जिसे बाहरी HTTP अनुरोधों को संभालने और एसएसएल ऑफलोड करने की भी आवश्यकता होती है। इसके लिए हा-प्रॉक्सी जैसे लोड बैलेंसर के साथ एकीकरण की आवश्यकता होती है। एक अन्य चुनौती क्लाउड वातावरण में चलते समय कुबेरनेट्स क्लस्टर की अर्ध-स्वचालित स्केलिंग है, उदाहरण के लिए रात में क्लस्टर को आंशिक रूप से छोटा करना।

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

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

डेवॉक्स यूके। कुबेरनेट्स उत्पादन में: नीला/हरा परिनियोजन, ऑटोस्केलिंग और परिनियोजन स्वचालन। भाग 1

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

कुबेरनेट्स एक ऐसा उपकरण नहीं है जिसका उपयोग बॉक्स से बाहर उत्पादक रूप से किया जा सकता है। बेशक, आप ऐसा कर सकते हैं, कुबेक्टल आदि का उपयोग कर सकते हैं, लेकिन फिर भी एपीआई इस प्लेटफ़ॉर्म के बारे में सबसे दिलचस्प और उपयोगी चीज़ है। फ़ंक्शन के एक सेट के रूप में एपीआई का उपयोग करके, आप कुबेरनेट्स में लगभग कुछ भी जो आप करना चाहते हैं, उस तक पहुंच सकते हैं। Kubectl स्वयं भी REST API का उपयोग करता है।

यह REST है, इसलिए आप इस API के साथ काम करने के लिए किसी भी भाषा या टूल का उपयोग कर सकते हैं, लेकिन कस्टम लाइब्रेरीज़ द्वारा आपका जीवन बहुत आसान बना दिया जाएगा। मेरी टीम ने 2 ऐसी लाइब्रेरी लिखीं: एक जावा/ओएसजीआई के लिए और एक गो के लिए। दूसरे का उपयोग अक्सर नहीं किया जाता है, लेकिन किसी भी मामले में आपके पास ये उपयोगी चीजें हैं। वे आंशिक रूप से लाइसेंस प्राप्त ओपन-सोर्स प्रोजेक्ट हैं। विभिन्न भाषाओं के लिए ऐसी कई लाइब्रेरी हैं, इसलिए आप वह चुन सकते हैं जो आपके लिए सबसे उपयुक्त हो।

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

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

नीला/हरा परिनियोजन तंत्र इस तरह दिखता है। हम हा-प्रॉक्सी के माध्यम से अपने एप्लिकेशन के लिए ट्रैफ़िक प्राप्त करते हैं, जो इसे उसी संस्करण के एप्लिकेशन की चल रही प्रतिकृतियों को अग्रेषित करता है।

जब कोई नई तैनाती की जाती है, तो हम डिप्लॉयर का उपयोग करते हैं, जिसे नए घटक दिए जाते हैं और नया संस्करण तैनात किया जाता है। किसी एप्लिकेशन के नए संस्करण को तैनात करने का मतलब है कि प्रतिकृतियों का एक नया सेट "उठाया" जाता है, जिसके बाद नए संस्करण की इन प्रतिकृतियों को एक अलग, नए पॉड में लॉन्च किया जाता है। हालाँकि, हा-प्रॉक्सी उनके बारे में कुछ नहीं जानता है और अभी तक उन पर कोई कार्यभार नहीं भेजता है।

इसलिए, सबसे पहले, यह सुनिश्चित करने के लिए स्वास्थ्य जांच के नए संस्करणों की प्रदर्शन जांच करना आवश्यक है कि प्रतिकृतियां लोड को पूरा करने के लिए तैयार हैं।

सभी परिनियोजन घटकों को किसी न किसी प्रकार की स्वास्थ्य जांच का समर्थन करना चाहिए। यह एक बहुत ही सरल HTTP कॉल जांच हो सकती है, जब आपको स्टेटस 200 के साथ एक कोड प्राप्त होता है, या अधिक गहन जांच होती है, जिसमें आप डेटाबेस और अन्य सेवाओं के साथ प्रतिकृतियों के कनेक्शन, गतिशील वातावरण कनेक्शन की स्थिरता की जांच करते हैं , और क्या सब कुछ शुरू होता है और सही ढंग से काम करता है। यह प्रक्रिया काफी जटिल हो सकती है.

सिस्टम द्वारा यह सत्यापित करने के बाद कि सभी अपडेट की गई प्रतिकृतियां काम कर रही हैं, डिप्लॉयर कॉन्फ़िगरेशन को अपडेट करेगा और सही कॉन्फ़िड पास करेगा, जो हा-प्रॉक्सी को फिर से कॉन्फ़िगर करेगा।

इसके बाद ही ट्रैफ़िक को नए संस्करण की प्रतिकृतियों वाले पॉड की ओर निर्देशित किया जाएगा और पुराना पॉड गायब हो जाएगा।

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

अब मैं आपको एक नए परिनियोजन घटक - डिप्लॉयर से परिचित कराऊंगा, जो स्वास्थ्य जांच करता है, प्रॉक्सी को पुन: कॉन्फ़िगर करता है, इत्यादि। यह एक अवधारणा है जो बाहरी दुनिया पर लागू नहीं होती है और कुबेरनेट्स के अंदर मौजूद है। मैं आपको दिखाऊंगा कि आप ओपन-सोर्स टूल का उपयोग करके अपनी खुद की डिप्लॉयर अवधारणा कैसे बना सकते हैं।

तो, पहली चीज़ जो डिप्लॉयर करता है वह कुबेरनेट्स एपीआई का उपयोग करके एक आरसी प्रतिकृति नियंत्रक बनाता है। यह एपीआई आगे की तैनाती के लिए पॉड्स और सेवाएं बनाता है, यानी यह हमारे अनुप्रयोगों के लिए एक पूरी तरह से नया क्लस्टर बनाता है। जैसे ही आरसी आश्वस्त हो जाएगी कि प्रतिकृतियां बननी शुरू हो गई हैं, वह उनकी कार्यक्षमता की स्वास्थ्य जांच करेगा। ऐसा करने के लिए, डिप्लॉयर GET /health कमांड का उपयोग करता है। यह उपयुक्त स्कैन घटकों को चलाता है और क्लस्टर के संचालन का समर्थन करने वाले सभी तत्वों की जांच करता है।

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

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

जैसा कि आप देख सकते हैं, घटकों की प्रचुरता के बावजूद, यहां कुछ भी जटिल नहीं है। आपको बस एपीआई और आदि पर अधिक ध्यान देने की जरूरत है। मैं आपको उस ओपन-सोर्स डिप्लॉयर के बारे में बताना चाहता हूं जिसका हम स्वयं उपयोग करते हैं - अमदातु कुबेरनेट्स डिप्लॉयर।

यह कुबेरनेट्स परिनियोजन को व्यवस्थित करने के लिए एक उपकरण है और इसमें निम्नलिखित विशेषताएं हैं:

नीला/हरा परिनियोजन;
एक बाहरी लोड बैलेंसर स्थापित करना;
परिनियोजन विवरणक प्रबंधन;
वास्तविक तैनाती का प्रबंधन करना;
तैनाती के दौरान स्वास्थ्य जांच की कार्यक्षमता की जाँच करना;
पॉड्स में पर्यावरण चर का कार्यान्वयन।

यह डिप्लॉयर Kubernetes API के शीर्ष पर बनाया गया है और हैंडल और परिनियोजन के प्रबंधन के लिए एक REST API, साथ ही परिनियोजन प्रक्रिया के दौरान स्ट्रीमिंग लॉग के लिए एक Websocket API प्रदान करता है।

यह लोड बैलेंसर कॉन्फ़िगरेशन डेटा को आदि में डालता है, इसलिए आपको आउट-ऑफ़-द-बॉक्स समर्थन के साथ हा-प्रॉक्सी का उपयोग करने की आवश्यकता नहीं है, लेकिन आसानी से अपनी स्वयं की लोड बैलेंसर कॉन्फ़िगरेशन फ़ाइल का उपयोग करें। अमदातु डिप्लॉयर को कुबेरनेट्स की तरह ही गो में लिखा गया है, और इसे अपाचे द्वारा लाइसेंस प्राप्त है।

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

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

एक अन्य उपकरण जो ओपन-सोर्स Amdatu प्रोजेक्ट का हिस्सा है, वह है Deploymentctl। इसमें परिनियोजन कॉन्फ़िगर करने के लिए एक यूआई है, परिनियोजन इतिहास संग्रहीत करता है, और तीसरे पक्ष के उपयोगकर्ताओं और डेवलपर्स से कॉलबैक के लिए वेबहुक शामिल है। आप यूआई का उपयोग नहीं कर सकते क्योंकि अमदातु डिप्लॉयर स्वयं एक आरईएसटी एपीआई है, लेकिन यह इंटरफ़ेस किसी भी एपीआई को शामिल किए बिना आपके लिए तैनाती को बहुत आसान बना सकता है। परिनियोजनctl को Angular 2 का उपयोग करके OSGi/Vertx में लिखा गया है।

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

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

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

तो चलो शुरू हो जाओ। सबसे पहले, हम ~ kubectl get pods कमांड का उपयोग करके किसी भी चल रहे पॉड्स की उपस्थिति की जांच करते हैं और, फ्रंटएंड यूआरएल से प्रतिक्रिया की अनुपस्थिति के आधार पर, हम यह सुनिश्चित करते हैं कि वर्तमान में कोई तैनाती नहीं की जा रही है।

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

यदि आप अब ~ kubectl get pods कमांड दोहराते हैं, तो आप देख सकते हैं कि सिस्टम 20 सेकंड के लिए "फ्रीज" हो जाता है, जिसके दौरान हा-प्रॉक्सी को पुन: कॉन्फ़िगर किया जाता है। इसके बाद, पॉड प्रारंभ होता है, और हमारी प्रतिकृति परिनियोजन लॉग में देखी जा सकती है।

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

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

कमांड ~ kubectl get pods से पता चलता है कि वर्तमान में एप्लिकेशन के 2 संस्करण चल रहे हैं, लेकिन फ्रंटएंड से पता चलता है कि हम अभी भी संस्करण 1 चला रहे हैं।

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

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

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

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

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

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

आइए अगले विषय पर चलते हैं - कुबेरनेट्स क्लस्टर को स्केल करना। ध्यान दें कि kubectl कमांड एक स्केलिंग कमांड है। अधिक सहायता से, हम अपने मौजूदा क्लस्टर में प्रतिकृतियों की संख्या आसानी से बढ़ा सकते हैं। हालाँकि, व्यवहार में, हम आमतौर पर पॉड्स के बजाय नोड्स की संख्या बढ़ाना चाहते हैं।

उसी समय, काम के घंटों के दौरान आपको बढ़ाने की आवश्यकता हो सकती है, और रात में, अमेज़ॅन सेवाओं की लागत को कम करने के लिए, आपको चल रहे एप्लिकेशन इंस्टेंस की संख्या को कम करने की आवश्यकता हो सकती है। इसका मतलब यह नहीं है कि केवल पॉड्स की संख्या को स्केल करना ही पर्याप्त होगा, क्योंकि यदि एक भी नोड निष्क्रिय है, तब भी आपको इसके लिए अमेज़ॅन को भुगतान करना होगा। यानी आपको पॉड्स को स्केल करने के साथ-साथ इस्तेमाल की जाने वाली मशीनों की संख्या को भी स्केल करने की आवश्यकता होगी।

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

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

नई मशीन स्केलिंग समूह में शुरू होती है, खुद को एक नोड के रूप में शुरू करती है, मास्टर की रजिस्ट्री में पंजीकृत होती है और काम करना शुरू करती है। इसके बाद, आप परिणामी नोड्स पर उपयोग के लिए प्रतिकृतियों की संख्या बढ़ा सकते हैं। स्केलिंग को कम करने के लिए अधिक प्रयास की आवश्यकता होती है, क्योंकि आपको यह सुनिश्चित करना होगा कि इस तरह के कदम से "अनावश्यक" मशीनों को बंद करने के बाद पहले से चल रहे एप्लिकेशन नष्ट न हो जाएं। ऐसे परिदृश्य को रोकने के लिए, आपको नोड्स को "अनिर्धारित" स्थिति पर सेट करना होगा। इसका मतलब यह है कि डेमॉनसेट पॉड्स को शेड्यूल करते समय डिफ़ॉल्ट शेड्यूलर इन नोड्स को अनदेखा कर देगा। शेड्यूलर इन सर्वरों से कुछ भी नहीं हटाएगा, लेकिन वहां कोई नया कंटेनर भी लॉन्च नहीं करेगा। अगला कदम ड्रेन नोड को बाहर निकालना है, यानी उसमें से रनिंग पॉड्स को किसी अन्य मशीन, या अन्य नोड्स में स्थानांतरित करना है जिनके पास इसके लिए पर्याप्त क्षमता है। एक बार जब आप यह सुनिश्चित कर लें कि इन नोड्स पर अब कोई कंटेनर नहीं है, तो आप उन्हें कुबेरनेट्स से हटा सकते हैं। इसके बाद, कुबेरनेट्स के लिए उनका अस्तित्व ही समाप्त हो जाएगा। इसके बाद, आपको अनावश्यक नोड्स या मशीनों को अक्षम करने के लिए AWS API का उपयोग करना होगा।
आप AWS API के समान एक अन्य ओपन-सोर्स स्केलिंग टूल Amdatu स्केलर्ड का उपयोग कर सकते हैं। यह क्लस्टर में नोड्स जोड़ने या हटाने के लिए सीएलआई प्रदान करता है। इसकी दिलचस्प विशेषता निम्नलिखित json फ़ाइल का उपयोग करके शेड्यूलर को कॉन्फ़िगर करने की क्षमता है।

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

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

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

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

एक प्रश्न था कि कुबेरनेट्स के साथ हा-प्रॉक्सी लोड बैलेंसर का उपयोग क्यों करें। अच्छा प्रश्न है क्योंकि वर्तमान में लोड संतुलन के 2 स्तर हैं। कुबेरनेट्स सेवाएँ अभी भी वर्चुअल आईपी पते पर मौजूद हैं। आप बाहरी होस्ट मशीनों पर पोर्ट के लिए उनका उपयोग नहीं कर सकते क्योंकि यदि अमेज़ॅन अपने क्लाउड होस्ट को ओवरलोड करता है, तो पता बदल जाएगा। यही कारण है कि हम कुबेरनेट्स के साथ निर्बाध रूप से संचार करने के लिए ट्रैफ़िक के लिए अधिक स्थिर संरचना बनाने के लिए - सेवाओं के सामने हा-प्रॉक्सी रखते हैं।

एक और अच्छा सवाल यह है कि आप नीला/हरा परिनियोजन करते समय डेटाबेस स्कीमा परिवर्तनों का ध्यान कैसे रख सकते हैं? तथ्य यह है कि कुबेरनेट्स के उपयोग के बावजूद, डेटाबेस स्कीमा को बदलना एक कठिन काम है। आपको यह सुनिश्चित करना होगा कि पुरानी और नई स्कीमा संगत हैं, जिसके बाद आप डेटाबेस को अपडेट कर सकते हैं और फिर एप्लिकेशन को स्वयं अपडेट कर सकते हैं। आप डेटाबेस को हॉट स्वैप कर सकते हैं और फिर एप्लिकेशन को अपडेट कर सकते हैं। मैं ऐसे लोगों को जानता हूं जिन्होंने एक नए स्कीमा के साथ एक पूरी तरह से नए डेटाबेस क्लस्टर को बूट किया है, यदि आपके पास मोंगो जैसा स्कीमलेस डेटाबेस है तो यह एक विकल्प है, लेकिन यह वैसे भी एक आसान काम नहीं है। यदि आपके पास कोई और प्रश्न नहीं है, तो आपके ध्यान के लिए धन्यवाद!

कुछ विज्ञापन 🙂

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

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

स्रोत: www.habr.com

डेवॉक्स यूके। कुबेरनेट्स उत्पादन में: नीला/हरा परिनियोजन, ऑटोस्केलिंग और परिनियोजन स्वचालन। भाग 2

कुछ विज्ञापन 🙂

एक टिप्पणी जोड़ें उत्तर रद्द