कुबेरनेट कंटेनर के लिए सर्वोत्तम प्रथाएँ: स्वास्थ्य जाँच

टीएल, डॉ

• कंटेनर और माइक्रोसर्विस के उच्च अवलोकन को प्राप्त करने के लिए, पत्रिकाओं और प्राथमिक मैट्रिक्स पर्याप्त नहीं है।
• तेजी से वसूली और बढ़ी हुई गलती को सहन करने के लिए, अनुप्रयोगों को उच्च अवलोकन सिद्धांत (HOP) को लागू करना चाहिए।
• आवेदन स्तर पर, एनआरए की आवश्यकता होती है: उचित लॉगिंग, सावधान निगरानी, ​​स्वास्थ्य जांच और प्रदर्शन / संक्रमण अनुरेखण।
• HOP तत्व के रूप में readinessProbe और livenessProbe Kubernetes चेक का उपयोग करें।

हेल्थ चेक टेम्प्लेट क्या है?

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

उच्च अवलोकन का सिद्धांत (NRA)

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

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

कुबेरनेट में स्वास्थ्य जांच पैटर्न कैसे लागू करें?

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

हमारे उदाहरण में, k8 एक स्वास्थ्य जांच करता है । इस प्रकार की जांच में, क्यूबलेट कंटेनर में प्रक्रिया की स्थिति की लगातार जांच करता है। एक बार जब वह समझता है कि प्रक्रिया तेज हो गई है, तो वह इसे फिर से शुरू करेगा। यदि त्रुटि केवल एप्लिकेशन को पुनरारंभ करने से समाप्त हो जाती है, और कोई त्रुटि होने पर प्रोग्राम को बंद करने के लिए डिज़ाइन किया गया है, तो एनआरए और हेल्थ चेक टेम्पलेट का पालन करने के लिए, एक प्रक्रिया स्वास्थ्य जांच पर्याप्त है। यह अफ़सोस की बात है कि पुनः आरंभ करने से सभी त्रुटियां समाप्त नहीं होती हैं। इस मामले के लिए, k8s एक पॉड का निवारण करने के लिए 2 गहरे तरीके प्रदान करता है: linyProbe और readinessProbe ।

LivenessProbe

LivenessProbe के दौरान , क्यूबलेट 3 प्रकार के चेक करता है: यह न केवल यह पता लगाता है कि क्या पॉड काम करता है, लेकिन क्या यह प्राप्त करने के लिए तैयार है और अनुरोधों का पर्याप्त रूप से जवाब देता है:

• फली के लिए एक HTTP अनुरोध सेट करें। प्रतिक्रिया में 200 से 399 तक सीमा में HTTP प्रतिक्रिया कोड होना चाहिए। इस प्रकार, 5xx और 4xx कोड इंगित करते हैं कि फली में समस्या है, भले ही प्रक्रिया चल रही हो।
• गैर-HTTP सेवाओं (उदाहरण के लिए, पोस्टफिक्स मेल सर्वर) के साथ पॉड्स की जांच करने के लिए, आपको एक टीसीपी कनेक्शन स्थापित करना होगा।
• फली के लिए एक मनमाना आदेश का निष्पादन (आंतरिक रूप से)। यदि कमांड एग्जिट कोड 0 है तो सत्यापन सफल माना जाता है।

यह कैसे काम करता है इसका एक उदाहरण। निम्न पॉड की परिभाषा में एक NodeJS एप्लिकेशन है जो HTTP अनुरोधों के लिए 500 की एक त्रुटि देता है। यह सुनिश्चित करने के लिए कि इस तरह की त्रुटि प्राप्त करने के बाद कंटेनर पुनरारंभ होता है, हम linyProbe पैरामीटर का उपयोग करते हैं:

apiVersion: v1 kind: Pod metadata: name: node500 spec: containers: - image: magalix/node500 name: node500 ports: - containerPort: 3000 protocol: TCP livenessProbe: httpGet: path: / port: 3000 initialDelaySeconds: 5 

यह किसी भी अन्य .spec.containers.livenessProbe परिभाषा से अलग नहीं है, लेकिन हम एक .spec.containers.livenessProbe ऑब्जेक्ट जोड़ते हैं। httpGet पैरामीटर उस मार्ग को स्वीकार करता है जहां HTTP GET अनुरोध भेजा गया है (हमारे उदाहरण में, यह / , लेकिन युद्ध के परिदृश्यों में भी कुछ ऐसा हो सकता है जैसे /api/v1/status )। अभी भी initialDelaySeconds पैरामीटर को स्वीकार करता है, जो सत्यापन ऑपरेशन को निर्दिष्ट संख्या में सेकंड के लिए प्रतीक्षा करने का निर्देश देता है। देरी की आवश्यकता है क्योंकि कंटेनर को शुरू करने के लिए समय की आवश्यकता होती है, और जब यह पुनरारंभ होता है तो यह कुछ समय के लिए अनुपलब्ध रहेगा।

इस सेटिंग को क्लस्टर में लागू करने के लिए, उपयोग करें:

 kubectl apply -f pod.yaml 

कुछ सेकंड के बाद, आप निम्न कमांड के साथ फली की सामग्री की जांच कर सकते हैं:

 kubectl describe pods node500 

आउटपुट के अंत में निम्नलिखित खोजें।

जैसा कि आप देख सकते हैं, linyProbe ने HTTP GET अनुरोध शुरू किया, कंटेनर ने एक त्रुटि 500 ​​(जिसके लिए प्रोग्राम किया गया था) उत्पन्न की, क्यूबलेट ने इसे पुनः आरंभ किया।

यदि आप रुचि रखते हैं कि NideJS एप्लिकेशन को कैसे प्रोग्राम किया गया था, तो यहां app.js और Dockerfile दिए गए हैं:

app.js

 var http = require('http'); var server = http.createServer(function(req, res) { res.writeHead(500, { "Content-type": "text/plain" }); res.end("We have run into an error\n"); }); server.listen(3000, function() { console.log('Server is running at 3000') }) 

Dockerfile

 FROM node COPY app.js / EXPOSE 3000 ENTRYPOINT [ "node","/app.js" ] 

इस पर ध्यान देना महत्वपूर्ण है: livenessProbe केवल विफलता के मामले में कंटेनर को पुनरारंभ करेगा। यदि पुनरारंभ उस त्रुटि को ठीक नहीं करता है जो कंटेनर के संचालन में हस्तक्षेप करता है, तो क्यूबलेट खराबी को खत्म करने के लिए उपाय करने में सक्षम नहीं होगा।

readinessProbe

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

आइए एक readinessProbe परिभाषा लिखें जो GET अनुरोध के लिए प्रतिक्रिया का समय दो सेकंड से अधिक नहीं सेट करता है, और एप्लिकेशन 5 सेकंड में GET अनुरोध का जवाब देगा। Pod.yaml फ़ाइल को इस तरह दिखना चाहिए:

 apiVersion: v1 kind: Pod metadata: name: nodedelayed spec: containers: - image: afakharany/node_delayed name: nodedelayed ports: - containerPort: 3000 protocol: TCP readinessProbe: httpGet: path: / port: 3000 timeoutSeconds: 2 

Kubectl के साथ फली का विस्तार करें:

 kubectl apply -f pod.yaml 

कुछ सेकंड रुकें, और फिर देखें कि तत्परता कैसे काम करती है:

 kubectl describe pods nodedelayed 

निष्कर्ष के अंत में, आप देख सकते हैं कि कुछ घटनाएँ इसी के समान हैं।

जैसा कि आप देख सकते हैं, स्कैन समय 2 सेकंड से अधिक होने पर kubectl ने पॉड को पुनरारंभ नहीं किया। इसके बजाय, उसने अनुरोध रद्द कर दिया। आने वाले कनेक्शन को अन्य, काम करने वाले पॉड्स पर पुनर्निर्देशित किया जाता है।

नोट: अब जब फली से अतिरिक्त भार हटा दिया गया है, तो kubectl इसे फिर से अनुरोध भेजता है: GET अनुरोध की प्रतिक्रियाओं में अब देरी नहीं हुई है।

तुलना के लिए: निम्नलिखित संशोधित app.js फ़ाइल है:

 var http = require('http'); var server = http.createServer(function(req, res) { const sleep = (milliseconds) => { return new Promise(resolve => setTimeout(resolve, milliseconds)) } sleep(5000).then(() => { res.writeHead(200, { "Content-type": "text/plain" }); res.end("Hello\n"); }) }); server.listen(3000, function() { console.log('Server is running at 3000') }) 

टीएल, डॉ
क्लाउड-आधारित अनुप्रयोगों के आगमन से पहले, लॉग अनुप्रयोगों की स्थिति की निगरानी और जांच करने का मुख्य साधन थे। हालाँकि, कोई समस्या निवारण कदम उठाने का कोई साधन नहीं था। लॉग आज उपयोगी हैं, उन्हें एकत्र किया जाना चाहिए और आपातकालीन स्थितियों और निर्णय लेने के विश्लेषण के लिए लॉग असेंबली प्रणाली में भेजा जाना चाहिए। [ यह सब उदाहरण के लिए, monit का उपयोग करके क्लाउड एप्लिकेशन के बिना किया जा सकता है, लेकिन k8 के साथ यह बहुत आसान हो गया है :) - एड। ]

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

डिफ़ॉल्ट रूप से कुबेरनेट्स 2 प्रकार के स्वास्थ्य जांच प्रदान करता है: तत्परताप्रणाली और linyProbe। दोनों एक ही प्रकार के चेक (HTTP जीईटी अनुरोध, टीसीपी संचार और कमांड निष्पादन) का उपयोग करते हैं। वे उन स्थितियों में भिन्न होते हैं जो फली में समस्याओं के जवाब में किए जाते हैं। linyProbe कंटेनर को इस उम्मीद में पुनः आरंभ करता है कि त्रुटि दोबारा नहीं होगी, और readinessProbe आने वाली ट्रैफ़िक से पॉड को अलग कर देता है जब तक कि समस्या का कारण हल न हो जाए।

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