🥇बिना डाउनटाइम के कुबेरनेट क्लस्टर को अपडेट करना

आपके Kubernetes क्लस्टर के लिए अपग्रेड प्रक्रिया

कुछ बिंदु पर, कुबेरनेट्स क्लस्टर का उपयोग करते समय, चल रहे नोड्स को अपडेट करने की आवश्यकता होती है। इसमें पैकेज अपडेट, कर्नेल अपडेट या नई वर्चुअल मशीन छवियों की तैनाती शामिल हो सकती है। कुबेरनेट्स शब्दावली में इसे कहा जाता है "स्वैच्छिक व्यवधान".

यह पोस्ट 4-पोस्ट श्रृंखला का हिस्सा है:

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

(लगभग। निकट भविष्य में श्रृंखला के शेष लेखों के अनुवाद की उम्मीद है)

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

समस्या की परिभाषा

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

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

आइए हमारे दो Kubernetes क्लस्टर नोड्स पर चलने वाले Nginx और Service वाले दो पॉड्स से शुरुआत करें।

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

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

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

एक नोड से सभी पॉड्स को पुनः वितरित करना

ड्रेन ऑपरेशन आपको एक नोड से सभी पॉड्स को फिर से वितरित करने की अनुमति देता है। नाली निष्पादन के दौरान, नोड को अनिर्धारित (ध्वज) के रूप में चिह्नित किया जाता है NoSchedule). यह उस पर नई फलियाँ आने से रोकता है। फिर ड्रेन पॉड्स को नोड से बाहर निकालना शुरू कर देता है, एक सिग्नल भेजकर वर्तमान में नोड पर चल रहे कंटेनरों को बंद कर देता है TERM फली में कंटेनर.

हालांकि kubectl drain पॉड्स को बाहर निकालने का बहुत अच्छा काम करेगा, दो अन्य कारक हैं जो नाली संचालन के विफल होने का कारण बन सकते हैं:

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

डाउनटाइम से बचना

स्वैच्छिक व्यवधान से डाउनटाइम को कम करने के लिए, जैसे कि किसी नोड पर ड्रेन ऑपरेशन से, कुबेरनेट्स निम्नलिखित विफलता प्रबंधन विकल्प प्रदान करता है:

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

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

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

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

एडब्ल्यूएस और उससे आगे शून्य डाउनटाइम के लिए कुबेरनेट्स क्लस्टर अपडेट के पूरी तरह से कार्यान्वित और परीक्षण किए गए संस्करण के लिए, यहां जाएं Gruntwork.io.

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

स्रोत: www.habr.com

डाउनटाइम के बिना कुबेरनेट्स क्लस्टर का उन्नयन

समस्या की परिभाषा

एक नोड से सभी पॉड्स को पुनः वितरित करना

डाउनटाइम से बचना

हमारे ब्लॉग पर अन्य लेख भी पढ़ें:

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