डाउनटाइम बिना Kubernetes क्लस्टर अपग्रेड गर्दै

तपाईंको Kubernetes क्लस्टरको लागि अपग्रेड प्रक्रिया

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

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

1. यो पोस्ट।
2. Kubernetes क्लस्टरमा पोडहरूको सही बन्द
3. पोड मेटाउँदा ढिलाइ समाप्त हुन्छ
4. PodDisruptionBudgets प्रयोग गरेर Kubernetes क्लस्टर डाउनटाइमबाट कसरी बच्ने

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

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

समस्या परिभाषित गर्दै

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

हाम्रो यात्रा सुरु गर्न, एउटा ठोस उदाहरण लिऔं। मानौं हामीसँग दुई नोडहरूको कुबर्नेट्स क्लस्टर छ, जसमा एउटा एप्लिकेसन चलिरहेको छ जसमा दुई पोडहरू पछाडि अवस्थित छन्। Service:

हाम्रो दुई Kubernetes क्लस्टर नोडहरूमा चलिरहेको Nginx र सेवाको साथ दुई पोडहरू सुरु गरौं।

हामी हाम्रो क्लस्टरमा दुई कार्यकर्ता नोडहरूको कर्नेल संस्करण अपडेट गर्न चाहन्छौं। हामीले यो कसरी गर्ने? एक सरल समाधान अपडेट गरिएको कन्फिगरेसनको साथ नयाँ नोडहरू बुट गर्ने र नयाँ नोडहरू सुरु गर्दा पुरानो नोडहरू बन्द गर्ने हो। यो काम गर्दा, यस दृष्टिकोण संग केहि समस्या हुनेछ:

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

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

नोडबाट सबै पोडहरू पुन: वितरण गर्दै

ड्रेन अपरेशनले तपाईंलाई नोडबाट सबै पोडहरू पुन: वितरण गर्न अनुमति दिन्छ। ड्रेन कार्यान्वयनको क्रममा, नोडलाई अनुसूचित गर्न नसकिने (झण्डा NoSchedule)। यसले यसमा नयाँ पोडहरू देखा पर्नबाट रोक्छ। त्यसपछि ड्रेनले नोडबाट पोडहरू हटाउन थाल्छ, हाल नोडमा चलिरहेका कन्टेनरहरूलाई बन्द गर्दछ, संकेत पठाउँदै। TERM पोडमा कन्टेनरहरू।

यद्यपि kubectl drain पोडहरू हटाउने ठूलो काम गर्नेछ, त्यहाँ दुई अन्य कारकहरू छन् जसले ड्रेन अपरेशन असफल हुन सक्छ:

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

डाउनटाइम बेवास्ता गर्दै

स्वैच्छिक अवरोधबाट डाउनटाइम कम गर्न, जस्तै नोडमा ड्रेन अपरेशनबाट, Kubernetes ले निम्न विफलता ह्यान्डलिंग विकल्पहरू प्रदान गर्दछ:

• आकर्षक समाप्ति
• जीवनचक्र हुकहरू
• PodDisruption Budgets

बाँकी शृङ्खलाहरूमा, हामी पोड माइग्रेसनको प्रभावलाई कम गर्न यी Kubernetes सुविधाहरू प्रयोग गर्नेछौं। मुख्य विचार पछ्याउन सजिलो बनाउनको लागि, हामी निम्न स्रोत कन्फिगरेसनको साथ माथिको हाम्रो उदाहरण प्रयोग गर्नेछौं:

---
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 पोडहरू पहुँच गर्न प्रयोग गर्न सकिन्छ।

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

AWS र बाहिर शून्य डाउनटाइमको लागि Kubernetes क्लस्टर अपडेटहरूको पूर्ण रूपमा कार्यान्वयन गरिएको र परीक्षण गरिएको संस्करणको लागि, भ्रमण गर्नुहोस्। Gruntwork.io.

हाम्रो ब्लगमा अन्य लेखहरू पनि पढ्नुहोस्:

• शून्य डाउनटाइम डिप्लोयमेन्ट र डाटाबेसहरू
• Kubernetes: किन यो प्रणाली संसाधन व्यवस्थापन सेट अप गर्न महत्त्वपूर्ण छ?
• Tekton पाइपलाइन - Kubernetes-स्थानीय पाइपलाइन
• Nginx को लागि गतिशील मोड्युलहरू निर्माण गर्दै
• Hashicorp Consul को Kubernetes प्राधिकरण को परिचय
• प्राधिकरण बिना क्लिकहाउसबाट क्लिकहाउसमा प्राधिकरणको साथ माइग्रेसनले के निम्त्यायो?

स्रोत: www.habr.com