Kubernetes कन्टेनरहरूको लागि उत्तम अभ्यासहरू: स्वास्थ्य जाँचहरू

TL; ड

• कन्टेनर र माइक्रो सर्भिसेसहरूको उच्च अवलोकन योग्यता प्राप्त गर्न, लगहरू र प्राथमिक मेट्रिकहरू पर्याप्त छैनन्।
• छिटो रिकभरी र बढ्दो लचिलोपनको लागि, अनुप्रयोगहरूले उच्च अवलोकन सिद्धान्त (HOP) लागू गर्नुपर्छ।
• आवेदन स्तरमा, NOP लाई आवश्यक छ: उचित लगिङ, नजिकको निगरानी, ​​सेनिटी जाँच, र प्रदर्शन/संक्रमण ट्रेसिङ।
• NOR को तत्वको रूपमा चेकहरू प्रयोग गर्नुहोस् तयारी जाँच и जीवन्तता जाँच Kubernetes।

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

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

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

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

राम्रोसँग डिजाइन गरिएको क्लाउड अनुप्रयोगले मानक I/O स्ट्रिमहरू STDERR र STDOUT प्रयोग गरेर यसको मुख्य घटनाहरू लग गर्दछ। अर्को सहायक सेवा आउँछ, उदाहरणका लागि फाइलबिट, लगस्ट्याश वा फ्लुएन्ट, केन्द्रीकृत निगरानी प्रणाली (उदाहरणका लागि प्रोमेथियस) र लग सङ्कलन प्रणाली (ELK सफ्टवेयर सुइट) मा लगहरू डेलिभर गर्ने। तलको रेखाचित्रले हेल्थ टेस्ट ढाँचा र उच्च अवलोकन सिद्धान्त अनुसार क्लाउड एप्लिकेसनले कसरी काम गर्छ भनेर देखाउँछ।

Kubernetes मा स्वास्थ्य जाँच ढाँचा कसरी लागू गर्ने?

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

हाम्रो उदाहरणमा, k8s गर्छ कार्यक्षमता जाँच। यस प्रकारको प्रमाणीकरणमा, कुबेलेटले कन्टेनरमा प्रक्रियाको अवस्था निरन्तर जाँच गर्दछ। एकचोटि उसले बुझ्यो कि प्रक्रिया रोकिएको छ, उसले यसलाई पुन: सुरु गर्नेछ। यदि त्रुटिलाई केवल एप्लिकेसन पुन: सुरु गरेर समाधान गर्न सकिन्छ, र कार्यक्रम कुनै त्रुटिमा बन्द गर्न डिजाइन गरिएको हो भने, त्यसपछि प्रक्रिया स्वास्थ्य जाँच तपाईंले NOP र स्वास्थ्य परीक्षण ढाँचा पालना गर्न आवश्यक छ। केवल दु:खको कुरा यो हो कि सबै त्रुटिहरू पुन: सुरु गरेर हटाइँदैन। यस अवस्थामा, k8s ले पोडसँग समस्याहरू पहिचान गर्न २ गहिरो तरिकाहरू प्रदान गर्दछ: जीवन्तता जाँच и तयारी जाँच.

LivenessProbe

यस समयमा जीवन्तता जाँच kubelet ले 3 प्रकारका जाँचहरू गर्दछ: पोड चलिरहेको छ कि छैन भनेर मात्र निर्धारण गर्दैन, तर यो अनुरोधहरू प्राप्त गर्न र पर्याप्त रूपमा प्रतिक्रिया दिन तयार छ कि छैन भनेर पनि निर्धारण गर्दछ:

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

यो कसरी काम गर्छ को एक उदाहरण। अर्को पोड परिभाषामा एक NodeJS अनुप्रयोग समावेश छ जसले HTTP अनुरोधहरूमा 500 त्रुटि फ्याँक्छ। यस्तो त्रुटि प्राप्त गर्दा कन्टेनर पुन: सुरु भएको सुनिश्चित गर्न, हामी livenessProbe प्यारामिटर प्रयोग गर्छौं:

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)। अर्को livenessProbe ले प्यारामिटर स्वीकार गर्छ initialDelaySeconds, जसले प्रमाणीकरण कार्यलाई सेकेन्डको निर्दिष्ट संख्या पर्खन निर्देशन दिन्छ। ढिलाइ आवश्यक छ किनभने कन्टेनर सुरु गर्न समय चाहिन्छ, र पुन: सुरु गर्दा यो केहि समयको लागि अनुपलब्ध हुनेछ।

क्लस्टरमा यो सेटिङ लागू गर्न, प्रयोग गर्नुहोस्:

kubectl apply -f pod.yaml

केहि सेकेन्ड पछि, तपाइँ निम्न आदेश प्रयोग गरेर पोडको सामग्री जाँच गर्न सक्नुहुन्छ:

kubectl describe pods node500

आउटपुटको अन्त्यमा, फेला पार्नुहोस् त्यो के हो.

तपाईले देख्न सक्नुहुन्छ, livenessProbe ले 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 errorn");
});

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

डकरफाइल

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

यो नोट गर्न महत्त्वपूर्ण छ: livenessProbe ले कन्टेनरलाई पुन: सुरु गर्नेछ यदि यो असफल भयो भने। यदि पुन: सुरु गर्दा कन्टेनर चल्नबाट रोक्ने त्रुटिलाई सच्याउँदैन भने, कुबेलेटले समस्या समाधान गर्न कार्य गर्न सक्षम हुनेछैन।

तयारी जाँच

ReadinessProbe ले समस्या निवारण कार्यहरू बाहेक livenessProbes (GET अनुरोधहरू, TCP संचार र आदेश कार्यान्वयन) जस्तै काम गर्दछ। कन्टेनर जसमा विफलता पत्ता लगाइएको छ पुन: सुरु गरिएको छैन, तर आगमन ट्राफिकबाट अलग गरिएको छ। कल्पना गर्नुहोस् कि एउटा कन्टेनरले धेरै गणनाहरू गरिरहेको छ वा धेरै भारमा छ, जसले गर्दा प्रतिक्रिया समय बढ्दैछ। LivenessProbe को अवस्थामा, प्रतिक्रिया उपलब्धता जाँच ट्रिगर हुन्छ (टाइमआउट सेकेन्ड जाँच प्यारामिटर मार्फत), जस पछि कुबेलेटले कन्टेनर पुन: सुरु गर्दछ। जब सुरु हुन्छ, कन्टेनरले संसाधन-गहन कार्यहरू गर्न थाल्छ र पुन: सुरु हुन्छ। प्रतिक्रिया गति चाहिने अनुप्रयोगहरूको लागि यो महत्त्वपूर्ण हुन सक्छ। उदाहरणका लागि, सडकमा कार सर्भरबाट प्रतिक्रियाको लागि पर्खिरहेको छ, प्रतिक्रिया ढिलो भएको छ - र कार दुर्घटनामा हुन्छ।

एउटा 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 सेकेन्ड नाघ्यो। बरु, उनले अनुरोध रद्द गरे। आगमन संचारहरू अन्य, काम गर्ने पोडहरूमा पुन: निर्देशित गरिन्छ।

ध्यान दिनुहोस् कि अब पोड अफलोड गरिएको छ, 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("Hellon");
   })
});

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

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

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

Kubernetes ले पूर्वनिर्धारित रूपमा 2 प्रकारका स्वास्थ्य जाँचहरू प्रदान गर्दछ: ReadinessProbe र livenessProbe। दुबैले एउटै प्रकारका चेकहरू प्रयोग गर्छन् (HTTP GET अनुरोधहरू, TCP संचार र आदेश कार्यान्वयन)। पोडहरूमा समस्याहरूको जवाफमा उनीहरूले के निर्णयहरू गर्छन् भन्ने कुरामा तिनीहरू भिन्न हुन्छन्। livenessProbe ले त्रुटि फेरि नहोस् भन्ने आशामा कन्टेनर पुन: सुरु गर्छ, र ReadinessProbe ले समस्याको कारण समाधान नभएसम्म पोडलाई आगमन ट्राफिकबाट अलग गर्छ।

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

स्रोत: www.habr.com