DEVOXX UK. उत्पादनात कुबर्नेट्स: ब्लू/ग्रीन डिप्लॉयमेंट, ऑटोस्केलिंग आणि डिप्लॉयमेंट ऑटोमेशन. भाग 2

कुबर्नेट्स हे क्लस्टर केलेल्या उत्पादन वातावरणात डॉकर कंटेनर चालविण्यासाठी एक उत्तम साधन आहे. तथापि, अशा समस्या आहेत ज्या कुबर्नेट्स सोडवू शकत नाहीत. वारंवार उत्पादन उपयोजनांसाठी, प्रक्रियेतील डाउनटाइम टाळण्यासाठी आम्हाला पूर्णपणे स्वयंचलित ब्लू/ग्रीन डिप्लॉयमेंटची आवश्यकता असते, ज्याला बाह्य HTTP विनंत्या हाताळण्याची आणि SSL ऑफलोड करण्याची देखील आवश्यकता असते. यासाठी ha-proxy सारख्या लोड बॅलन्सरसह एकत्रीकरण आवश्यक आहे. दुसरे आव्हान म्हणजे क्लाउड वातावरणात चालू असताना कुबर्नेट्स क्लस्टरचे अर्ध-स्वयंचलित स्केलिंग, उदाहरणार्थ रात्रीच्या वेळी क्लस्टरचे अंशतः स्केलिंग करणे.

Kubernetes मध्ये बॉक्सच्या बाहेर ही वैशिष्ट्ये नसली तरी, ते एक API प्रदान करते जे तुम्ही समान समस्यांचे निराकरण करण्यासाठी वापरू शकता. क्लाउड आरटीआय प्रकल्पाचा भाग म्हणून कुबरनेट क्लस्टरचे स्वयंचलित ब्लू/ग्रीन डिप्लॉयमेंट आणि स्केलिंगसाठी साधने विकसित केली गेली, जी ओपन-सोर्सवर आधारित तयार केली गेली.

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

DEVOXX UK. उत्पादनात कुबर्नेट्स: ब्लू/ग्रीन डिप्लॉयमेंट, ऑटोस्केलिंग आणि डिप्लॉयमेंट ऑटोमेशन. भाग 1

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

Kubernetes हे बॉक्सच्या बाहेर उत्पादकपणे वापरले जाऊ शकते असे साधन नाही. अर्थात, तुम्ही ते करू शकता, kubectl इत्यादी वापरू शकता, परंतु तरीही API ही या प्लॅटफॉर्मबद्दल सर्वात मनोरंजक आणि उपयुक्त गोष्ट आहे. API चा फंक्शन्सचा संच म्हणून वापर करून, तुम्ही कुबरनेटमध्ये तुम्हाला जे काही करायचे आहे त्यात प्रवेश करू शकता. kubectl स्वतः REST API देखील वापरते.

हे REST आहे, त्यामुळे तुम्ही या API सह कार्य करण्यासाठी कोणतीही भाषा किंवा साधन वापरू शकता, परंतु सानुकूल लायब्ररींद्वारे तुमचे जीवन अधिक सोपे होईल. माझ्या टीमने अशा 2 लायब्ररी लिहिल्या: एक Java/OSGi साठी आणि एक Go साठी. दुसरा सहसा वापरला जात नाही, परंतु कोणत्याही परिस्थितीत तुमच्याकडे या उपयुक्त गोष्टी आहेत. ते अंशतः परवानाकृत मुक्त-स्रोत प्रकल्प आहेत. वेगवेगळ्या भाषांसाठी अशी अनेक लायब्ररी आहेत, त्यामुळे तुम्ही तुमच्यासाठी योग्य असलेली लायब्ररी निवडू शकता.

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

आमच्या अनुप्रयोगांची तैनाती स्वयंचलित करण्यासाठी आम्ही निळा/हिरवा उपयोजन वापरण्यास प्राधान्य देण्याचे हे एक कारण आहे. या पद्धतीसह, आपण एका वेळी अनुप्रयोगाची फक्त एक आवृत्ती सक्रिय असल्याची खात्री करणे आवश्यक आहे.

निळा/हिरवा उपयोजन यंत्रणा असे दिसते. आम्हाला आमच्या ऍप्लिकेशन्ससाठी ha-proxy द्वारे ट्रॅफिक प्राप्त होते, जे त्याच आवृत्तीच्या ऍप्लिकेशनच्या रनिंग प्रतिकृतींकडे पाठवते.

जेव्हा नवीन उपयोजन केले जाते, तेव्हा आम्ही Deployer वापरतो, ज्याला नवीन घटक दिले जातात आणि नवीन आवृत्ती तैनात केली जाते. ॲप्लिकेशनची नवीन आवृत्ती उपयोजित करणे म्हणजे प्रतिकृतींचा एक नवीन संच “उभे” केला जातो, त्यानंतर नवीन आवृत्तीच्या या प्रतिकृती वेगळ्या, नवीन पॉडमध्ये लाँच केल्या जातात. तथापि, ha-proxy ला त्यांच्याबद्दल काहीही माहिती नाही आणि अद्याप त्यांच्याकडे कोणताही वर्कलोड नाही.

म्हणून, सर्व प्रथम, आरोग्य तपासणीच्या नवीन आवृत्त्यांचे कार्यप्रदर्शन तपासणे आवश्यक आहे याची खात्री करण्यासाठी प्रतिकृती लोड सेवा देण्यासाठी तयार आहेत.

सर्व उपयोजन घटकांनी काही प्रकारच्या आरोग्य तपासणीस समर्थन दिले पाहिजे. ही एक अतिशय सोपी HTTP कॉल तपासणी असू शकते, जेव्हा तुम्हाला स्टेटस 200 सह कोड प्राप्त होतो, किंवा अधिक सखोल तपासणी, ज्यामध्ये तुम्ही डेटाबेस आणि इतर सेवांसह प्रतिकृतींचे कनेक्शन तपासता, डायनॅमिक पर्यावरण कनेक्शनची स्थिरता. , आणि सर्वकाही योग्यरित्या सुरू होते आणि कार्य करते की नाही. ही प्रक्रिया खूप गुंतागुंतीची असू शकते.

सिस्टमने सर्व अपडेट केलेल्या प्रतिकृती कार्यरत असल्याचे सत्यापित केल्यानंतर, डिप्लॉयर कॉन्फिगरेशन अपडेट करेल आणि योग्य कॉन्फिगरेशन पास करेल, जे ha-proxy पुन्हा कॉन्फिगर करेल.

यानंतरच रहदारी नवीन आवृत्तीच्या प्रतिकृतीसह पॉडकडे निर्देशित केली जाईल आणि जुना पॉड अदृश्य होईल.

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

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

त्यामुळे, Deployer ने पहिली गोष्ट केली ती म्हणजे Kubernetes API वापरून RC प्रतिकृती नियंत्रक तयार करणे. हे API पुढील तैनातीसाठी पॉड आणि सेवा तयार करते, म्हणजेच ते आमच्या ऍप्लिकेशन्ससाठी पूर्णपणे नवीन क्लस्टर तयार करते. आरसीची प्रतिकृती सुरू झाल्याची खात्री पटताच, ते त्यांच्या कार्यक्षमतेची आरोग्य तपासणी करेल. हे करण्यासाठी, Deployer GET/health कमांड वापरतो. हे योग्य स्कॅन घटक चालवते आणि क्लस्टरच्या ऑपरेशनला समर्थन देणारे सर्व घटक तपासते.

सर्व पॉड्सनी त्यांच्या आरोग्याची माहिती दिल्यानंतर, डिप्लॉयर एक नवीन कॉन्फिगरेशन घटक तयार करतो - etcd वितरित स्टोरेज, ज्याचा वापर कुबरनेटद्वारे केला जातो, ज्यामध्ये लोड बॅलन्सर कॉन्फिगरेशन संग्रहित केले जाते. आम्ही etcd वर डेटा लिहितो आणि नवीन डेटासाठी confd मॉनिटर्स etcd नावाचे छोटे साधन.

सुरुवातीच्या कॉन्फिगरेशनमध्ये कोणतेही बदल आढळल्यास, ती नवीन सेटिंग्ज फाइल तयार करते आणि ती ha-proxy मध्ये हस्तांतरित करते. या प्रकरणात, ha-proxy कोणतेही कनेक्शन न गमावता रीबूट होते आणि नवीन सेवांवरील लोड संबोधित करते जे आमच्या अनुप्रयोगांची नवीन आवृत्ती कार्य करण्यास सक्षम करते.

जसे आपण पाहू शकता, घटकांची विपुलता असूनही, येथे काहीही क्लिष्ट नाही. तुम्हाला फक्त API आणि etcd वर अधिक लक्ष देणे आवश्यक आहे. मी तुम्हाला ओपन-सोर्स डिप्लॉयरबद्दल सांगू इच्छितो जो आम्ही स्वतः वापरतो - Amdatu Kubernetes Deployer.

हे Kubernetes उपयोजन ऑर्केस्ट्रेट करण्यासाठी एक साधन आहे आणि त्यात खालील वैशिष्ट्ये आहेत:

• निळा/हिरवा उपयोजन;
• बाह्य लोड बॅलन्सर सेट करणे;
• उपयोजन वर्णनकर्ता व्यवस्थापन;
• वास्तविक तैनाती व्यवस्थापित करणे;
• तैनाती दरम्यान आरोग्य तपासणीची कार्यक्षमता तपासणे;
• पॉड्समध्ये पर्यावरणीय व्हेरिएबल्सची अंमलबजावणी.

हा डिप्लॉयर Kubernetes API च्या वर तयार केलेला आहे आणि हँडल आणि डिप्लॉयमेंट्स व्यवस्थापित करण्यासाठी REST API तसेच तैनाती प्रक्रियेदरम्यान लॉग स्ट्रीमिंगसाठी वेबसॉकेट API प्रदान करतो.

हे लोड बॅलन्सर कॉन्फिगरेशन डेटा etcd मध्ये ठेवते, त्यामुळे तुम्हाला आउट-ऑफ-द-बॉक्स सपोर्टसह ha-proxy वापरण्याची गरज नाही, परंतु तुमची स्वतःची लोड बॅलन्सर कॉन्फिगरेशन फाइल सहजपणे वापरा. Amdatu Deployer हे गो मध्ये लिहिलेले आहे, कुबेरनेट्स प्रमाणेच, आणि Apache द्वारे परवानाकृत आहे.

मी डिप्लॉयरची ही आवृत्ती वापरणे सुरू करण्यापूर्वी, मी खालील उपयोजन वर्णनकर्ता वापरला, जे मला आवश्यक पॅरामीटर्स निर्दिष्ट करते.

या कोडच्या महत्त्वाच्या पॅरामीटर्सपैकी एक म्हणजे “useHealthCheck” ध्वज सक्षम करणे. आम्ही हे निर्दिष्ट करणे आवश्यक आहे की तैनाती प्रक्रियेदरम्यान एक स्वच्छता तपासणी करणे आवश्यक आहे. जेव्हा डिप्लॉयमेंट तृतीय-पक्ष कंटेनर वापरते ज्यांची पडताळणी करणे आवश्यक नसते तेव्हा हे सेटिंग अक्षम केले जाऊ शकते. हा वर्णनकर्ता प्रतिकृतींची संख्या आणि ha-proxy ला आवश्यक असलेली फ्रंटएंड URL देखील सूचित करतो. शेवटी पॉड स्पेसिफिकेशन ध्वज "पॉडस्पेक" आहे, जो पोर्ट कॉन्फिगरेशन, इमेज इ. माहितीसाठी कुबर्नेट्सला कॉल करतो. हे अगदी सोपे JSON वर्णनकर्ता आहे.

मुक्त-स्रोत Amdatu प्रकल्पाचा भाग असलेले दुसरे साधन Deploymentctl आहे. त्यात उपयोजन कॉन्फिगर करण्यासाठी, उपयोजन इतिहास संचयित करण्यासाठी UI आहे आणि तृतीय-पक्ष वापरकर्ते आणि विकासकांकडून कॉलबॅकसाठी वेबहुक आहेत. तुम्ही UI वापरू शकत नाही कारण Amdatu Deployer स्वतः REST API आहे, परंतु हा इंटरफेस तुमच्यासाठी कोणतेही API समाविष्ट न करता तैनात करणे अधिक सोपे करू शकतो. Angular 2 वापरून Deploymentctl OSGi/Vertx मध्ये लिहिले आहे.

मी आता प्री-रेकॉर्डेड रेकॉर्डिंग वापरून वरील गोष्टी स्क्रीनवर दाखवीन जेणेकरून तुम्हाला प्रतीक्षा करावी लागणार नाही. आम्ही एक साधा गो ऍप्लिकेशन तैनात करणार आहोत. तुम्ही आधी Go चा प्रयत्न केला नसेल तर काळजी करू नका, हा एक अतिशय सोपा ऍप्लिकेशन आहे त्यामुळे तुम्ही ते शोधण्यात सक्षम असाल.

येथे आम्ही एक HTTP सर्व्हर तयार करत आहोत जो फक्त /आरोग्यला प्रतिसाद देतो, म्हणून हा अनुप्रयोग फक्त आरोग्य तपासणीची चाचणी करतो आणि दुसरे काहीही नाही. चेक पास झाल्यास, खाली दर्शविलेली JSON रचना वापरली जाते. त्यात उपयोक्त्याद्वारे उपयोजित केलेल्या अनुप्रयोगाची आवृत्ती, फाइलच्या शीर्षस्थानी तुम्हाला दिसणारा संदेश आणि बुलियन डेटा प्रकार - आमचा अनुप्रयोग कार्य करत आहे की नाही हे समाविष्ट आहे.

मी शेवटच्या ओळीत थोडी फसवणूक केली, कारण मी फाईलच्या शीर्षस्थानी एक निश्चित बुलियन मूल्य ठेवले आहे, जे भविष्यात मला "अस्वस्थ" अनुप्रयोग देखील तैनात करण्यास मदत करेल. आम्ही हे नंतर हाताळू.

चला तर मग सुरुवात करूया. प्रथम, आम्ही ~ kubectl get pods कमांड वापरून कोणत्याही चालू पॉड्सची उपस्थिती तपासतो आणि, फ्रंटएंड URL कडून प्रतिसाद न मिळाल्याच्या आधारावर, आम्ही खात्री करतो की सध्या कोणतेही उपयोजन केले जात नाही.

स्क्रीनवर पुढे तुम्हाला मी नमूद केलेला Deploymentctl इंटरफेस दिसेल, ज्यामध्ये उपयोजन पॅरामीटर्स सेट केले आहेत: नेमस्पेस, ऍप्लिकेशनचे नाव, उपयोजन आवृत्ती, प्रतिकृतींची संख्या, फ्रंट-एंड URL, कंटेनरचे नाव, प्रतिमा, संसाधन मर्यादा, आरोग्य तपासणीसाठी पोर्ट क्रमांक, इ. संसाधन मर्यादा खूप महत्वाच्या आहेत, कारण ते तुम्हाला जास्तीत जास्त संभाव्य हार्डवेअर वापरण्याची परवानगी देतात. येथे तुम्ही डिप्लॉयमेंट लॉग देखील पाहू शकता.

तुम्ही आता ~ kubectl get pods ही आज्ञा पुन्हा केल्यास, तुम्ही पाहू शकता की सिस्टम 20 सेकंदांसाठी “फ्रीज” होते, ज्या दरम्यान ha-proxy पुन्हा कॉन्फिगर केले जाते. यानंतर, पॉड सुरू होतो, आणि आमची प्रतिकृती तैनाती लॉगमध्ये दिसू शकते.

मी व्हिडिओमधून 20 सेकंद प्रतीक्षा कमी केली आणि आता आपण स्क्रीनवर पाहू शकता की अनुप्रयोगाची पहिली आवृत्ती तैनात केली गेली आहे. हे सर्व फक्त UI वापरून केले गेले.

आता दुसरी आवृत्ती वापरून पाहू. हे करण्यासाठी, मी "हॅलो, कुबर्नेट्स!" वरून अनुप्रयोगाचा संदेश बदलतो. “Hello, Deployer!” वर, सिस्टम ही प्रतिमा तयार करते आणि ती डॉकर रेजिस्ट्रीमध्ये ठेवते, त्यानंतर आम्ही Deploymentctl विंडोमध्ये पुन्हा “डिप्लॉय” बटणावर क्लिक करतो. या प्रकरणात, उपयोजन लॉग स्वयंचलितपणे त्याच प्रकारे लॉन्च केला जातो ज्याप्रमाणे अनुप्रयोगाची पहिली आवृत्ती उपयोजित करताना होते.

कमांड ~ kubectl get pods दाखवते की सध्या ऍप्लिकेशनच्या 2 आवृत्त्या चालू आहेत, परंतु फ्रंटएंड दाखवते की आम्ही अद्याप आवृत्ती 1 चालवत आहोत.

नवीन आवृत्तीकडे रहदारी पुनर्निर्देशित करण्यापूर्वी लोड बॅलन्सर आरोग्य तपासणी पूर्ण होण्याची प्रतीक्षा करतो. 20 सेकंदांनंतर, आम्ही कर्लवर स्विच करतो आणि पाहतो की आमच्याकडे आता अनुप्रयोगाची आवृत्ती 2 तैनात केली आहे आणि पहिली हटविली गेली आहे.

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

तुम्ही बघू शकता, उपयोजन वरील सर्व पायऱ्यांमधून जाते आणि ~kubectl get pods दाखवते की दोन्ही पॉड चालू आहेत. परंतु मागील उपयोजनाप्रमाणे, लॉग कालबाह्य स्थिती दर्शवितो. म्हणजेच, आरोग्य तपासणी अयशस्वी झाल्यामुळे, अनुप्रयोगाची नवीन आवृत्ती तैनात केली जाऊ शकत नाही. परिणामस्वरुप, आपण पहाल की सिस्टम अनुप्रयोगाची जुनी आवृत्ती वापरण्यासाठी परत आली आहे आणि नवीन आवृत्ती फक्त विस्थापित केली गेली आहे.

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

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

आमचा बिल्ड सर्व्हर डॉकर प्रतिमा तयार करेल, ती डॉकर हबमध्ये किंवा तुम्ही वापरता त्या कोणत्याही नोंदणीमध्ये ढकलेल. डॉकर हब वेबहुकला सपोर्ट करते, त्यामुळे आम्ही वर दर्शविलेल्या मार्गाने डिप्लॉयरद्वारे रिमोट डिप्लॉयमेंट ट्रिगर करू शकतो. अशा प्रकारे आपण संभाव्य उत्पादनासाठी आपल्या अनुप्रयोगाची तैनाती पूर्णपणे स्वयंचलित करू शकता.

चला पुढील विषयाकडे वळू - कुबर्नेट्स क्लस्टर स्केल करणे. लक्षात घ्या की kubectl कमांड स्केलिंग कमांड आहे. अधिक मदतीने, आम्ही आमच्या विद्यमान क्लस्टरमधील प्रतिकृतींची संख्या सहजपणे वाढवू शकतो. तथापि, सराव मध्ये, आम्ही सहसा शेंगांऐवजी नोड्सची संख्या वाढवू इच्छितो.

त्याच वेळी, कामाच्या वेळेत तुम्हाला वाढवावी लागेल आणि रात्रीच्या वेळी, Amazon सेवांची किंमत कमी करण्यासाठी, तुम्हाला चालू असलेल्या अनुप्रयोग उदाहरणांची संख्या कमी करावी लागेल. याचा अर्थ असा नाही की केवळ पॉड्सची संख्या मोजणे पुरेसे असेल, कारण जरी एक नोड निष्क्रिय असेल तरीही तुम्हाला अॅमेझॉनला पैसे द्यावे लागतील. म्हणजेच, शेंगा मोजण्याबरोबरच, तुम्हाला वापरलेल्या मशीनची संख्या मोजावी लागेल.

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

त्यामुळे नोड आणि शेंगा या दोन्हींची काळजी घ्यावी लागेल. Kubernetes वर्कर नोड्सची संख्या कॉन्फिगर करण्यासाठी आम्ही AWS API आणि स्केलिंग गट मशीन वापरून नवीन नोड्स लाँच करणे सहजपणे स्केल करू शकतो. कुबर्नेट्स क्लस्टरमध्ये नोड्सची नोंदणी करण्यासाठी तुम्ही क्लाउड-इनिट किंवा तत्सम स्क्रिप्ट देखील वापरू शकता.

नवीन मशीन स्केलिंग ग्रुपमध्ये सुरू होते, स्वतःला नोड म्हणून आरंभ करते, मास्टरच्या नोंदणीमध्ये नोंदणी करते आणि कार्य करण्यास प्रारंभ करते. यानंतर, आपण परिणामी नोड्सवर वापरण्यासाठी प्रतिकृतींची संख्या वाढवू शकता. स्केलिंग डाउन करण्यासाठी अधिक प्रयत्नांची आवश्यकता आहे कारण अशा चरणामुळे "अनावश्यक" मशीन्स बंद केल्यानंतर आधीपासूनच चालू असलेल्या अनुप्रयोगांचा नाश होणार नाही याची खात्री करणे आवश्यक आहे. अशा परिस्थितीला प्रतिबंध करण्यासाठी, तुम्हाला नोड्स "अनशेड्युल" स्थितीवर सेट करणे आवश्यक आहे. याचा अर्थ डेमनसेट पॉड्स शेड्यूल करताना डीफॉल्ट शेड्युलर या नोड्सकडे दुर्लक्ष करेल. शेड्युलर या सर्व्हरमधून काहीही हटवणार नाही, परंतु तेथे कोणतेही नवीन कंटेनर लाँच करणार नाही. पुढील पायरी म्हणजे ड्रेन नोड काढून टाकणे, म्हणजेच त्यामधून चालू असलेल्या पॉड्स दुसऱ्या मशीनमध्ये हस्तांतरित करणे किंवा यासाठी पुरेशी क्षमता असलेले इतर नोड्स. या नोड्सवर यापुढे कोणतेही कंटेनर नाहीत याची खात्री केल्यावर, तुम्ही त्यांना कुबर्नेट्समधून काढू शकता. यानंतर, ते कुबर्नेट्ससाठी अस्तित्वात राहणे बंद करतील. पुढे, तुम्हाला अनावश्यक नोड्स किंवा मशीन्स अक्षम करण्यासाठी AWS API वापरण्याची आवश्यकता आहे.
तुम्ही Amdatu Scalerd, AWS API प्रमाणेच दुसरे ओपन-सोर्स स्केलिंग टूल वापरू शकता. हे क्लस्टरमध्ये नोड्स जोडण्यासाठी किंवा काढून टाकण्यासाठी CLI प्रदान करते. खालील json फाईल वापरून शेड्यूलर कॉन्फिगर करण्याची क्षमता हे त्याचे मनोरंजक वैशिष्ट्य आहे.

दर्शविलेले कोड रात्रीच्या कालावधीत क्लस्टरची क्षमता निम्म्याने कमी करते. हे उपलब्ध प्रतिकृतींची संख्या आणि Amazon क्लस्टरची इच्छित क्षमता दोन्ही कॉन्फिगर करते. हे शेड्युलर वापरल्याने रात्रीच्या वेळी नोड्सची संख्या आपोआप कमी होईल आणि सकाळी वाढेल, अॅमेझॉन सारख्या क्लाउड सेवेवरून नोड्स वापरण्याचा खर्च वाचेल. हे वैशिष्ट्य Kubernetes मध्ये तयार केलेले नाही, परंतु Scalerd वापरल्याने तुम्हाला हा प्लॅटफॉर्म तुम्हाला हवा तसा स्केल करण्याची अनुमती मिळेल.

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

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

विषय संपवण्‍यासाठी, मी तुम्‍हाला Kubernetes वर आधारित Cloud RTI प्‍लॅटफॉर्मशी ओळख करून देऊ इच्छितो, ज्यावर माझी टीम काम करत आहे. हे केंद्रीकृत लॉगिंग, ऍप्लिकेशन आणि क्लस्टर मॉनिटरिंग आणि इतर अनेक उपयुक्त वैशिष्ट्ये प्रदान करते जे उपयोगी पडतील. हे मॉनिटरिंग प्रदर्शित करण्यासाठी Grafana सारखी विविध मुक्त-स्रोत साधने वापरते.

कुबरनेटसह ha-proxy लोड बॅलन्सर का वापरायचा असा प्रश्न होता. चांगला प्रश्न कारण सध्या लोड बॅलन्सिंगचे 2 स्तर आहेत. Kubernetes सेवा अजूनही आभासी IP पत्त्यांवर राहतात. तुम्ही ते बाह्य होस्ट मशीनवरील पोर्टसाठी वापरू शकत नाही कारण Amazon ने त्याचे क्लाउड होस्ट ओव्हरलोड केल्यास, पत्ता बदलेल. यामुळेच आम्ही सेवांसमोर ha-proxy ठेवतो - कुबर्नेट्सशी अखंडपणे संवाद साधण्यासाठी रहदारीसाठी अधिक स्थिर रचना तयार करण्यासाठी.

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

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

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $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