डाउनटाइमशिवाय कुबर्नेट्स क्लस्टर अपग्रेड करणे

तुमच्या Kubernetes क्लस्टरसाठी अपग्रेड प्रक्रिया

काही ठिकाणी, कुबर्नेट्स क्लस्टर वापरताना, चालू नोड्स अपडेट करण्याची आवश्यकता असते. यात पॅकेज अद्यतने, कर्नल अद्यतने, किंवा नवीन व्हर्च्युअल मशीन प्रतिमांचा समावेश असू शकतो. Kubernetes च्या परिभाषेत याला म्हणतात "स्वैच्छिक व्यत्यय".

ही पोस्ट 4-पोस्ट मालिकेचा भाग आहे:

1. ही पोस्ट.
2. कुबर्नेट्स क्लस्टरमधील शेंगा योग्यरित्या बंद करा
3. पॉड हटवल्यावर विलंबित समाप्ती
4. PodDisruptionBudgets वापरून Kubernetes क्लस्टर डाउनटाइम कसे टाळावे

(अंदाजे. नजीकच्या भविष्यात मालिकेतील उर्वरित लेखांचे भाषांतर अपेक्षित आहे)

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

समस्या परिभाषित करीत आहे

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

आपला प्रवास सुरू करण्यासाठी, एक ठोस उदाहरण घेऊ. समजा आमच्याकडे दोन नोड्सचा कुबर्नेट्स क्लस्टर आहे, ज्यामध्ये मागे दोन पॉड्स असलेले ॲप्लिकेशन चालू आहे. Service:

चला Nginx सह दोन पॉड्स आणि आमच्या दोन Kubernetes क्लस्टर नोड्सवर चालणाऱ्या सर्व्हिससह सुरुवात करूया.

आम्हाला आमच्या क्लस्टरमधील दोन वर्कर नोड्सची कर्नल आवृत्ती अपडेट करायची आहे. आम्ही हे कसे करू? अद्ययावत कॉन्फिगरेशनसह नवीन नोड्स बूट करणे आणि नंतर नवीन सुरू करताना जुने नोड्स बंद करणे हा एक सोपा उपाय आहे. हे कार्य करत असताना, या दृष्टिकोनात काही समस्या असतील:

• जेव्हा तुम्ही जुने नोड्स बंद करता तेव्हा त्यावर चालणारे पॉड्सही बंद होतील. डौलदार शटडाउनसाठी शेंगा साफ करणे आवश्यक असल्यास काय? तुम्ही वापरत असलेली व्हर्च्युअलायझेशन प्रणाली क्लीनअप प्रक्रिया पूर्ण होण्याची प्रतीक्षा करू शकत नाही.
• आपण एकाच वेळी सर्व नोड्स बंद केल्यास काय? जेव्हा शेंगा नवीन नोड्सवर जातात तेव्हा तुम्हाला चांगला डाउनटाइम मिळेल.

आम्ही नोडमध्ये बदल करत असताना आमच्या कार्यकर्त्यांची कोणतीही प्रक्रिया चालू नसल्याची खात्री करून त्याच्या जुन्या नोडस्मधून पॉड स्थानांतरित करण्याचा मार्ग आम्हाला हवा आहे. किंवा जेव्हा आम्ही क्लस्टरची संपूर्ण बदली करतो, जसे की उदाहरणाप्रमाणे (म्हणजेच, आम्ही VM प्रतिमा बदलतो), आम्हाला जुन्या नोड्समधून नवीन नोड्समध्ये चालू असलेले अनुप्रयोग हस्तांतरित करायचे आहेत. दोन्ही प्रकरणांमध्ये, आम्हाला जुन्या नोड्सवर शेड्यूल करण्यापासून नवीन पॉड्स प्रतिबंधित करायचे आहेत, आणि नंतर त्यांच्यापासून सर्व चालू पॉड्स बाहेर काढायचे आहेत. ही उद्दिष्टे साध्य करण्यासाठी आपण कमांड वापरू शकतो kubectl drain.

नोडमधून सर्व शेंगा पुन्हा वितरित करणे

ड्रेन ऑपरेशन आपल्याला नोडमधून सर्व शेंगा पुन्हा वितरित करण्यास अनुमती देते. ड्रेन एक्झिक्युशन दरम्यान, नोड अनुसूचित (ध्वज) म्हणून चिन्हांकित केला जातो NoSchedule). त्यामुळे त्यावर नवीन शेंगा येण्यापासून प्रतिबंध होतो. मग ड्रेन नोडमधून शेंगा बाहेर काढण्यास सुरवात करते, सध्या नोडवर चालू असलेले कंटेनर बंद करते, सिग्नल पाठवते TERM पॉड मध्ये कंटेनर.

तरी kubectl drain शेंगा बाहेर काढण्याचे उत्तम काम करेल, आणखी दोन घटक आहेत ज्यामुळे ड्रेन ऑपरेशन अयशस्वी होऊ शकते:

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

डाउनटाइम टाळत आहे

ऐच्छिक व्यत्ययापासून डाउनटाइम कमी करण्यासाठी, जसे की नोडवरील ड्रेन ऑपरेशनमधून, कुबर्नेट्स खालील अपयश हाताळणी पर्याय प्रदान करते:

• ग्रेसफुल समाप्ती
• लाइफसायकल हुक
• PodDisruptionBudgets

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

---
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.

आमच्या ब्लॉगवरील इतर लेख देखील वाचा:

• शून्य डाउनटाइम उपयोजन आणि डेटाबेस
• कुबर्नेट्स: सिस्टम संसाधन व्यवस्थापन कॉन्फिगर करणे इतके महत्त्वाचे का आहे?
• टेकटन पाइपलाइन - कुबर्नेट्स-नेटिव्ह पाइपलाइन
• Nginx साठी डायनॅमिक मॉड्यूल तयार करणे
• Hashicorp Consul च्या Kubernetes Authorization चा परिचय
• क्लिकहाऊसमधून अधिकृततेशिवाय क्लिकहाऊसमध्ये अधिकृततेसह स्थलांतर केल्याने काय झाले?

स्त्रोत: www.habr.com