குபெர்னெட்ஸ் கொள்கலன்களுக்கான சிறந்த நடைமுறைகள்: சுகாதார சோதனைகள்

டிஎல்; DR

• கொள்கலன்கள் மற்றும் மைக்ரோ சர்வீஸ்களின் உயர் கண்காணிப்புத்தன்மையை அடைய, பதிவுகள் மற்றும் முதன்மை அளவீடுகள் போதாது.
• விரைவான மீட்பு மற்றும் அதிகரித்த பின்னடைவுக்கு, பயன்பாடுகள் உயர் கண்காணிப்பு கொள்கையை (HOP) பயன்படுத்த வேண்டும்.
• பயன்பாட்டு மட்டத்தில், NOP க்கு தேவை: முறையான பதிவு, நெருக்கமான கண்காணிப்பு, நல்லறிவு சோதனைகள் மற்றும் செயல்திறன்/மாற்றம் கண்டறிதல்.
• NOR இன் ஒரு அங்கமாக காசோலைகளைப் பயன்படுத்தவும் தயார்நிலை ஆய்வு и உயிருள்ள ஆய்வு குபர்னெட்ஸ்.

ஹெல்த் செக் டெம்ப்ளேட் என்றால் என்ன?

ஒரு பணி-முக்கியமான மற்றும் மிகவும் கிடைக்கக்கூடிய பயன்பாட்டை வடிவமைக்கும் போது, ​​தவறு சகிப்புத்தன்மை போன்ற ஒரு அம்சத்தைப் பற்றி சிந்திக்க மிகவும் முக்கியம். செயலிழப்பிலிருந்து விரைவாக மீண்டால், ஒரு பயன்பாடு தவறு சகிப்புத்தன்மை கொண்டதாகக் கருதப்படுகிறது. ஒரு பொதுவான கிளவுட் பயன்பாடு மைக்ரோ சர்வீஸ் கட்டமைப்பைப் பயன்படுத்துகிறது - அங்கு ஒவ்வொரு கூறுகளும் தனித்தனி கொள்கலனில் வைக்கப்படுகின்றன. நீங்கள் ஒரு கிளஸ்டரை வடிவமைக்கும்போது, ​​k8s இல் உள்ள பயன்பாடு அதிகமாகக் கிடைக்கிறதா என்பதை உறுதிப்படுத்த, நீங்கள் சில வடிவங்களைப் பின்பற்ற வேண்டும். அவற்றில் ஹெல்த் செக் டெம்ப்ளேட் உள்ளது. பயன்பாடு ஆரோக்கியமானது என்பதை k8s உடன் எவ்வாறு தொடர்பு கொள்கிறது என்பதை இது வரையறுக்கிறது. இது பாட் இயங்குகிறதா என்பது பற்றிய தகவல் மட்டுமல்ல, கோரிக்கைகளை அது எவ்வாறு பெறுகிறது மற்றும் பதிலளிக்கிறது என்பது பற்றிய தகவல். குபெர்னெட்டஸ் நெற்றின் ஆரோக்கியத்தைப் பற்றி எவ்வளவு அதிகமாக அறிந்திருக்கிறாரோ, அந்த அளவுக்கு அது போக்குவரத்து வழித்தடங்கள் மற்றும் சுமை சமநிலையைப் பற்றிய சிறந்த முடிவுகளை எடுக்கும். எனவே, உயர் கண்காணிப்பு கோட்பாடு விண்ணப்பத்தை கோரிக்கைகளுக்கு சரியான நேரத்தில் பதிலளிக்க அனுமதிக்கிறது.

உயர் கண்காணிப்பு கோட்பாடு (HOP)

உயர் கவனிப்பு கொள்கை ஒன்று கொள்கலன் பயன்பாடுகளை வடிவமைப்பதற்கான கொள்கைகள். மைக்ரோ சர்வீஸ் கட்டமைப்பில், சேவைகள் தங்கள் கோரிக்கை எவ்வாறு செயலாக்கப்படுகிறது என்பதைக் கவனிப்பதில்லை (மற்றும் அது சரி), ஆனால் பெறும் சேவைகளிலிருந்து அவை எவ்வாறு பதில்களைப் பெறுகின்றன என்பதுதான் முக்கியம். எடுத்துக்காட்டாக, ஒரு பயனரை அங்கீகரிக்க, ஒரு கொள்கலன் மற்றொருவருக்கு HTTP கோரிக்கையை அனுப்புகிறது, ஒரு குறிப்பிட்ட வடிவத்தில் பதிலை எதிர்பார்க்கிறது - அவ்வளவுதான். PythonJS கோரிக்கையையும் செயலாக்க முடியும், மேலும் Python Flask பதிலளிக்க முடியும். கொள்கலன்கள் ஒன்றுக்கொன்று மறைக்கப்பட்ட உள்ளடக்கங்களைக் கொண்ட கருப்புப் பெட்டிகள் போன்றவை. எவ்வாறாயினும், NOP கொள்கையின்படி ஒவ்வொரு சேவையும் பல API இறுதிப்புள்ளிகளை வெளிப்படுத்த வேண்டும், அது எவ்வளவு ஆரோக்கியமானது, அத்துடன் அதன் தயார்நிலை மற்றும் தவறு சகிப்புத்தன்மை நிலை ஆகியவற்றைக் குறிக்கிறது. ரூட்டிங் மற்றும் சுமை சமநிலைக்கான அடுத்த படிகளைப் பற்றி சிந்திக்க குபெர்னெட்டஸ் இந்த குறிகாட்டிகளைக் கோருகிறார்.

நன்கு வடிவமைக்கப்பட்ட கிளவுட் பயன்பாடு அதன் முக்கிய நிகழ்வுகளை நிலையான I/O ஸ்ட்ரீம்களான STDERR மற்றும் STDOUT ஐப் பயன்படுத்தி பதிவு செய்கிறது. அடுத்து ஒரு துணை சேவை, எடுத்துக்காட்டாக filebeat, logstash அல்லது fluentd, ஒரு மையப்படுத்தப்பட்ட கண்காணிப்பு அமைப்பு (உதாரணமாக Prometheus) மற்றும் ஒரு பதிவு சேகரிப்பு அமைப்பு (ELK மென்பொருள் தொகுப்பு) ஆகியவற்றிற்கு பதிவுகளை வழங்கும். ஹெல்த் டெஸ்ட் பேட்டர்ன் மற்றும் உயர் கண்காணிப்பு கொள்கையின்படி கிளவுட் அப்ளிகேஷன் எவ்வாறு செயல்படுகிறது என்பதை கீழே உள்ள வரைபடம் காட்டுகிறது.

குபெர்னெட்டஸில் ஹெல்த் செக் பேட்டர்னை எவ்வாறு பயன்படுத்துவது?

பெட்டிக்கு வெளியே, k8s கட்டுப்படுத்திகளில் ஒன்றைப் பயன்படுத்தி காய்களின் நிலையை கண்காணிக்கிறது (ஆயத்தங்களும், பிரதிசெட்டுகள், டெமான்செட்ஸ், ஸ்டேட்ஃபுல் செட்ஸ் முதலியன, முதலியன). சில காரணங்களால் பாட் விழுந்துவிட்டதைக் கண்டுபிடித்த பிறகு, கட்டுப்படுத்தி அதை மறுதொடக்கம் செய்ய அல்லது மற்றொரு முனைக்கு நகர்த்த முயற்சிக்கிறது. இருப்பினும், ஒரு பாட் அது இயங்குவதாகவும், ஆனால் அது செயல்படவில்லை என்றும் தெரிவிக்கலாம். ஒரு உதாரணம் தருவோம்: உங்கள் பயன்பாடு அப்பாச்சியை இணைய சேவையகமாகப் பயன்படுத்துகிறது, நீங்கள் கிளஸ்டரின் பல காய்களில் கூறுகளை நிறுவியுள்ளீர்கள். நூலகம் தவறாக உள்ளமைக்கப்பட்டதால், பயன்பாட்டிற்கான அனைத்து கோரிக்கைகளும் குறியீடு 500 (உள் சேவையகப் பிழை) மூலம் பதிலளிக்கின்றன. டெலிவரியைச் சரிபார்க்கும் போது, ​​காய்களின் நிலையைச் சரிபார்ப்பது வெற்றிகரமான முடிவை அளிக்கிறது, ஆனால் வாடிக்கையாளர்கள் வித்தியாசமாக நினைக்கிறார்கள். இந்த விரும்பத்தகாத சூழ்நிலையை நாங்கள் பின்வருமாறு விவரிப்போம்:

எங்கள் எடுத்துக்காட்டில், k8s செய்கிறது செயல்பாடு சோதனை. இந்த வகை சரிபார்ப்பில், கொள்கலனில் உள்ள செயல்முறையின் நிலையை குபெலெட் தொடர்ந்து சரிபார்க்கிறது. செயல்முறை நிறுத்தப்பட்டதை அவர் புரிந்துகொண்டவுடன், அவர் அதை மீண்டும் தொடங்குவார். பயன்பாட்டை மறுதொடக்கம் செய்வதன் மூலம் பிழையைத் தீர்க்க முடிந்தால், மேலும் ஏதேனும் பிழை ஏற்பட்டால் அதை மூடும் வகையில் நிரல் வடிவமைக்கப்பட்டிருந்தால், நீங்கள் NOP மற்றும் சுகாதார சோதனை முறையைப் பின்பற்றுவது ஒரு செயல்முறை சுகாதார சோதனை மட்டுமே. ஒரே பரிதாபம் என்னவென்றால், மறுதொடக்கம் செய்வதன் மூலம் எல்லா பிழைகளும் அகற்றப்படுவதில்லை. இந்த வழக்கில், k8s 2 ஆழமான வழிகளில் உள்ள சிக்கல்களைக் கண்டறிய உதவுகிறது: உயிருள்ள ஆய்வு и தயார்நிலை ஆய்வு.

லைவ்னஸ் ப்ரோப்

போது உயிருள்ள ஆய்வு kubelet 3 வகையான காசோலைகளைச் செய்கிறது: பாட் இயங்குகிறதா என்பதைத் தீர்மானிப்பது மட்டுமல்லாமல், கோரிக்கைகளைப் பெறவும் போதுமான அளவு பதிலளிக்கவும் தயாராக உள்ளதா என்பதையும் தீர்மானிக்கிறது:

• பாட்க்கு HTTP கோரிக்கையை அமைக்கவும். பதிலில் 200 முதல் 399 வரையிலான வரம்பில் HTTP மறுமொழிக் குறியீடு இருக்க வேண்டும். எனவே, செயல்முறை இயங்கினாலும், 5xx மற்றும் 4xx குறியீடுகள் பாட் சிக்கல்களை எதிர்கொள்கிறது என்பதைக் குறிக்கிறது.
• HTTP அல்லாத சேவைகளைக் கொண்ட பாட்களைச் சோதிக்க (உதாரணமாக, Postfix அஞ்சல் சேவையகம்), நீங்கள் TCP இணைப்பை நிறுவ வேண்டும்.
• ஒரு பாட் (உள்நாட்டில்) ஒரு தன்னிச்சையான கட்டளையை இயக்கவும். கட்டளை நிறைவு குறியீடு 0 ஆக இருந்தால் சரிபார்ப்பு வெற்றிகரமாக கருதப்படுகிறது.

இது எவ்வாறு செயல்படுகிறது என்பதற்கான எடுத்துக்காட்டு. அடுத்த பாட் வரையறையில் HTTP கோரிக்கைகளில் 500 பிழையை ஏற்படுத்தும் NodeJS பயன்பாடு உள்ளது. அத்தகைய பிழையைப் பெறும்போது கொள்கலன் மறுதொடக்கம் செய்யப்படுவதை உறுதிசெய்ய, 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 ஐ உருவாக்கியது (இதைச் செய்ய திட்டமிடப்பட்டது), மற்றும் kubelet அதை மறுதொடக்கம் செய்தது.

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 அதை மறுதொடக்கம் செய்யும். கன்டெய்னர் இயங்குவதைத் தடுக்கும் பிழையை மறுதொடக்கம் சரி செய்யவில்லை என்றால், சிக்கலைச் சரிசெய்வதற்கு குபெலெட்டால் நடவடிக்கை எடுக்க முடியாது.

தயார்நிலை ஆய்வு

ரெடினெஸ் ப்ரோப் பிழைகாணல் செயல்களைத் தவிர்த்து, livenessProbes (GET கோரிக்கைகள், TCP தகவல்தொடர்புகள் மற்றும் கட்டளை செயல்படுத்தல்) போலவே செயல்படுகிறது. தோல்வி கண்டறியப்பட்ட கொள்கலன் மறுதொடக்கம் செய்யப்படவில்லை, ஆனால் உள்வரும் போக்குவரத்திலிருந்து தனிமைப்படுத்தப்பட்டுள்ளது. கொள்கலன்களில் ஒன்று நிறைய கணக்கீடுகளைச் செய்கிறது அல்லது அதிக சுமையின் கீழ் உள்ளது என்று கற்பனை செய்து பாருங்கள், இதனால் பதில் நேரம் அதிகரிக்கும். livenessProbe விஷயத்தில், மறுமொழி கிடைப்பது சரிபார்ப்பு (timeoutSeconds சரிபார்ப்பு அளவுரு மூலம்) தூண்டப்படுகிறது, அதன் பிறகு kubelet கொள்கலனை மறுதொடக்கம் செய்கிறது. தொடங்கும் போது, ​​கொள்கலன் வள-தீவிர பணிகளைச் செய்யத் தொடங்குகிறது மற்றும் மீண்டும் மீண்டும் தொடங்கப்படுகிறது. பதில் வேகம் தேவைப்படும் பயன்பாடுகளுக்கு இது முக்கியமானதாக இருக்கலாம். எடுத்துக்காட்டாக, ஒரு கார் சாலையில் இருக்கும்போது சேவையகத்தின் பதிலுக்காகக் காத்திருக்கிறது, பதில் தாமதமாகிறது - மேலும் கார் விபத்தில் சிக்குகிறது.

ஒரு rednessProbe வரையறையை எழுதுவோம், அது 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')
})

டிஎல்; DR
கிளவுட் அப்ளிகேஷன்களின் வருகைக்கு முன், பதிவுகள் பயன்பாட்டின் ஆரோக்கியத்தை கண்காணிப்பதற்கும் சரிபார்ப்பதற்கும் முதன்மையான வழிமுறையாக இருந்தன. இருப்பினும், சரிவர நடவடிக்கை எடுக்க வழி இல்லை. பதிவுகள் இன்றும் பயனுள்ளதாக உள்ளன; அவசரகால சூழ்நிலைகளை பகுப்பாய்வு செய்வதற்கும் முடிவுகளை எடுப்பதற்கும் அவை சேகரிக்கப்பட்டு பதிவு சேகரிப்பு அமைப்புக்கு அனுப்பப்பட வேண்டும். [எடுத்துக்காட்டாக, மோனிட்டைப் பயன்படுத்தி கிளவுட் பயன்பாடுகள் இல்லாமல் இவை அனைத்தும் செய்யப்படலாம், ஆனால் k8s உடன் இது மிகவும் எளிதாகிவிட்டது :) - ஆசிரியரின் குறிப்பு. ]

இன்று, திருத்தங்கள் கிட்டத்தட்ட உண்மையான நேரத்தில் செய்யப்பட வேண்டும், எனவே பயன்பாடுகள் இனி கருப்பு பெட்டிகளாக இருக்க வேண்டியதில்லை. இல்லை, செயல்முறைகளின் நிலையைப் பற்றிய மதிப்புமிக்க தரவை வினவவும் சேகரிக்கவும் கண்காணிப்பு அமைப்புகளை அனுமதிக்கும் இறுதிப்புள்ளிகளை அவை காட்ட வேண்டும், இதனால் அவை தேவைப்பட்டால் உடனடியாக பதிலளிக்க முடியும். இது செயல்திறன் சோதனை வடிவமைப்பு முறை என்று அழைக்கப்படுகிறது, இது உயர் கண்காணிப்பு கொள்கையை (HOP) பின்பற்றுகிறது.

குபெர்னெட்டஸ் இயல்பாகவே 2 வகையான உடல்நலப் பரிசோதனைகளை வழங்குகிறது: ரெடினெஸ் ப்ரோப் மற்றும் லைவ்னஸ் ப்ரோப். இரண்டும் ஒரே வகையான காசோலைகளைப் பயன்படுத்துகின்றன (HTTP GET கோரிக்கைகள், TCP தகவல்தொடர்புகள் மற்றும் கட்டளை செயல்படுத்தல்). காய்களில் ஏற்படும் பிரச்சனைகளுக்கு அவர்கள் எடுக்கும் முடிவுகளில் அவர்கள் வேறுபடுகிறார்கள். பிழை மீண்டும் நிகழாது என்ற நம்பிக்கையில் livenessProbe கொள்கலனை மறுதொடக்கம் செய்கிறது, மேலும் ரெடினெஸ் ப்ரோப் பிரச்சனைக்கான காரணம் தீர்க்கப்படும் வரை உள்வரும் போக்குவரத்தில் இருந்து பாடை தனிமைப்படுத்துகிறது.

சரியான பயன்பாட்டு வடிவமைப்பில் இரண்டு வகையான சரிபார்ப்புகளும் இருக்க வேண்டும் மற்றும் அவை போதுமான தரவைச் சேகரிக்கின்றன என்பதை உறுதிப்படுத்த வேண்டும், குறிப்பாக விதிவிலக்கு அளிக்கப்படும் போது. முக்கியமான சுகாதார அளவீடுகளுடன் கண்காணிப்பு அமைப்பை (ப்ரோமிதியஸ்) வழங்கும் தேவையான API இறுதிப்புள்ளிகளையும் இது காட்ட வேண்டும்.

ஆதாரம்: www.habr.com