उद्देश्य

• जानें कुबेरनेट्स क्लस्टर क्या है।
• जानें मिनिक्यूब क्या है।
• अपने कंप्यूटर पर Kubernetes क्लस्टर प्रारंभ करें।

कुबेरनेट्स क्लस्टर

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

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

• कंट्रोल प्लेन क्लस्टर का समन्वय करता है
• नोड्स वे कर्मचारी हैं जो एप्लिकेशन चलाते हैं

क्लस्टर आरेख

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

नोड एक VM या एक भौतिक कंप्यूटर है जो कुबेरनेट्स क्लस्टर में एक वर्कर मशीन के रूप में कार्य करता है। प्रत्येक नोड में एक kubelet होता है, जो नोड के प्रबंधन और कुबेरनेट्स नियंत्रण के साथ संचार करने के लिए एक एजेंट है। नोड में कंटेनर संचालन को संभालने के लिए उपकरण भी होने चाहिए, जैसे कि containerd या Docker। उत्पादन ट्रैफ़िक को संभालने वाले कुबेरनेट्स क्लस्टर में कम से कम तीन नोड होने चाहिए।

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

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

अब जब आप कुबेरनेट्स के बारे में अधिक जान गए हैं, तो इसे अपने कंप्यूटर पर आज़माने के लिए हेलो मिनिक्यूब पर जाएं।

उद्देश्यों

• एप्लिकेशन डिप्लॉयमेंट के बारे में जानें।
• कुबेरनेट्स पर kubectl के साथ अपना पहला ऐप डिप्लॉय करें।

कुबेरनेट्स डिप्लॉयमेंट

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

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

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

कुबेरनेट्स पर अपना पहला ऐप डिप्लॉय करें

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

जब आप कोई डिप्लॉयमेंट बनाते हैं, तो आपको अपने एप्लिकेशन के लिए कंटेनर इमेज और चलाने के लिए इच्छित प्रतिकृतियों की संख्या निर्दिष्ट करने की आवश्यकता होगी। आप अपने कामकाज को अपडेट करके बाद में उस जानकारी को बदल सकते हैं; बूटकैंप के मॉड्यूल 5 और 6 चर्चा करते हैं कि आप अपने डिप्लॉयमेंट को कैसे स्केल और अपडेट कर सकते हैं।

अपने पहले डिप्लॉयमेंट के लिए, आप एक डॉकर कंटेनर में पैक किए गए हैलो-नोड एप्लिकेशन का उपयोग करेंगे जो सभी अनुरोधों को प्रतिध्वनित करने के लिए NGINX का उपयोग करता है। (यदि आपने पहले से हैलो-नोड एप्लिकेशन बनाने और कंटेनर का उपयोग करके इसे तैनात करने का प्रयास नहीं किया है, तो आप पहले हेलो Minikube ट्यूटोरियल के निर्देशों का पालन करके ऐसा कर सकते हैं)।

आपको kubectl भी इंस्टॉल करना होगा। यदि आपको इसे इंस्टॉल करने की आवश्यकता है, तो इंस्टॉल टूल्स पर जाएं।

अब जब आप जान गए हैं कि डिप्लॉयमेंट क्या हैं, तो आइए अपना पहला ऐप परिनियोजित करें!

kubectl की मूल बातें

कुबेक्टल कमांड का सामान्य प्रारूप है: kubectl action resource

यह निर्दिष्ट संसाधन (जैसे नोड या डिप्लॉयमेंट ) पर निर्दिष्ट क्रिया (जैसे बनाना, वर्णन करना या हटाना) करता है। आप संभावित मापदंडों के बारे में अतिरिक्त जानकारी प्राप्त करने के लिए उपकमांड के बाद --help का उपयोग कर सकते हैं (उदाहरण के लिए: kubectl get nodes --help)।

kubectl version कमांड चलाकर जांचें कि kubectl आपके क्लस्टर से बात करने के लिए कॉन्फ़िगर किया गया है।

जांचें कि kubectl स्थापित है और आप क्लाइंट और सर्वर दोनों संस्करण देख सकते हैं।

क्लस्टर में नोड्स देखने के लिए, kubectl get nodes कमांड चलाएँ।

आप उपलब्ध नोड्स देखते हैं। बाद में, Kubernetes नोड उपलब्ध संसाधनों के आधार पर हमारे एप्लिकेशन को कहां तैनात करना है इसका चयन करेगा।

एक ऐप तैनात करें

आइए अपना पहला ऐप कुबेरनेट्स पर kubectl create deployment कमांड के साथ तैनात करें। हमें डिप्लॉयमेंट नाम और ऐप छवि स्थान प्रदान करने की आवश्यकता है (डॉकर हब के बाहर होस्ट की गई छवियों के लिए पूर्ण रिपॉजिटरी यूआरएल शामिल करें)।

kubectl create deployment Kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

बहुत बढ़िया! आपने अभी-अभी एक डिप्लॉयमेंट बनाकर अपना पहला एप्लिकेशन डेप्लॉये किया है। इसने आपके लिए कुछ चीज़ें निष्पादित कीं:

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

अपने डिप्लॉयमेंट को सूचीबद्ध करने के लिए kubectl get deployment कमांड का उपयोग करें:

kubectl get deployments

हम देखते हैं कि आपके ऐप का एक इंस्टेंस 1 डिप्लॉयमेंट चला रहा है। इंस्टेंस आपके नोड पर एक कंटेनर के अंदर चल रहा है।

ऐप देखें

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

हम बाद में मॉड्यूल 4 में कुबेरनेट्स क्लस्टर के बाहर आपके एप्लिकेशन को प्रदर्शित करने के अन्य विकल्पों पर चर्चा करेंगे।

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

प्रॉक्सी चलाने के लिए आपको दूसरी टर्मिनल विंडो खोलनी होगी।

kubectl proxy

अब हमारे होस्ट (टर्मिनल) और कुबेरनेट्स क्लस्टर के बीच एक कनेक्शन है। प्रॉक्सी इन टर्मिनलों से एपीआई तक सीधी पहुंच सक्षम बनाता है।

आप प्रॉक्सी एंडपॉइंट के माध्यम से होस्ट किए गए सभी एपीआई देख सकते हैं। उदाहरण के लिए, हम curl कमांड का उपयोग करके सीधे API के माध्यम से संस्करण को क्वेरी कर सकते हैं:

curl http://localhost:8001/version

एपीआई सर्वर स्वचालित रूप से पॉड नाम के आधार पर प्रत्येक पॉड के लिए एक एंडपॉइंट बनाएगा, जिसे प्रॉक्सी के माध्यम से भी एक्सेस किया जा सकता है।

सबसे पहले हमें पॉड नाम प्राप्त करने की आवश्यकता है, और हम पर्यावरण चर POD_NAME में संग्रहित करेंगे:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{ {end}}')
echo पॉड का नाम: $POD_NAME

आप निम्न चलाकर प्रॉक्सी एपीआई के माध्यम से पॉड तक पहुंच सकते हैं:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

नए डिप्लॉयमेंट को प्रॉक्सी का उपयोग किए बिना पहुंच योग्य बनाने के लिए, एक सेवा की आवश्यकता होती है जिसे मॉड्यूल 4 में समझाया जाएगा .

उद्देश्य

• कुबेरनेट्स पॉड्स के बारे में जानें।
• कुबेरनेट्स नोड्स के बारे में जानें।
• डिप्लॉयड एप्लीकेशन का समस्या निवारण करें।

कुबेरनेट्स पॉड्स

जब आपने मॉड्यूल 2 में एक एप्लीकेशन बनाया, तो कुबेरनेट्स ने आपके एप्लिकेशन इंस्टेंस को होस्ट करने के लिए एक पॉड बनाया। पॉड एक कुबेरनेट्स एब्स्ट्रैक्शन है जो एक या अधिक एप्लिकेशन कंटेनरों (जैसे डॉकर) के समूह और उन कंटेनरों के लिए कुछ साझा संसाधनों का प्रतिनिधित्व करता है। उन संसाधनों में शामिल हैं:

• साझा स्टोरेज, वॉल्यूम के रूप में
• नेटवर्किंग, एक अद्वितीय क्लस्टर IP पते के रूप में
• प्रत्येक कंटेनर को चलाने के तरीके के बारे में जानकारी, जैसे कंटेनर इमेज संस्करण या उपयोग करने के लिए विशिष्ट पोर्ट

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

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

पॉड्स अवलोकन

नोड्स

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

प्रत्येक कुबेरनेट्स नोड पर कम से कम ये चलते हैं:

• क्यूबलेट, कुबेरनेट्स कण्ट्रोल प्लेन और नोड के बीच संचार के लिए जिम्मेदार एक प्रक्रिया; यह पॉड्स और मशीन पर चलने वाले कंटेनरों का प्रबंधन करता है।
• एक कंटेनर रनटाइम (जैसे डॉकर), एक रजिस्ट्री से कंटेनर इमेज को पुल करने, कंटेनर को अनपैक करने और एप्लिकेशन चलाने के लिए।

नोड अवलोकन

kubectl के साथ समस्या निवारण

मॉड्यूल 2 में, आपने कमांड लाइन इंटरफ़ेस का उपयोग किया है। डेप्लॉयड एप्लीकेशन और उनके एनवायरनमेंट के बारे में जानकारी प्राप्त करने के लिए आप मॉड्यूल 3 में इसका उपयोग करना जारी रखेंगे। सबसे आम ऑपरेशन निम्नलिखित kubectl कमांड के साथ किया जा सकता है:

• kubectl get - संसाधनों की सूची बनाएं
• kubectl describe - संसाधन के बारे में विस्तृत जानकारी दिखाएं
• kubectl logs - पॉड में कंटेनर के लॉग प्रिंट करें
• kubectl exec - पॉड में कंटेनर पर कमांड चलाए

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

अब जब हम अपने क्लस्टर कॉम्पोनेन्ट और कमांड लाइन के बारे में जानते हैं, तो आइए हमारे एप्लिकेशन को देखें।

एप्लिकेशन कॉन्फ़िगरेशन की जाँच करें

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

kubectl get pods

यदि कोई पॉड्स नहीं चल रहा है, तो कृपया कुछ सेकंड प्रतीक्षा करें और पॉड्स को फिर से सूचीबद्ध करें। एक बार जब आप एक पॉड को चलता हुआ देख लें तो आप जारी रख सकते हैं।

इसके बाद, यह देखने के लिए कि उस पॉड के अंदर कौन से कंटेनर हैं और उन कंटेनरों को बनाने के लिए कौन सी छवियों का उपयोग किया जाता है, हम kubectl describe pods कमांड चलाते हैं:

kubectl describe pods है

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

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

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

ऐप को टर्मिनल में दिखाएं

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

kubectl proxy

अब फिर से, हम पॉड नाम प्राप्त करेंगे और उस पॉड को सीधे प्रॉक्सी के माध्यम से क्वेरी करेंगे। पॉड नाम प्राप्त करने और उसे POD_NAME पर्यावरण चर में संग्रहीत करने के लिए:

export POD_NAME='$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{'\n'}} {{end}}')"
echo "Name of Pod: $POD_NAME"

हमारे एप्लिकेशन का आउटपुट देखने के लिए, curl अनुरोध चलाएँ:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

url पॉड के एपीआई का मार्ग है।

कंटेनर लॉग देखें

कुछ भी जो एप्लिकेशन सामान्य रूप से मानक आउटपुट पर भेजता है वह पॉड के भीतर कंटेनर के लिए लॉग बन जाता है। हम kubectl logs कमांड का उपयोग करके इन लॉग्स को पुनः प्राप्त कर सकते हैं:

kubectl logs "$POD_NAME"

नोट : हमें कंटेनर नाम निर्दिष्ट करने की आवश्यकता नहीं है, क्योंकि हमारे पास पॉड के अंदर केवल एक कंटेनर है।

कंटेनर पर कमांड निष्पादित करना

पॉड चालू होने और चलने के बाद हम सीधे कंटेनर पर कमांड निष्पादित कर सकते हैं। इसके लिए, हम exec उपकमांड का उपयोग करते हैं और एक पैरामीटर के रूप में पॉड के नाम का उपयोग करते हैं। आइए पर्यावरण चरों को सूचीबद्ध करें:

kubectl exec "$POD_NAME" -- env

फिर से, यह उल्लेख करने योग्य है कि कंटेनर का नाम स्वयं छोड़ा जा सकता है क्योंकि हमारे पास पॉड में केवल एक ही कंटेनर है।

आगे आइए पॉड के कंटेनर में एक बैश सत्र शुरू करें:

kubectl exec -ti $POD_NAME -- bash

अब हमारे पास कंटेनर पर एक खुला कंसोल है जहां हम अपना NodeJS एप्लिकेशन चलाते हैं। ऐप का सोर्स कोड server.js फ़ाइल में है:

cat server.js

आप curl कमांड चलाकर जांच सकते हैं कि एप्लिकेशन चालू है:

curl http://localhost:8080

ध्यान दें : यहां हमने localhost का उपयोग किया है क्योंकि हमने NodeJS पॉड के अंदर कमांड निष्पादित किया है। यदि आप localhost:8080 से कनेक्ट नहीं हो सकते हैं, तो यह सुनिश्चित करने के लिए जांचें कि आपने kubectl exec कमांड चलाया है और पॉड के भीतर से कमांड लॉन्च कर रहे हैं

अपना कंटेनर कनेक्शन बंद करने के लिए, exit टाइप करें।

उद्देश्य

• कुबेरनेट्स में सर्विस के बारे में जानें
• समझें कि लेबल और लेबल चयनकर्ता ऑब्जेक्ट किसी सर्विस से कैसे संबंधित हैं
• सर्विस का उपयोग करके कुबेरनेट्स क्लस्टर के बाहर किसी एप्लिकेशन को एक्सपोज़ करें

कुबेरनेट्स सर्विसों का अवलोकन

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

कुबेरनेट्स में सर्विस एक अमूर्त है जो पॉड्स के तार्किक सेट और उन्हें एक्सेस करने के लिए एक निति परिभाषित करता है। सर्विस निर्भर पॉड्स के बीच एक युग्मन को सक्षम करती है। सभी कुबेरनेट्स ऑब्जेक्ट्स की तरह YAML (अधिमानित) या JSON का उपयोग करके एक सर्विस को परिभाषित किया जाता है। सर्विस द्वारा लक्षित पॉड्स का सेट आमतौर पर एक लेबल सेलेक्टर द्वारा निर्धारित किया जाता है (नीचे देखें कि आप selector शामिल किए बिना सर्विस क्यों उपयोग करना चाहेंगे।)

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

• क्लस्टर IP (डिफ़ॉल्ट) - क्लस्टर में किसी आंतरिक IP पर सर्विस को एक्सपोज़ करें। यह प्रकार सर्विस को केवल क्लस्टर के भीतर से ही पहुंच योग्य बनाता है।
• नोडपोर्ट - NAT का उपयोग करके क्लस्टर में प्रत्येक चयनित नोड के एक ही पोर्ट पर सेवा को प्रदर्शित करता है। <NodeIP>:<NodePort> का उपयोग करके किसी सेवा को क्लस्टर के बाहर से एक्सेस योग्य बनाता है। क्लस्टरआईपी का सुपरसेट।
• लोड बैलेंसर - मौजूदा क्लाउड (यदि समर्थित हो) में एक बाहरी लोड बैलेंसर बनाता है और सर्विस को एक निश्चित, बाहरी आईपी असाइन करता है। नोडपोर्ट का सुपरसेट।
• एक्सटर्नल-नाम - सेवा को externalName फ़ील्ड (जैसे foo.bar.example.com) की सामग्री से मैप करता है, एक लौटाकर CNAME अपने मान के साथ रिकॉर्ड करें। किसी भी प्रकार का कोई प्रॉक्सी सेट अप नहीं किया गया है। इस प्रकार के लिए v1.7 या उच्चतर kube-dns, या कोरडीएनएस संस्करण 0.0.8 या उच्चतर की आवश्यकता होती है।

विभिन्न प्रकार की सर्विसओं के बारे में अधिक जानकारी स्रोत आईपी का उपयोग करना ट्यूटोरियल में मिल सकती है। एप्लिकेशन को सर्विसओं से जोड़ना भी देखें।

इसके अतिरिक्त, ध्यान दें कि सर्विसओं के साथ कुछ उपयोग के मामले हैं जिनमें विनिर्देश में selector को परिभाषित नहीं करना शामिल है। selector के बिना बनाई गई सर्विस भी अनुरूप एंडपॉइन्ट ऑब्जेक्ट नहीं बनाएगी। यह उपयोगकर्ताओं को विशिष्ट एंडपॉइन्ट के लिए किसी सर्विस को मैन्युअल रूप से मैप करने की अनुमति देता है। एक और संभावना है कि कोई सलेक्टर क्यों नहीं हो सकता है, कि आप सख्ती से type: ExternalName का उपयोग कर रहे हैं।

सेवाएं और लेबल

सेवा पॉड्स के एक सेट पर ट्रैफ़िक को रूट करती है। सेवाएँ अमूर्त हैं जो आपके एप्लिकेशन को प्रभावित किए बिना पॉड्स को कुबेरनेट्स में मरने और दोहराने की अनुमति देती हैं। निर्भर पॉड्स के बीच डिस्कवरी और रूटिंग (जैसे कि किसी एप्लिकेशन में फ्रंटएंड और बैकएंड कंपोनेंट्स) को कुबेरनेट्स सर्विसेज द्वारा नियंत्रित किया जाता है।

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

• डिप्लॉयमेंट,परीक्षण और प्रोडक्शन के लिए वस्तुओं को नामित करें
• संस्करण टैग जोड़ें
• टैग का उपयोग करके ऑब्जेक्ट्स को वर्गीकृत करें

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

एक नई सेवा बनाएं

आइए सत्यापित करें कि हमारा एप्लिकेशन चल रहा है। हम kubectl get कमांड का उपयोग करेंगे और मौजूदा पॉड्स की तलाश करेंगे:

kubectl get pods

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

इसके बाद, आइए अपने क्लस्टर से वर्तमान सेवाओं को सूचीबद्ध करें:

kubectl get services

हमारे पास kubernetes नामक एक सेवा है जो मिनीक्यूब के क्लस्टर शुरू करने पर डिफ़ॉल्ट रूप से बनाई जाती है। एक नई सेवा बनाने और उसे बाहरी ट्रैफ़िक में उजागर करने के लिए हम पैरामीटर के रूप में नोडपोर्ट के साथ एक्सपोज़ कमांड का उपयोग करेंगे।

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --पोर्ट 8080

आइए फिर से get services उपकमांड चलाएँ:

kubectl get services

अब हमारे पास कुबेरनेट्स-बूटकैंप नामक एक चालू सेवा है। यहां हम देखते हैं कि सेवा को एक अद्वितीय क्लस्टर-आईपी, एक आंतरिक पोर्ट और एक बाहरी-आईपी (नोड का आईपी) प्राप्त हुआ।

यह पता लगाने के लिए कि कौन सा पोर्ट बाहरी रूप से खोला गया था (प्रकार: NodePort सेवा के लिए) हम describe service उपकमांड चलाएंगे:

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसमें निर्दिष्ट नोड पोर्ट का मान हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'
echo "NODE_PORT=$NODE_PORT"

अब हम curl, नोड के आईपी पते और बाहरी रूप से उजागर पोर्ट का उपयोग करके परीक्षण कर सकते हैं कि ऐप क्लस्टर के बाहर प्रदर्शित है:

कर्ल http://'$(minikube ip):$NODE_PORT'

http://127.0.0.1:51082
! क्योंकि आप डार्विन पर डॉकर ड्राइवर का उपयोग कर रहे हैं, इसे चलाने के लिए टर्मिनल का खुला होना आवश्यक है।

और हमें सर्वर से प्रतिक्रिया मिलती है। सेवा उजागर हो गई है.

लेबल का उपयोग करना

परिनियोजन ने स्वचालित रूप से हमारे पॉड के लिए एक लेबल बनाया। <कोड>परिनियोजन का वर्णन करें उपकमांड के साथ आप उस लेबल का नाम (कुंजी) देख सकते हैं:

kubectl describe deployments

आइए पॉड्स की हमारी सूची के बारे में पूछताछ करने के लिए इस लेबल का उपयोग करें। हम एक पैरामीटर के रूप में kubectl get pods कमांड का उपयोग -l के साथ करेंगे, जिसके बाद लेबल मान होंगे:

kubectl get pods -l app=kubernetes-bootcamp

मौजूदा सेवाओं को सूचीबद्ध करने के लिए आप ऐसा ही कर सकते हैं:

kubectl get services -l app=kubernetes-bootcamp

पॉड का नाम प्राप्त करें और इसे POD_NAME पर्यावरण चर में संग्रहीत करें:

export POD_NAME='$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{'\n'}} {{end}}')"
echo "Name of Pod: $POD_NAME"

नया लेबल लागू करने के लिए हम label उपकमांड का उपयोग करते हैं, जिसके बाद ऑब्जेक्ट प्रकार, ऑब्जेक्ट का नाम और नया लेबल आता है:

kubectl label pods "$POD_NAME" version=v1

यह हमारे पॉड पर एक नया लेबल लागू करेगा (हमने एप्लिकेशन संस्करण को पॉड पर पिन किया है), और हम इसे डिस्क्रिप्शन पॉड कमांड के साथ जांच सकते हैं:

kubectl describe pods "$POD_NAME"

हम यहां देखते हैं कि लेबल अब हमारे पॉड से जुड़ा हुआ है। और अब हम नए लेबल का उपयोग करके पॉड्स की सूची क्वेरी कर सकते हैं:

kubectl get pods -l version=v1

और हम पॉड देखते हैं।

किसी सेवा को हटाना

सेवाओं को हटाने के लिए आप delete service उपकमांड का उपयोग कर सकते हैं। लेबल का उपयोग यहां भी किया जा सकता है:

kubectl delete service -l app=kubernetes-bootcamp

पुष्टि करें कि सेवा समाप्त हो गई है:

kubectl get services

यह पुष्टि करता है कि हमारी सेवा हटा दी गई थी। यह पुष्टि करने के लिए कि मार्ग अब उजागर नहीं हुआ है, आप पहले से उजागर आईपी और पोर्ट को curl कर सकते हैं:

curl http://'$(minikube ip):$NODE_PORT'

यह साबित करता है कि एप्लिकेशन अब क्लस्टर के बाहर से पहुंच योग्य नहीं है। आप पुष्टि कर सकते हैं कि ऐप अभी भी पॉड के अंदर से curl के साथ चल रहा है:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

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

उद्देश्य

• kubectl का उपयोग करके किसी ऐप को स्केल करें।

एक एप्लीकेशन को स्केल करना

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

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

स्केलिंग अवलोकन

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

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

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

डिप्लॉयमेंट को स्केल करना

अपनी तैनाती को सूचीबद्ध करने के लिए, get deployments उपकमांड का उपयोग करें:

kubectl get deployments

आउटपुट इसके समान होना चाहिए:

                NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
                kubernetes-bootcamp   1/1     1            1           11m
                

हमारे पास 1 पॉड होना चाहिए। यदि नहीं, तो कमांड फिर से चलाएँ। इससे पता चलता है:

• NAME क्लस्टर में परिनियोजन के नाम सूचीबद्ध करता है।
• READY वर्तमान/वांछित प्रतिकृतियों का अनुपात दर्शाता है
• UP-TO-DATE उन प्रतिकृतियों की संख्या प्रदर्शित करता है जिन्हें वांछित स्थिति प्राप्त करने के लिए अद्यतन किया गया है।
• AVAILABLE प्रदर्शित करता है कि आपके उपयोगकर्ताओं के लिए एप्लिकेशन की कितनी प्रतिकृतियां उपलब्ध हैं।
• AGE एप्लिकेशन के चलने की अवधि प्रदर्शित करता है।

परिनियोजन द्वारा बनाए गए रेप्लिकासेट को देखने के लिए, चलाएँ:

kubectl get rs

ध्यान दें कि रेप्लिकासेट का नाम हमेशा [DEPLOYMENT-NAME]-[RANDOM-STRING] के रूप में स्वरूपित होता है। यादृच्छिक स्ट्रिंग यादृच्छिक रूप से उत्पन्न होती है और बीज के रूप में पॉड-टेम्पलेट-हैश का उपयोग करती है।

इस आउटपुट के दो महत्वपूर्ण कॉलम हैं:

• DESIRED एप्लिकेशन की प्रतिकृतियों की वांछित संख्या प्रदर्शित करता है, जिसे आप परिनियोजन बनाते समय परिभाषित करते हैं। यह वांछित स्थिति है.
• CURRENT दर्शाता है कि वर्तमान में कितनी प्रतिकृतियां चल रही हैं।

इसके बाद, आइए परिनियोजन को 4 प्रतिकृतियों तक मापें। हम kubectl scale कमांड का उपयोग करेंगे, इसके बाद परिनियोजन प्रकार, नाम और उदाहरणों की वांछित संख्या का उपयोग करेंगे:

kubectl scale deployment/kubernetes-bootcamp --replicas=4

अपनी तैनाती को एक बार फिर से सूचीबद्ध करने के लिए, get deployment का उपयोग करें:

kubectl get deployments

जब परिवर्तन लागू किया गया था, उसकी वजह से हमारे पास अब एप्लिकेशन के 4 उदाहरण उपलब्ध हैं। इसके बाद, आइए देखें कि पॉड्स की संख्या बदली है या नहीं:

kubectl get pods -o wide

अब अलग-अलग ip पते के साथ 4 पॉड हैं। परिवर्तन परिनियोजन ईवेंट लॉग में दर्ज किया गया था। इसे जाँचने के लिए, डिस्क्रिप्शन उपकमांड का उपयोग करें:

kubectl describe deployments/kubernetes-bootcamp

आप इस कमांड के आउटपुट में यह भी देख सकते हैं कि अब 4 प्रतिकृतियां हैं।

लोड संतुलन

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

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसका मान नोड पोर्ट के रूप में हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'

echo NODE_PORT=$NODE_PORT

इसके बाद, हम उजागर आईपी पते और पोर्ट पर एक curl करेंगे। कमांड को कई बार निष्पादित करें:

curl http://"$(minikube ip):$NODE_PORT"

हम प्रत्येक अनुरोध के साथ एक अलग पॉड पर पहुंचते हैं। यह दर्शाता है कि लोड-संतुलन काम कर रहा है।

स्केल डाउन

परिनियोजन को 2 प्रतिकृतियों तक कम करने के लिए, scale उपकमांड को फिर से चलाएँ:

kubectl scale deployment/kubernetes-bootcamp --replicas=2

यह जांचने के लिए परिनियोजन को सूचीबद्ध करें कि क्या परिवर्तन get deployments उपकमांड के साथ लागू किया गया था:

kubectl get deployments

प्रतिकृतियों की संख्या घटकर 2 हो गई। get pods के साथ पॉड्स की संख्या सूचीबद्ध करें:

kubectl get pods -o wide

यह पुष्टि करता है कि 2 पॉड समाप्त कर दिए गए थे।

उद्देश्य

• kubectl का उपयोग करके रोलिंग अपडेट करें।

एप्लिकेशन को अपडेट करना

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

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

रोलिंग अपडेट अवलोकन

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

रोलिंग अपडेट निम्नलिखित क्रियाओं की अनुमति देते हैं:

• किसी एप्लिकेशन को एक एनवायरनमेंट से दूसरे एनवायरनमेंट में प्रचारित करें (कंटेनर इमेज अपडेट के माध्यम से)
• पिछले संस्करणों में रोलबैक करें
• शून्य डाउनटाइम के साथ एप्लीकेशन का निरंतर इंटीग्रेशन और निरंतर डिलीवरी

चलिए अगले भाग पर चलते हैं और अपने एप्लिकेशन को एक नए संस्करण में अपडेट और रोलबैक करते है।

ऐप का संस्करण अपडेट करें

अपनी तैनाती को सूचीबद्ध करने के लिए, get deployments उपकमांड चलाएँ: kubectl get deployments

चल रहे पॉड्स को सूचीबद्ध करने के लिए, get pods उपकमांड चलाएँ:

kubectl get pods

ऐप का वर्तमान छवि संस्करण देखने के लिए, describe pod उपकमांड चलाएँ और image फ़ील्ड देखें:

kubectl describe pods

एप्लिकेशन की छवि को संस्करण 2 में अद्यतन करने के लिए, set image उपकमांड का उपयोग करें, इसके बाद परिनियोजन नाम और नया छवि संस्करण लिखें:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2

कमांड ने आपके ऐप के लिए एक अलग छवि का उपयोग करने के लिए परिनियोजन को सूचित किया और एक रोलिंग अपडेट शुरू किया। नए पॉड्स की स्थिति जांचें, और पुराने पॉड्स को get pods उपकमांड के साथ समाप्त होते हुए देखें:

kubectl get pods

अपडेट सत्यापित करें

सबसे पहले, जांचें कि ऐप चल रहा है या नहीं। उजागर आईपी पते और पोर्ट को खोजने के लिए, describe service कमांड चलाएँ:

kubectl describe services/kubernetes-bootcamp

NODE_PORT नामक एक पर्यावरण चर बनाएं जिसमें निर्दिष्ट नोड पोर्ट का मान हो:

export NODE_PORT='$(kubectl getservices/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')'
echo "NODE_PORT=$NODE_PORT"

इसके बाद, उजागर आईपी और पोर्ट पर curl करें:

curl http://'$(minikube ip):$NODE_PORT'

हर बार जब आप curl कमांड चलाएंगे, तो आप एक अलग पॉड से टकराएंगे। ध्यान दें कि सभी पॉड्स अब नवीनतम संस्करण (v2) चला रहे हैं।

आप rollout status उपकमांड चलाकर भी अपडेट की पुष्टि कर सकते हैं:

kubectl rollout status deployments/kubernetes-bootcamp

ऐप का वर्तमान छवि संस्करण देखने के लिए, describe pod उपकमांड चलाएँ:

kubectl describe pods

आउटपुट के image फ़ील्ड में, सत्यापित करें कि आप नवीनतम छवि संस्करण (v2) चला रहे हैं।

अपडेट वापस रोल करें

आइए एक और अपडेट करें, और v10 के साथ टैग की गई छवि को तैनात करने का प्रयास करें:

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

डिप्लॉयमेंट की स्थिति देखने के लिए get deployments का उपयोग करें:

kubectl get deployments

ध्यान दें कि आउटपुट उपलब्ध पॉड्स की वांछित संख्या सूचीबद्ध नहीं करता है। सभी पॉड्स को सूचीबद्ध करने के लिए get pods उपकमांड चलाएँ:

kubectl get pods

ध्यान दें कि कुछ पॉड्स की स्थिति ImagePullBackOff है।

समस्या के बारे में अधिक जानकारी प्राप्त करने के लिए, describe pod उपकमांड चलाएँ:

kubectl describe pods

प्रभावित पॉड्स के आउटपुट के event अनुभाग में, ध्यान दें कि v10 छवि संस्करण रिपॉजिटरी में मौजूद नहीं था।

परिनियोजन को अपने अंतिम कार्यशील संस्करण में वापस लाने के लिए, rollout undo उपकमांड का उपयोग करें:

kubectl rollout undo deployment/kubernetes-bootcamp

rollout undo कमांड परिनियोजन को पिछली ज्ञात स्थिति (छवि का v2) में वापस कर देता है। अद्यतन संस्करणित हैं और आप परिनियोजन की किसी भी पूर्व ज्ञात स्थिति पर वापस लौट सकते हैं।

पॉड्स को फिर से सूचीबद्ध करने के लिए get pods उपकमांड का उपयोग करें:

kubectl get pods

चार पॉड्स चल रहे हैं। इन पॉड्स पर तैनात छवि की जांच करने के लिए, <कोड>describe pods उपकमांड का उपयोग करें:

kubectl describe pods

परिनियोजन एक बार फिर ऐप के स्थिर संस्करण (v2) का उपयोग कर रहा है। रोलबैक सफल रहा.

अपने स्थानीय क्लस्टर को साफ़ करना याद रखें

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp