కుబెర్నెట్స్ కంటైనర్‌ల కోసం ఉత్తమ పద్ధతులు: ఆరోగ్య తనిఖీలు

TL; DR

• కంటైనర్లు మరియు మైక్రోసర్వీస్‌ల యొక్క అధిక పరిశీలనను సాధించడానికి, లాగ్‌లు మరియు ప్రాథమిక కొలమానాలు సరిపోవు.
• వేగవంతమైన రికవరీ మరియు పెరిగిన స్థితిస్థాపకత కోసం, అప్లికేషన్‌లు హై అబ్జర్వబిలిటీ ప్రిన్సిపల్ (HOP)ని వర్తింపజేయాలి.
• అప్లికేషన్ స్థాయిలో, NOP అవసరం: సరైన లాగింగ్, క్లోజ్ మానిటరింగ్, శానిటీ చెక్‌లు మరియు పనితీరు/పరివర్తన ట్రేసింగ్.
• NOR యొక్క మూలకం వలె తనిఖీలను ఉపయోగించండి సంసిద్ధత ప్రోబ్ и సజీవతప్రోబ్ కుబెర్నెటీస్.

ఆరోగ్య తనిఖీ టెంప్లేట్ అంటే ఏమిటి?

మిషన్-క్లిష్టమైన మరియు అత్యంత అందుబాటులో ఉన్న అప్లికేషన్‌ను రూపకల్పన చేసేటప్పుడు, తప్పు సహనం వంటి అంశం గురించి ఆలోచించడం చాలా ముఖ్యం. ఒక అప్లికేషన్ వైఫల్యం నుండి త్వరగా కోలుకుంటే అది తప్పును తట్టుకునేదిగా పరిగణించబడుతుంది. ఒక సాధారణ క్లౌడ్ అప్లికేషన్ మైక్రోసర్వీసెస్ ఆర్కిటెక్చర్‌ని ఉపయోగిస్తుంది - ఇక్కడ ప్రతి భాగం ప్రత్యేక కంటైనర్‌లో ఉంచబడుతుంది. మరియు మీరు క్లస్టర్‌ని డిజైన్ చేసినప్పుడు k8sలో అప్లికేషన్ ఎక్కువగా అందుబాటులో ఉందని నిర్ధారించుకోవడానికి, మీరు నిర్దిష్ట నమూనాలను అనుసరించాలి. వాటిలో హెల్త్ చెక్ టెంప్లేట్ ఉంది. అప్లికేషన్ ఆరోగ్యంగా ఉందని k8sకి ఎలా కమ్యూనికేట్ చేస్తుందో ఇది నిర్వచిస్తుంది. ఇది పాడ్ రన్ అవుతుందా లేదా అనే దాని గురించి మాత్రమే కాకుండా, అభ్యర్థనలను ఎలా స్వీకరిస్తుంది మరియు ప్రతిస్పందిస్తుంది అనే దాని గురించి కూడా సమాచారం. కుబెర్నెట్‌లకు పాడ్ ఆరోగ్యం గురించి ఎంత ఎక్కువ తెలుసు, ట్రాఫిక్ రూటింగ్ మరియు లోడ్ బ్యాలెన్సింగ్ గురించి అది తెలివిగా నిర్ణయాలు తీసుకుంటుంది. అందువల్ల, హై అబ్జర్వేబిలిటీ ప్రిన్సిపల్ అప్లికేషన్ సకాలంలో అభ్యర్థనలకు ప్రతిస్పందించడానికి అనుమతిస్తుంది.

అధిక పరిశీలన సూత్రం (HOP)

అధిక పరిశీలన సూత్రం ఒకటి కంటెయినరైజ్డ్ అప్లికేషన్ల రూపకల్పనకు సూత్రాలు. మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లో, సేవలు వారి అభ్యర్థన ఎలా ప్రాసెస్ చేయబడిందో పట్టించుకోవు (మరియు సరిగ్గా అలాగే), కానీ అవి స్వీకరించే సేవల నుండి ప్రతిస్పందనలను ఎలా స్వీకరిస్తాయన్నది ముఖ్యం. ఉదాహరణకు, వినియోగదారుని ప్రామాణీకరించడానికి, ఒక కంటైనర్ మరొకరికి HTTP అభ్యర్థనను పంపుతుంది, నిర్దిష్ట ఆకృతిలో ప్రతిస్పందనను ఆశించడం - అంతే. PythonJS అభ్యర్థనను కూడా ప్రాసెస్ చేయగలదు మరియు పైథాన్ ఫ్లాస్క్ ప్రతిస్పందించగలదు. కంటైనర్లు ఒకదానికొకటి దాచిన కంటెంట్‌లతో బ్లాక్ బాక్స్‌ల వంటివి. ఏదేమైనప్పటికీ, NOP సూత్రం ప్రకారం, ప్రతి సేవ అనేక API ముగింపు పాయింట్‌లను బహిర్గతం చేయడం అవసరం, అది ఎంత ఆరోగ్యకరమైనది, అలాగే దాని సంసిద్ధత మరియు తప్పు సహన స్థితిని సూచిస్తుంది. రూటింగ్ మరియు లోడ్ బ్యాలెన్సింగ్ కోసం తదుపరి దశల గురించి ఆలోచించడం కోసం Kubernetes ఈ సూచికలను అభ్యర్థిస్తుంది.

చక్కగా రూపొందించబడిన క్లౌడ్ అప్లికేషన్ దాని ప్రధాన ఈవెంట్‌లను ప్రామాణిక I/O స్ట్రీమ్‌లు STDERR మరియు STDOUT ఉపయోగించి లాగ్ చేస్తుంది. తదుపరి సహాయక సేవ వస్తుంది, ఉదాహరణకు ఫైల్‌బీట్, లాగ్‌స్టాష్ లేదా ఫ్లూయెంట్, కేంద్రీకృత పర్యవేక్షణ వ్యవస్థ (ఉదాహరణకు ప్రోమేథియస్) మరియు లాగ్ కలెక్షన్ సిస్టమ్ (ELK సాఫ్ట్‌వేర్ సూట్)కి లాగ్‌లను బట్వాడా చేస్తుంది. హెల్త్ టెస్ట్ ప్యాటర్న్ మరియు హై అబ్జర్వేబిలిటీ ప్రిన్సిపల్ ప్రకారం క్లౌడ్ అప్లికేషన్ ఎలా పనిచేస్తుందో దిగువ రేఖాచిత్రం చూపుతుంది.

కుబెర్నెట్స్‌లో ఆరోగ్య తనిఖీ నమూనాను ఎలా దరఖాస్తు చేయాలి?

పెట్టె వెలుపల, k8s కంట్రోలర్‌లలో ఒకదానిని ఉపయోగించి పాడ్‌ల స్థితిని పర్యవేక్షిస్తుంది (నియోగించడం, రెప్లికాసెట్స్, డెమోన్‌సెట్స్, స్టేట్‌ఫుల్ సెట్‌లు మొదలైనవి, మొదలైనవి). కొన్ని కారణాల వల్ల పాడ్ పడిపోయిందని కనుగొన్న తర్వాత, కంట్రోలర్ దానిని పునఃప్రారంభించడానికి లేదా మరొక నోడ్‌కి తరలించడానికి ప్రయత్నిస్తుంది. అయితే, ఒక పాడ్ అది అప్ మరియు రన్ అవుతుందని నివేదించవచ్చు, కానీ అది పని చేయడం లేదు. ఒక ఉదాహరణ ఇద్దాం: మీ అప్లికేషన్ అపాచీని వెబ్ సర్వర్‌గా ఉపయోగిస్తుంది, మీరు క్లస్టర్‌లోని అనేక పాడ్‌లలో కాంపోనెంట్‌ను ఇన్‌స్టాల్ చేసారు. లైబ్రరీ తప్పుగా కాన్ఫిగర్ చేయబడినందున, అప్లికేషన్‌కి సంబంధించిన అన్ని అభ్యర్థనలు కోడ్ 500 (అంతర్గత సర్వర్ లోపం)తో ప్రతిస్పందిస్తాయి. డెలివరీని తనిఖీ చేస్తున్నప్పుడు, పాడ్‌ల స్థితిని తనిఖీ చేయడం విజయవంతమైన ఫలితాన్ని ఇస్తుంది, కానీ కస్టమర్‌లు భిన్నంగా ఆలోచిస్తారు. మేము ఈ అవాంఛనీయ పరిస్థితిని ఈ క్రింది విధంగా వివరిస్తాము:

మా ఉదాహరణలో, k8s చేస్తుంది కార్యాచరణ తనిఖీ. ఈ రకమైన ధృవీకరణలో, kubelet నిరంతరంగా కంటైనర్‌లోని ప్రక్రియ యొక్క స్థితిని తనిఖీ చేస్తుంది. ప్రక్రియ ఆగిపోయిందని అతను అర్థం చేసుకున్న తర్వాత, అతను దానిని మళ్లీ ప్రారంభిస్తాడు. అప్లికేషన్‌ను పునఃప్రారంభించడం ద్వారా లోపాన్ని పరిష్కరించగలిగితే మరియు ఏదైనా ఎర్రర్‌ను షట్ డౌన్ చేసేలా ప్రోగ్రామ్ రూపొందించబడితే, మీరు NOP మరియు హెల్త్ టెస్ట్ ప్యాటర్న్‌ని అనుసరించడానికి ప్రాసెస్ హెల్త్ చెక్ మాత్రమే అవసరం. జాలి ఏమిటంటే, పునఃప్రారంభించడం ద్వారా అన్ని లోపాలు తొలగించబడవు. ఈ సందర్భంలో, పాడ్‌తో సమస్యలను గుర్తించడానికి k8s 2 లోతైన మార్గాలను అందిస్తుంది: సజీవతప్రోబ్ и సంసిద్ధత ప్రోబ్.

లైవ్‌నెస్‌ప్రోబ్

సమయంలో సజీవతప్రోబ్ kubelet 3 రకాల తనిఖీలను నిర్వహిస్తుంది: పాడ్ రన్ అవుతుందో లేదో మాత్రమే కాకుండా, అభ్యర్థనలను స్వీకరించడానికి మరియు తగినంతగా ప్రతిస్పందించడానికి సిద్ధంగా ఉందో లేదో కూడా నిర్ణయిస్తుంది:

• పాడ్‌కి HTTP అభ్యర్థనను సెటప్ చేయండి. ప్రతిస్పందన తప్పనిసరిగా 200 నుండి 399 పరిధిలో HTTP ప్రతిస్పందన కోడ్‌ని కలిగి ఉండాలి. అందువల్ల, ప్రక్రియ నడుస్తున్నప్పటికీ, పాడ్‌లో సమస్యలు ఉన్నాయని 5xx మరియు 4xx కోడ్‌లు సూచిస్తాయి.
• HTTP కాని సేవలతో పాడ్‌లను పరీక్షించడానికి (ఉదాహరణకు, పోస్ట్‌ఫిక్స్ మెయిల్ సర్వర్), మీరు 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')
})

Dockerfile

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

దీన్ని గమనించడం ముఖ్యం: livenessProbe కంటైనర్ విఫలమైతే మాత్రమే దాన్ని పునఃప్రారంభిస్తుంది. పునఃప్రారంభం కంటైనర్‌ను అమలు చేయకుండా నిరోధించే లోపాన్ని సరిదిద్దకపోతే, సమస్యను సరిచేయడానికి kubelet చర్య తీసుకోదు.

సంసిద్ధత ప్రోబ్

ట్రబుల్‌షూటింగ్ చర్యలు మినహా, redinessProbe livenessProbes (GET అభ్యర్థనలు, TCP కమ్యూనికేషన్‌లు మరియు కమాండ్ ఎగ్జిక్యూషన్) లాగానే పని చేస్తుంది. వైఫల్యం గుర్తించబడిన కంటైనర్ పునఃప్రారంభించబడలేదు, కానీ ఇన్కమింగ్ ట్రాఫిక్ నుండి వేరుచేయబడింది. కంటైనర్లలో ఒకటి చాలా గణనలను నిర్వహిస్తోందని లేదా భారీ లోడ్లో ఉందని ఊహించండి, దీని వలన ప్రతిస్పందన సమయాలు పెరుగుతాయి. లైవ్‌నెస్‌ప్రోబ్ విషయంలో, ప్రతిస్పందన లభ్యత తనిఖీ ట్రిగ్గర్ చేయబడుతుంది (టైమ్‌అవుట్‌సెకండ్స్ చెక్ పారామీటర్ ద్వారా), ఆ తర్వాత కుబెలెట్ కంటైనర్‌ను రీస్టార్ట్ చేస్తుంది. ప్రారంభించినప్పుడు, కంటైనర్ రిసోర్స్-ఇంటెన్సివ్ పనులను చేయడం ప్రారంభిస్తుంది మరియు మళ్లీ పునఃప్రారంభించబడుతుంది. ప్రతిస్పందన వేగం అవసరమయ్యే అప్లికేషన్‌లకు ఇది కీలకం. ఉదాహరణకు, రోడ్డుపై ఉన్న కారు సర్వర్ నుండి ప్రతిస్పందన కోసం వేచి ఉంది, ప్రతిస్పందన ఆలస్యం అవుతుంది - మరియు కారు ప్రమాదానికి గురవుతుంది.

GET అభ్యర్థన ప్రతిస్పందన సమయాన్ని రెండు సెకన్లకు మించకుండా సెట్ చేసే rednessProbe నిర్వచనాన్ని వ్రాద్దాం మరియు అప్లికేషన్ 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; DR
క్లౌడ్ అప్లికేషన్‌లు రాకముందు, అప్లికేషన్ ఆరోగ్యాన్ని పర్యవేక్షించడానికి మరియు తనిఖీ చేయడానికి లాగ్‌లు ప్రాథమిక సాధనాలు. అయితే, ఎలాంటి దిద్దుబాటు చర్యలు తీసుకునే అవకాశం లేదు. లాగ్‌లు నేటికీ ఉపయోగకరంగా ఉన్నాయి; అత్యవసర పరిస్థితులను విశ్లేషించడానికి మరియు నిర్ణయాలు తీసుకోవడానికి వాటిని సేకరించి, లాగ్ సేకరణ వ్యవస్థకు పంపాలి. [మోనిట్‌ని ఉపయోగించి క్లౌడ్ అప్లికేషన్‌లు లేకుండా ఇవన్నీ చేయవచ్చు, ఉదాహరణకు, k8s తో ఇది చాలా సులభం అయింది :) - ఎడిటర్ యొక్క గమనిక. ]

నేడు, దిద్దుబాట్లు దాదాపు నిజ సమయంలో చేయాలి, కాబట్టి అప్లికేషన్లు బ్లాక్ బాక్స్‌లుగా ఉండవలసిన అవసరం లేదు. కాదు, వారు పర్యవేక్షణ వ్యవస్థలను ప్రాసెస్‌ల స్థితి గురించి విలువైన డేటాను ప్రశ్నించడానికి మరియు సేకరించడానికి అనుమతించే ముగింపు పాయింట్‌లను చూపాలి, తద్వారా వారు అవసరమైతే తక్షణమే ప్రతిస్పందించగలరు. దీనిని పనితీరు పరీక్ష డిజైన్ నమూనా అంటారు, ఇది హై అబ్జర్వేబిలిటీ ప్రిన్సిపల్ (HOP)ని అనుసరిస్తుంది.

కుబెర్నెటెస్ డిఫాల్ట్‌గా 2 రకాల ఆరోగ్య తనిఖీలను అందిస్తుంది: రెడీనెస్‌ప్రోబ్ మరియు లైవ్‌నెస్‌ప్రోబ్. రెండూ ఒకే రకమైన చెక్‌లను ఉపయోగిస్తాయి (HTTP GET అభ్యర్థనలు, TCP కమ్యూనికేషన్‌లు మరియు కమాండ్ ఎగ్జిక్యూషన్). పాడ్‌లలోని సమస్యలకు ప్రతిస్పందనగా వారు తీసుకునే నిర్ణయాలలో వారు విభేదిస్తారు. livenessProbe లోపం మళ్లీ జరగకూడదనే ఆశతో కంటైనర్‌ను పునఃప్రారంభిస్తుంది మరియు సమస్య యొక్క కారణం పరిష్కరించబడే వరకు రెడినెస్‌ప్రోబ్ పాడ్‌ను ఇన్‌కమింగ్ ట్రాఫిక్ నుండి వేరు చేస్తుంది.

సరైన అప్లికేషన్ డిజైన్‌లో రెండు రకాల తనిఖీలు ఉండాలి మరియు అవి తగినంత డేటాను సేకరిస్తున్నాయని నిర్ధారించుకోవాలి, ప్రత్యేకించి మినహాయింపు ఇచ్చినప్పుడు. ముఖ్యమైన ఆరోగ్య కొలమానాలతో పర్యవేక్షణ వ్యవస్థ (ప్రోమేథియస్)ను అందించే అవసరమైన API ముగింపు పాయింట్‌లను కూడా ఇది చూపాలి.

మూలం: www.habr.com