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

TL, डॉ

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

स्वास्थ्य जांच टेम्पलेट क्या है?

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

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

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

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

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

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

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

जीवंतता जांच

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

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

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

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. पैरामीटर httpGet उस पथ को स्वीकार करता है जिस पर HTTP GET अनुरोध भेजा गया है (हमारे उदाहरण में यह है)। /, लेकिन युद्ध परिदृश्यों में कुछ ऐसा हो सकता है /api/v1/status). एक अन्य लाइवनेसप्रोब एक पैरामीटर स्वीकार करता है initialDelaySeconds, जो सत्यापन ऑपरेशन को निर्दिष्ट सेकंड की प्रतीक्षा करने का निर्देश देता है। विलंब की आवश्यकता है क्योंकि कंटेनर को प्रारंभ होने के लिए समय की आवश्यकता होती है, और पुनः प्रारंभ होने पर यह कुछ समय के लिए अनुपलब्ध रहेगा।

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

kubectl apply -f pod.yaml

कुछ सेकंड के बाद, आप निम्न आदेश का उपयोग करके पॉड की सामग्री की जांच कर सकते हैं:

kubectl describe pods node500

आउटपुट के अंत में, खोजें वही है.

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

यदि आप सोच रहे हैं कि NideJS एप्लिकेशन को कैसे प्रोग्राम किया गया था, तो यहां ऐप.जेएस और डॉकरफाइल का उपयोग किया गया था:

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 errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

Dockerfile

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

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

तत्परता जांच

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

आइए एक redinessProbe परिभाषा लिखें जो 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 सेकंड से अधिक होने पर कुबेक्टल ने पॉड को पुनरारंभ नहीं किया। इसके बजाय, उन्होंने अनुरोध रद्द कर दिया। आने वाले संचार को अन्य, कार्यशील पॉड्स पर पुनर्निर्देशित किया जाता है।

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

तुलना के लिए, नीचे संशोधित ऐप.जेएस फ़ाइल है:

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("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

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

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

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

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

स्रोत: www.habr.com