कुबेरनेट्स गाइड, भाग 2: एक क्लस्टर के साथ बनाना और काम करना

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

कुबेरनेट्स का परिचय

मैं वादा करता हूं, और मैं बिल्कुल भी अतिरंजित नहीं हूं कि जब आप इस लेख को पढ़ते हैं, तो अपने आप से पूछें: "कुबेरनेट्स को सुपरनेट्स क्यों नहीं कहा जाता है?"


Supernetes

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

Ern कुबेरनेट्स क्या है?

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

प्रश्न: कैसे कंटेनरीकृत अनुप्रयोग पैमाने?
उत्तर: अतिरिक्त कंटेनरों को लॉन्च करें।

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

प्रश्न: सिस्टम को बाधित किए बिना प्रोग्राम कैसे अपडेट करें? और, यदि अपडेट में कोई त्रुटि है, तो एप्लिकेशन के कार्यशील संस्करण में कैसे लौटें?

वास्तव में, यह कुबेरनेट्स तकनीक है जो इन और कई अन्य सवालों के योग्य जवाब देती है। मैं कुबेरनेट्स की परिभाषा को एक वाक्य तक सीमित करने की कोशिश करूंगा: "कुबेरनेट्स एक कंटेनर प्रबंधन प्रणाली है जो अंतर्निहित बुनियादी ढांचे (जिस वातावरण में कंटेनर चलते हैं) को रोकती है।"

मेरा मानना ​​है कि अब आप "कंटेनर प्रबंधन" की अवधारणा के बारे में विशेष रूप से स्पष्ट नहीं हैं, हालांकि हमने पहले ही इसका उल्लेख किया है। नीचे हम इस तकनीक पर विचार करेंगे। हालांकि, "बुनियादी ढांचे को खत्म करने" की अवधारणा का सामना पहली बार किया गया है। इसलिए, अब हम इस पर विचार करेंगे।

बुनियादी ढांचे का ▍Aststraction

कुबेरनेट्स अनुप्रयोगों को बुनियादी ढांचे से दूर करने की अनुमति देता है, जिससे हमें एक सरल एपीआई मिल जाता है जिससे आप अनुरोध भेज सकते हैं। कुबेरनेट अपनी सभी क्षमताओं का उपयोग करके इन अनुरोधों को पूरा करने की कोशिश करता है। उदाहरण के लिए, एक नियमित भाषा में, एक समान अनुरोध निम्नानुसार वर्णित किया जा सकता है: "कुबेरनेट्स, 4 छवि कंटेनरों का विस्तार करें एक्स"। आदेश प्राप्त करने के बाद, कुबेरनेट्स नोड्स पाएंगे जो बहुत व्यस्त नहीं हैं (उन्हें "नोड" भी कहा जाता है - अंग्रेजी "नोड" से), जिस पर आप नए कंटेनर तैनात कर सकते हैं।


एपीआई सर्वर अनुरोध

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

पिछले आंकड़े में जो दिखाया गया है, उससे बहुत पहले ही आप परिचित हैं। लेकिन कुछ नया भी है:

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

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

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

Providers क्लाउड सेवा प्रदाताओं के साथ काम का मानकीकरण

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

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

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

अब बात करते हैं कुबेरनेट्स के व्यावहारिक उपयोग की

कुबेरनेट्स अभ्यास: फली

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


माइक्रोसेबल्स कुबेरनेट द्वारा प्रबंधित क्लस्टर में काम करते हैं

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

Ube स्थापना और मिनिक्यूब की शुरुआत

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

मिनीब्यूब को शुरू करने के लिए, minikube start कमांड को minikube start , और इसके पूरा होने के बाद, kubectl get nodes कमांड kubectl get nodes । नतीजतन, आपको निम्न जैसा कुछ देखना चाहिए:

 kubectl get nodes NAME       STATUS ROLES     AGE VERSION minikube   Ready <none>    11m v1.9.0 

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

अब बात करते हैं फली की।

▍Pody

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

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

निम्न आरेख संख्याबद्ध चूल्हा गुणों को दर्शाता है।


चूल्हा गुण

इन गुणों पर विचार करें।

1. कुबेरनेट क्लस्टर में प्रत्येक पॉड में एक विशिष्ट आईपी पता होता है।
2. चूल्हा में कई कंटेनर हो सकते हैं। वे उपलब्ध पोर्ट नंबर साझा करते हैं, उदाहरण के लिए, वे localhost माध्यम से एक दूसरे के साथ सूचना का आदान-प्रदान कर सकते हैं (स्वाभाविक रूप से, वे समान पोर्ट का उपयोग नहीं कर सकते हैं)। अन्य पॉड्स में स्थित कंटेनरों के साथ इंटरैक्शन इन पॉड्स के आईपी पते का उपयोग करके आयोजित किया जाता है।
3. पॉड्स में कंटेनर डेटा स्टोरेज वॉल्यूम, आईपी एड्रेस, पोर्ट नंबर, आईपीसी नेमस्पेस साझा करते हैं।

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

हमारे लिए जो पहले से ही चूल्हों के बारे में कहा गया है, वह कुबेरनेट्स को जारी रखने के लिए पर्याप्त है। उनके बारे में यहाँ और पढ़ें।

▍ चूल्हा का वर्णन

निम्नलिखित sa-frontend एप्लिकेशन के लिए एक मैनिफ़ेस्ट फ़ाइल है।

 apiVersion: v1 kind: Pod                                            # 1 metadata: name: sa-frontend                                  # 2 spec:                                                # 3 containers:   - image: rinormaloku/sentiment-analysis-frontend # 4     name: sa-frontend                              # 5     ports:       - containerPort: 80 

आइए हम इसमें निर्दिष्ट कुछ मापदंडों की व्याख्या करते हैं।

1. Kind : कुबेरनेट्स संसाधन को हम बनाना चाहते हैं। हमारे मामले में, यह Pod ।
2. Name : संसाधन का नाम। हमने इसे sa-frontend कहा।
3. Spec : एक वस्तु जो संसाधन की वांछित स्थिति का वर्णन करती है। यहां सबसे महत्वपूर्ण संपत्ति कंटेनरों की सरणी है।
4. Image : कंटेनर की छवि जिसे हम इस पॉड में चलाना चाहते हैं।
5. Name : नीचे दिए गए कंटेनर के लिए एक अद्वितीय नाम।
6. ContainerPort : ContainerPort जिस पोर्ट पर सुन रहा है। इस पैरामीटर को एक संकेत माना जा सकता है कि कौन इस फ़ाइल को पढ़ता है (यदि आप इस पैरामीटर को छोड़ देते हैं, तो यह पोर्ट तक पहुंच को सीमित नहीं करेगा)।

▍ एक चूल्हा SA-Frontend बनाना

पॉड डिस्क्रिप्शन फाइल जिसके बारे में हमने बात की है, वह resource-manifests/sa-frontend-pod.yaml । आपको टर्मिनल टूल का उपयोग करके या तो इस फ़ोल्डर में जाना चाहिए, या, जब आप उपयुक्त कमांड को कॉल करते हैं, तो फ़ाइल का पूरा पथ निर्दिष्ट करें। यहाँ यह कमांड है और सिस्टम प्रतिक्रिया का एक उदाहरण है:

 kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created 

यह पता लगाने के लिए कि यह किसके तहत काम करता है, निम्नलिखित कमांड चलाएँ:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s 

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

Outside बाहर से आवेदन करने में असफल

बाहर से एप्लिकेशन तक पहुंच को व्यवस्थित करने के लिए, सेवा प्रकार का एक कुबेरनेट संसाधन बनाना सही होगा, जिसके बारे में हम नीचे बात करेंगे, लेकिन यहाँ, संक्षिप्तता के लिए, हम एक साधारण पोर्ट फ़ॉरवर्डिंग का उपयोग करेंगे:

 kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80 

यदि आप अब 127.0.0.1:88 पर एक ब्राउज़र से गुजरते हैं, तो आप रिएक्ट एप्लिकेशन पेज देख सकते हैं।

▍ गलत स्केलिंग दृष्टिकोण

हम पहले ही कह चुके हैं कि कुबेरनेट्स की क्षमताओं में से एक अनुप्रयोग स्केलिंग है। इस अवसर का अनुभव करने के लिए, हम एक और एक के तहत चलेंगे। निम्नलिखित कोड को sa-frontend-pod2.yaml फ़ाइल में रखकर एक और Pod संसाधन का विवरण बनाएँ:

 apiVersion: v1 kind: Pod                                           metadata: name: sa-frontend2      #   spec:                                                containers:   - image: rinormaloku/sentiment-analysis-frontend     name: sa-frontend                                  ports:       - containerPort: 80 

जैसा कि आप देख सकते हैं, यदि आप इस विवरण की तुलना करते हैं कि हमने ऊपर क्या जांच की है, तो इसमें एकमात्र परिवर्तन Name संपत्ति का मूल्य है।

के तहत एक नया बनाएँ:

 kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created 

सुनिश्चित करें कि यह चल रहा है:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s sa-frontend2                  1/1 Running 0 7s 

अब हमारे पास दो चूल्हे हैं! सच है, यहां आनंद लेने के लिए कुछ खास नहीं है। कृपया ध्यान दें कि यहां दिखाई गई एप्लिकेशन स्केलिंग समस्या के समाधान में कई कमियां हैं। हम इस बारे में बात करेंगे कि यह एक और Kubernetes संसाधन पर अनुभाग में कैसे करना है जिसे तैनाती कहा जाता है।

अब विचार करें कि दो समान श्रोताओं को लॉन्च करने के बाद हमें क्या मिला। अर्थात्, नग्नेक्स वेब सर्वर अब दो अलग-अलग पॉड्स में चलता है। इस संबंध में, हम दो प्रश्न पूछ सकते हैं:

1. URL से बाहर से इन सर्वरों तक पहुंच कैसे दें?
2. उनके बीच लोड संतुलन को कैसे व्यवस्थित करें?

गलत स्केलिंग दृष्टिकोण

कुबेरनेट्स टूल के बीच फॉर्म सेवा के संसाधन हैं। आइए उनके बारे में बात करते हैं।

कुबेरनेट्स अभ्यास: सेवाएं

Kubernetes की सेवाएं चूल्हा सेटों तक पहुंच बिंदुओं के रूप में कार्य करती हैं जो इन चूल्हों के समान कार्यक्षमता प्रदान करती हैं। सेवाएं चूल्हा के साथ काम करने और उनके बीच लोड को संतुलित करने के कठिन कार्यों का समाधान करती हैं।


कुबेरनेट्स सेवा आईपी पते की सेवा देती है

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

यह लेबल नामक एक अन्य कुबेरनेट्स अमूर्त के साथ किया जाता है। टैग के साथ काम दो चरणों के होते हैं:

1. लेबल असाइनमेंट सेवा को काम करने देगा।
2. सेवा के लिए एक "चयनकर्ता" को लागू करना, जो यह निर्धारित करता है कि कौन से पॉड्स को लेबल सौंपा गया है, सेवा काम करेगी।

शायद यह वर्णन करने की तुलना में एक उदाहरण के रूप में कल्पना करना आसान है।


लेबल वाली फली और उनकी प्रकट फाइलें

हम यहाँ दो चूल्हा देखते हैं, जो app: sa-frontend का उपयोग कर रहे हैं app: sa-frontend निर्माण, एक ही लेबल असाइन किया गया है। इस तरह के निशान के साथ फली में सेवा की दिलचस्पी है।

▍Metki

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

 kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured 

जब इन आदेशों को निष्पादित किया जाता है, तो सिस्टम चेतावनी जारी करेगा (यह हमें सूट नहीं करता है कि हम create बजाय apply उपयोग करते create , हम इसे समझते हैं), लेकिन, एक चेतावनी के बाद, यह रिपोर्ट करता है कि संबंधित पॉड्स कॉन्फ़िगर किए गए हैं। हम जाँच सकते हैं कि क्या लेबल लेबल दिए गए थे, लॉग को फ़िल्टर करके जिसके लिए हम जानकारी प्रदर्शित करना चाहते हैं:

 kubectl get pod -l app=sa-frontend NAME           READY STATUS    RESTARTS AGE sa-frontend    1/1 Running   0 2h sa-frontend2   1/1 Running   0 2h 

यह सत्यापित करने का एक और तरीका है कि लेबल वास्तव में लेबल असाइन किए गए हैं --show-labels पिछले कमांड में --show-labels कुंजी संलग्न करना है। इसके कारण, उनकी फली की जानकारी में उनके निशान पर डेटा भी शामिल होगा।

अब टैग सौंपे गए हैं और हम उनके साथ काम करने के लिए सेवा को कॉन्फ़िगर करने के लिए तैयार हैं। इसलिए, हम LoadBalancer जैसी सेवा के विवरण के साथ LoadBalancer करेंगे।


LoadBalancer जैसी सेवा का उपयोग करके भार संतुलन

▍ सेवा विवरण

यहाँ LoadBalancer जैसी सेवा का LoadBalancer विवरण LoadBalancer :

 apiVersion: v1 kind: Service              # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer       # 2 ports: - port: 80               # 3   protocol: TCP          # 4   targetPort: 80         # 5 selector:                # 6   app: sa-frontend       # 7 

इस पाठ की व्याख्या करें:

1. Kind : हम एक सेवा, एक Service संसाधन बनाते हैं।
2. Type : इसके विनिर्देशन में संकेतित संसाधन का प्रकार। हमने LoadBalancer प्रकार चुना, क्योंकि इस सेवा के साथ हम चूल्हों के बीच लोड को संतुलित करने की समस्या को हल करना चाहते हैं।
3. Port : पोर्ट जिस पर सेवा अनुरोध स्वीकार करती है।
4. Protocol : सेवा द्वारा उपयोग किया जाने वाला प्रोटोकॉल।
5. TargetPort : आने वाले अनुरोधों को पोर्ट को पुनर्निर्देशित किया गया है
6. Selector : ऐसी वस्तु जिसके बारे में जानकारी होनी चाहिए कि सेवा किसके साथ काम करना चाहिए।
7. app: sa-frontend : यह प्रॉपर्टी बताती है कि सर्विस किस पॉड के साथ काम करेगी। अर्थात्, ये वे पॉड हैं जिनसे app: sa-frontend लेबल असाइन किया गया है।

सेवा बनाने के लिए, आपको निम्न कमांड चलाने की आवश्यकता है:

 kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created 

आप निम्नानुसार सेवा की स्थिति देख सकते हैं:

 kubectl get svc NAME             TYPE CLUSTER-IP      EXTERNAL-IP PORT(S) AGE sa-frontend-lb   LoadBalancer 10.101.244.40   <pending> 80:30708/TCP 7m 

यहां आप देख सकते हैं कि EXTERNAL-IP संपत्ति <pending> स्थिति में है, लेकिन आप इसे बदलने के लिए इंतजार नहीं कर सकते। यह इस तथ्य के कारण है कि हम मिनिक्यूब का उपयोग करते हैं। यदि हमने एक निश्चित क्लाउड सेवा प्रदाता, जैसे कि एज़्योर या Google क्लाउड प्लेटफ़ॉर्म के साथ काम करते हुए ऐसी सेवा बनाई है, तो सेवा में एक सार्वजनिक आईपी पता होगा जो इंटरनेट से इसे एक्सेस करना संभव बना देगा।

इसके बावजूद, मिनिक्यूब हमें गड़बड़ करने की अनुमति नहीं देगा, हमें सिस्टम के स्थानीय डिबगिंग के लिए एक उपयोगी कमांड दे रहा है:

 minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser... 

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

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

कुबेरनेट्स अभ्यास: नियोजन

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

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

▍ तैनाती के उपयोग

अब क्लस्टर में दो चूल्हा और एक सेवा है जो उन्हें बाहर से पहुंच प्रदान करती है और उन पर भार को संतुलित करती है।


क्लस्टर वर्तमान स्थिति

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

इससे पहले कि हम काम जारी रखें, आइए इसके लक्ष्यों को तैयार करें, जो हमें दिशा-निर्देश देंगे जो तैनाती की घोषणा फ़ाइल को पार्स करते समय काम आएंगे। तो यहाँ है कि हम क्या जरूरत है:

1. हम एक कंटेनर rinormaloku/sentiment-analysis-frontend आधार पर दो चूल्हा बनाने में सक्षम होना चाहते हैं।
2. हमें एक एप्लिकेशन परिनियोजन प्रणाली की आवश्यकता है जो इसे अपडेट किए जाने पर बिना किसी रुकावट के काम करने की अनुमति देती है।
3. हम चाहते हैं कि app: sa-frontend लेबल असाइन किया जाए app: sa-frontend , जो sa-frontend-lb सर्विस को इन पॉड्स का पता लगाने की अनुमति देगा।

अब हम इन आवश्यकताओं को परिनियोजन संसाधन के विवरण के रूप में व्यक्त करेंगे।

Description परिनियोजन विवरण

यहां पर परिनियोजन-प्रकार के संसाधन का एक YAML विवरण दिया गया है, जो उपरोक्त सिस्टम आवश्यकताओं को ध्यान में रखते हुए बनाया गया था:

 apiVersion: extensions/v1beta1 kind: Deployment                                          # 1 metadata: name: sa-frontend spec: replicas: 2                                             # 2 minReadySeconds: 15 strategy:   type: RollingUpdate                                   # 3   rollingUpdate:     maxUnavailable: 1                                   # 4     maxSurge: 1                                         # 5 template:                                               # 6   metadata:     labels:       app: sa-frontend                                  # 7   spec:     containers:       - image: rinormaloku/sentiment-analysis-frontend         imagePullPolicy: Always                         # 8         name: sa-frontend         ports:           - containerPort: 80 

आइए इस विवरण का विश्लेषण करें:

1. Kind : यह यहाँ कहता है कि हम Deployment दृश्य के एक संसाधन का वर्णन कर रहे हैं।
2. Replicas : परिनियोजन विनिर्देशन ऑब्जेक्ट की एक संपत्ति जो परिभाषित करती है कि कितने उदाहरणों (प्रतिकृतियां) को चलाने के लिए चूल्हा है।
3. Type : इस तैनाती में उपयोग की जाने वाली रणनीति का वर्णन करता है जब वर्तमान संस्करण से एक नए पर स्विच किया जाता है। RollingUpdate रणनीति उन्नयन के दौरान शून्य सिस्टम डाउनटाइम प्रदान करती है।
4. MaxUnavailable : यह RollingUpdate ऑब्जेक्ट की एक संपत्ति है, जो अनुक्रमिक सिस्टम अपडेट करते समय अनुपलब्ध चूल्हों की अधिकतम संख्या (चूल्हों की वांछित संख्या की तुलना में) सेट करता है। हमारी तैनाती में, जो 2 प्रतिकृतियों की उपस्थिति का तात्पर्य करता है, इस संपत्ति का मूल्य इंगित करता है कि एक पॉड के पूरा होने के बाद, दूसरे को निष्पादित किया जाएगा, जो अपडेट के दौरान आवेदन को उपलब्ध कराता है।
5. MaxSurge : यह MaxSurge की एक संपत्ति है जो अधिकतम संख्या में चूल्हों का वर्णन करती है जिन्हें तैनाती में जोड़ा जा सकता है (किसी संख्या में चूल्हा की तुलना में)। हमारे मामले में, इसके मूल्य, 1 का अर्थ है कि, जब प्रोग्राम के नए संस्करण पर स्विच किया जा रहा है, तो हम क्लस्टर में एक और उप जोड़ सकते हैं, जिससे इस तथ्य को बढ़ावा मिलेगा कि एक साथ तीन चूल्हों को लॉन्च किया जा सकता है।
6. Template : यह ऑब्जेक्ट चूल्हा टेम्पलेट को परिभाषित करता है जिसे वर्णित Deployment संसाधन नए चूल्हा बनाने के लिए उपयोग करेगा। आप शायद इस सेटिंग को परिचित पाएंगे।
7. app: sa-frontend : दिए गए पैटर्न के अनुसार बनाए गए चूल्हों के लिए लेबल।
8. ImagePullPolicy : छवियों के साथ काम के क्रम को परिभाषित करता है। हमारे मामले में, यह संपत्ति Always लिए सेट है, अर्थात्, प्रत्येक परिनियोजन के दौरान, संबंधित छवि को रिपॉजिटरी से डाउनलोड किया जाएगा।

इस सब की जांच करने के बाद, चलिए अभ्यास करते हैं। तैनाती चलाएं:

 kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created 

सिस्टम की स्थिति की जाँच करें:

 kubectl get pods NAME                           READY STATUS RESTARTS AGE sa-frontend                    1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4   1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg   1/1 Running 0 1m sa-frontend2                   1/1 Running 0 2d 

जैसा कि आप देख सकते हैं, अब हमारे पास 4 पॉड हैं। उनमें से दो परिनियोजन संसाधन का उपयोग करके बनाए गए थे, दो और वे हैं जो हमने खुद बनाए थे। अब आप उन पॉड्स को हटा सकते हैं जिन्हें हमने निम्न प्रकार के कमांड का उपयोग करके खुद बनाया था:

 kubectl delete pod <pod-name> 

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

एक चूल्हा को हटाते समय, परिनियोजन संसाधन से पता चलता है कि सिस्टम की वर्तमान स्थिति (1 उप) वांछित एक (2 उप) से अलग है, इसलिए एक और उप लॉन्च किया गया है।

इस तथ्य के अलावा कि तैनाती के संसाधनों का उपयोग क्या है, जब सिस्टम को सही स्थिति में बनाए रखा जाता है? इन संसाधनों की ताकत पर विचार करें।

Down शून्य सिस्टम डाउनटाइम के साथ परिनियोजन निष्पादित करना

मान लीजिए कि एक उत्पाद प्रबंधक हमारे पास आता है और रिपोर्ट करता है कि जिस ग्राहक के लिए हमने यह उत्पाद बनाया है, वह ग्राहक एप्लिकेशन में एक हरा बटन चाहता है। डेवलपर्स इस आवश्यकता को लागू करते हैं और हमें केवल वही चीज़ देते हैं जो हमें उनकी ज़रूरत है - एक छवि कंटेनर जिसे rinormaloku/sentiment-analysis-frontend:green कहा जाता है। अब हमारा समय आता है। हम, DevOps टीम को अद्यतन प्रणाली को तैनात करने और शून्य डाउनटाइम सुनिश्चित करने की आवश्यकता है। अब देखते हैं कि तैनाती संसाधन को विकसित करने और कॉन्फ़िगर करने के प्रयास उचित हैं या नहीं।

sa-frontend-deployment.yaml rinormaloku/sentiment-analysis-frontend:green फ़ाइल संपादित करें, छवि कंटेनर नाम को नए rinormaloku/sentiment-analysis-frontend:green से rinormaloku/sentiment-analysis-frontend:green , rinormaloku/sentiment-analysis-frontend:green साथ rinormaloku/sentiment-analysis-frontend:green , फिर इस फ़ाइल को sa-frontend-deployment-green.yaml और निम्न कमांड निष्पादित करें:

 kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured 

निम्नलिखित कमांड के साथ सिस्टम की स्थिति जांचें:

 kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out 

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

, , :

 minikube service sa-frontend-lb 

, .




, , — .

RollingUpdate

, kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , , rinormaloku/sentiment-analysis-frontend:green . , , .




RollingUpdate , , maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .

Deployment. , . .

▍

, , . «! ! !», — . . , , :

 kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION  CHANGE-CAUSE 1         <none>    2         kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true 

: «, , ?».

«. , ?», — .

, , :

 kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back 

. , .

.

.

!

, . Kubernetes , , . , !

. , . CHANGE-CAUSE <none> , — kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?

, -- record , .

, , , .

Kubernetes:

Kubernetes, , . , .




.

▍ sa-logic

resource-manifests :

 kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created 

sa-logic . Python-. app: sa-logic . sa-logic , . sa-logic-deployment.yaml .

-, , — sa-logic .

▍ sa-logic

, Service. , Java-, sa-webapp , , Python-. , , , Python-, . , , , .

, , , , . , sa-logic , sa-logic .

:

 kubectl apply -f service-sa-logic.yaml service "sa-logic" created 

, .




sa-logic , sa-webapp , , .

sa-webapp .

▍ sa-webapp

, Deployment - . , sa-web-app-deployment.yaml , :

 - image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env:   - name: SA_LOGIC_API_URL     value: "http://sa-logic" ports:   - containerPort: 8080 

env ? , , , SA_LOGIC_API_URL http://sa-logic . , , . ?

kube-dns.

▍DNS- Kubernetes

Kubernetes , kube-dns . DNS-. kube-dns , DNS- .

, sa-logic , IP-. kube-dns IP- . http://sa-logic IP-.

Deployment sa-webapp .

▍ sa-webapp

:

 kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created 

sa-webapp , . React- , sa-webapp .

▍ sa-webapp

service-sa-web-app-lb.yaml , , , , . , , :

 kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created 

. , , . , sa-frontend , Java- sa-webapp , http://localhost:8080/sentiment . , , sa-webapp , React- , Java-.

, . , — , , .

, :

1. IP- sa-webapp , :
   
   minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------|
2. IP- sa-frontend/src/App.js . , :
   
   

    analyzeSentence() {       fetch('http://192.168.99.100:31691/sentiment', { /*    */})           .then(response => response.json())           .then(data => this.setState(data));   } 

3. React-, sa-frontend npm run build .
4. :
   
   

    docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube. 

5. Docker Hub:
   
   

    docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube 

6. sa-frontend-deployment.yaml , .
7. :
   
   

    kubectl apply -f sa-frontend-deployment.yaml 

, , , , minikube service sa-frontend-lb . , - .

परिणाम

Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.

, :

• , , React, Java Python.
• Docker, , Dockerfile .
• , , Docker Hub.

, Kubernetes:

, , Kubernetes.

प्रिय पाठकों! Kubernetes?