कुबर्नेट्स कंटेनर्ससाठी सर्वोत्तम पद्धती: आरोग्य तपासणी

TL; डॉ

• कंटेनर आणि मायक्रो सर्व्हिसेसची उच्च निरीक्षणक्षमता प्राप्त करण्यासाठी, लॉग आणि प्राथमिक मेट्रिक्स पुरेसे नाहीत.
• जलद पुनर्प्राप्तीसाठी आणि वाढीव लवचिकतेसाठी, अॅप्लिकेशन्सने उच्च निरीक्षणक्षमता तत्त्व (HOP) लागू केले पाहिजे.
• ऍप्लिकेशन स्तरावर, NOP ला आवश्यक आहे: योग्य लॉगिंग, क्लोज मॉनिटरिंग, सॅनिटी चेक आणि परफॉर्मन्स/ट्रान्झिशन ट्रेसिंग.
• NOR चे घटक म्हणून चेक वापरा तयारीप्रोब и livenessProbe कुबर्नेट्स.

आरोग्य तपासणी टेम्पलेट म्हणजे काय?

मिशन-गंभीर आणि अत्यंत उपलब्ध अनुप्रयोगाची रचना करताना, दोष सहिष्णुतेसारख्या पैलूबद्दल विचार करणे खूप महत्वाचे आहे. एखादे ऍप्लिकेशन फॉल्ट टॉलरंट मानले जाते जर ते अपयशातून लवकर बरे झाले. ठराविक क्लाउड ऍप्लिकेशन मायक्रोसर्व्हिसेस आर्किटेक्चर वापरते - जिथे प्रत्येक घटक वेगळ्या कंटेनरमध्ये ठेवला जातो. आणि जेव्हा तुम्ही क्लस्टर डिझाईन करता तेव्हा k8s वरील ऍप्लिकेशन मोठ्या प्रमाणात उपलब्ध आहे याची खात्री करण्यासाठी, तुम्हाला काही पॅटर्न फॉलो करणे आवश्यक आहे. त्यापैकी आरोग्य तपासणी साचा आहे. अनुप्रयोग k8s ला ते निरोगी असल्याचे कसे संप्रेषण करते हे ते परिभाषित करते. हे केवळ पॉड चालू आहे की नाही याबद्दल माहिती नाही, तर ती विनंती कशी प्राप्त करते आणि प्रतिसाद देते याबद्दल देखील आहे. कुबर्नेट्सना पॉडच्या आरोग्याविषयी जितके अधिक माहिती असते, तितकेच ते ट्रॅफिक मार्ग आणि लोड बॅलेंसिंगबद्दल अधिक हुशार निर्णय घेतात. अशाप्रकारे, उच्च निरीक्षणक्षमता तत्त्व अर्जाला वेळेवर विनंतीला प्रतिसाद देण्यास अनुमती देते.

उच्च निरीक्षणक्षमता तत्त्व (HOP)

उच्च निरीक्षणक्षमतेचे तत्त्व हे त्यापैकी एक आहे कंटेनरीकृत अनुप्रयोग डिझाइन करण्यासाठी तत्त्वे. मायक्रोसर्व्हिसेस आर्किटेक्चरमध्ये, सेवा त्यांच्या विनंतीवर प्रक्रिया कशी केली जाते याची काळजी घेत नाही (आणि योग्यच), परंतु त्यांना प्राप्त झालेल्या सेवांकडून प्रतिसाद कसा मिळतो हे महत्त्वाचे आहे. उदाहरणार्थ, वापरकर्त्याचे प्रमाणीकरण करण्यासाठी, एक कंटेनर दुसर्‍याला HTTP विनंती पाठवतो, एका विशिष्ट स्वरूपात प्रतिसादाची अपेक्षा करतो - इतकेच. PythonJS विनंतीवर प्रक्रिया देखील करू शकते आणि Python Flask प्रतिसाद देऊ शकते. कंटेनर एकमेकांना लपविलेल्या सामग्रीसह ब्लॅक बॉक्ससारखे असतात. तथापि, NOP तत्त्वानुसार प्रत्येक सेवेला एकाधिक API एंडपॉइंट्स उघड करणे आवश्यक आहे जे ते किती निरोगी आहे, तसेच त्याची तयारी आणि दोष सहिष्णुता स्थिती दर्शवते. राउटिंग आणि लोड बॅलन्सिंगसाठी पुढील चरणांचा विचार करण्यासाठी कुबर्नेट्स या निर्देशकांची विनंती करतात.

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

Kubernetes मध्ये आरोग्य तपासणी नमुना कसा लागू करावा?

बॉक्सच्या बाहेर, k8s एका नियंत्रकाचा वापर करून पॉड्सच्या स्थितीचे निरीक्षण करते (तैनात, प्रतिकृती सेट, डेमनसेट, स्टेटफुल सेट इ., इ.). पॉड काही कारणास्तव खाली पडल्याचे आढळून आल्यावर, कंट्रोलर ते रीस्टार्ट करण्याचा किंवा दुसर्‍या नोडवर हलवण्याचा प्रयत्न करतो. तथापि, एक पॉड तक्रार करू शकतो की ते चालू आहे, परंतु ते स्वतः कार्य करत नाही. चला एक उदाहरण देऊ: तुमचा अनुप्रयोग Apache वेब सर्व्हर म्हणून वापरतो, तुम्ही क्लस्टरच्या अनेक पॉड्सवर घटक स्थापित केला आहे. लायब्ररी चुकीच्या पद्धतीने कॉन्फिगर केल्यामुळे, अनुप्रयोगाच्या सर्व विनंत्या कोड 500 (अंतर्गत सर्व्हर त्रुटी) सह प्रतिसाद देतात. डिलिव्हरी तपासताना, पॉड्सची स्थिती तपासणे यशस्वी परिणाम देते, परंतु ग्राहक वेगळ्या पद्धतीने विचार करतात. आम्ही या अवांछित परिस्थितीचे खालीलप्रमाणे वर्णन करू:

आमच्या उदाहरणात, k8s करतो कार्यक्षमता तपासणी. या प्रकारच्या पडताळणीमध्ये, कुबेलेट कंटेनरमधील प्रक्रियेची स्थिती सतत तपासते. प्रक्रिया थांबली आहे हे समजल्यानंतर तो पुन्हा सुरू करेल. जर फक्त ऍप्लिकेशन रीस्टार्ट करून त्रुटीचे निराकरण केले जाऊ शकते आणि प्रोग्राम कोणत्याही त्रुटीवर बंद करण्यासाठी डिझाइन केला असेल, तर तुम्हाला NOP आणि आरोग्य चाचणी पॅटर्नचे पालन करण्याची प्रक्रिया आरोग्य तपासणी करणे आवश्यक आहे. फक्त खेदाची गोष्ट म्हणजे रीस्टार्ट करून सर्व त्रुटी दूर होत नाहीत. या प्रकरणात, k8s पॉडमधील समस्या ओळखण्यासाठी 2 सखोल मार्ग ऑफर करते: livenessProbe и तयारीप्रोब.

LivenessProbe

दरम्यान livenessProbe कुबेलेट 3 प्रकारच्या तपासण्या करते: पॉड चालू आहे की नाही हे केवळ निर्धारित करत नाही, तर ते विनंत्या प्राप्त करण्यास आणि त्यांना पुरेसा प्रतिसाद देण्यासाठी तयार आहे की नाही हे देखील ठरवते:

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

हे कसे कार्य करते याचे उदाहरण. पुढील पॉड डेफिनिशनमध्ये 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 च्या बाबतीत, प्रतिसाद उपलब्धता तपासणी ट्रिगर केली जाते (timeoutSeconds check parameter द्वारे), ज्यानंतर kubelet कंटेनर रीस्टार्ट करते. सुरू केल्यावर, कंटेनर संसाधन-केंद्रित कार्ये करण्यास सुरवात करतो आणि पुन्हा रीस्टार्ट होतो. ज्या अनुप्रयोगांना प्रतिसादाची गती आवश्यक आहे त्यांच्यासाठी हे गंभीर असू शकते. उदाहरणार्थ, कार रस्त्यावर असताना सर्व्हरकडून प्रतिसादाची वाट पाहत आहे, प्रतिसादास उशीर झाला आहे - आणि कार अपघातात पडते.

चला एक रेडिनेसप्रोब व्याख्या लिहूया जी 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("Hellon");
   })
});

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

TL; डॉ
क्लाउड ऍप्लिकेशन्सच्या आगमनापूर्वी, लॉग हे ऍप्लिकेशनचे आरोग्य निरीक्षण आणि तपासण्याचे प्राथमिक माध्यम होते. मात्र, सुधारात्मक कारवाई करण्याचे कोणतेही साधन नव्हते. लॉग आजही उपयुक्त आहेत; आणीबाणीच्या परिस्थितीचे विश्लेषण करण्यासाठी आणि निर्णय घेण्यासाठी ते गोळा करणे आणि लॉग संग्रह प्रणालीकडे पाठवणे आवश्यक आहे. [हे सर्व मोनिट वापरून क्लाउड ऍप्लिकेशन्सशिवाय केले जाऊ शकते, उदाहरणार्थ, परंतु k8 सह ते खूप सोपे झाले :) - संपादकाची टीप. ]

आज, दुरुस्त्या जवळजवळ रिअल टाईममध्ये कराव्या लागतील, त्यामुळे अनुप्रयोगांना यापुढे ब्लॅक बॉक्स बनवण्याची गरज नाही. नाही, त्यांनी एंडपॉइंट्स दाखवले पाहिजेत जे मॉनिटरिंग सिस्टमला प्रक्रियेच्या स्थितीबद्दल प्रश्न आणि मौल्यवान डेटा गोळा करण्यास अनुमती देतात जेणेकरून ते आवश्यक असल्यास त्वरित प्रतिसाद देऊ शकतील. याला परफॉर्मन्स टेस्ट डिझाईन पॅटर्न म्हणतात, जो उच्च निरीक्षणक्षमतेच्या तत्त्वाचे (HOP) पालन करतो.

Kubernetes बाय डीफॉल्ट 2 प्रकारच्या आरोग्य तपासणी ऑफर करते: रेडिनेसप्रोब आणि लिव्हनेसप्रोब. दोघेही समान प्रकारचे चेक वापरतात (HTTP GET विनंत्या, TCP कम्युनिकेशन्स आणि कमांड एक्झिक्यूशन). शेंगामधील समस्यांना प्रतिसाद म्हणून ते कोणते निर्णय घेतात यावरून ते वेगळे आहेत. livenessProbe ही त्रुटी पुन्हा होणार नाही या आशेने कंटेनर रीस्टार्ट करते आणि समस्येचे कारण सुटेपर्यंत ReadinessProbe पॉडला इनकमिंग ट्रॅफिकपासून वेगळे करते.

योग्य ऍप्लिकेशन डिझाइनमध्ये दोन्ही प्रकारच्या तपासणीचा समावेश असावा आणि त्यांनी पुरेसा डेटा संकलित केल्याची खात्री करावी, विशेषत: जेव्हा अपवाद टाकला जातो. हे आवश्यक एपीआय एंडपॉइंट्स देखील दर्शवले पाहिजे जे मॉनिटरिंग सिस्टम (प्रोमेथियस) प्रदान करतात महत्त्वपूर्ण आरोग्य मेट्रिक्स.

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