ለኩበርኔትስ ኮንቴይነሮች ምርጥ ልምዶች፡ የጤና ምርመራዎች

TL; DR

• የመያዣዎችን እና የማይክሮ አገልግሎቶችን ከፍተኛ ታዛቢነት ለማግኘት የምዝግብ ማስታወሻዎች እና የመጀመሪያ ደረጃ መለኪያዎች በቂ አይደሉም።
• ለፈጣን ማገገም እና የመቋቋም አቅም መጨመር፣መተግበሪያዎች የከፍተኛ ታዛቢነት መርህን (HOP) መተግበር አለባቸው።
• በማመልከቻው ደረጃ፣ NOP የሚፈልገው፡ ትክክለኛ ምዝግብ ማስታወሻ፣ የቅርብ ክትትል፣ የንፅህና መጠበቂያ፣ እና የአፈጻጸም/የሽግግር ፍለጋ።
• ቼኮችን እንደ የNOR አካል ይጠቀሙ ዝግጁነት ፕሮቤ и livenessProbe ኩበርኔትስ

የጤና ምርመራ አብነት ምንድን ነው?

ተልእኮ-ወሳኝ እና በጣም የሚገኝ መተግበሪያን ሲነድፍ፣ እንደ ስህተት መቻቻልን ስለ እንደዚህ አይነት ገጽታ ማሰብ በጣም አስፈላጊ ነው። አፕሊኬሽኑ ከውድቀት በፍጥነት ካገገመ ስህተትን እንደመታገስ ይቆጠራል። የተለመደው የደመና ትግበራ የማይክሮ ሰርቪስ አርክቴክቸርን ይጠቀማል - እያንዳንዱ አካል በተለየ መያዣ ውስጥ ይቀመጣል። እና ክላስተር ሲነድፉ በk8s ላይ ያለው አፕሊኬሽን በጣም መገኘቱን ለማረጋገጥ የተወሰኑ ቅጦችን መከተል ያስፈልግዎታል። ከነሱ መካከል የጤና ማረጋገጫ አብነት አለ። አፕሊኬሽኑ ጤናማ መሆኑን ከ k8s ጋር እንዴት እንደሚያስተላልፍ ይገልጻል። ይህ ፖዱ እየሰራ ስለመሆኑ ብቻ ሳይሆን ለጥያቄዎች እንዴት እንደሚቀበል እና እንደሚመልስ ጭምር መረጃ ነው። ኩበርኔትስ ስለ ፖድ ጤና የበለጠ በሚያውቅ መጠን ስለ የትራፊክ ማዘዋወር እና ጭነት ማመጣጠን የበለጠ ብልህ ውሳኔዎችን ያደርጋል። ስለዚህ የከፍተኛ ታዛቢነት መርህ አፕሊኬሽኑ ለጥያቄዎች ወቅታዊ ምላሽ እንዲሰጥ ይፈቅዳል።

ከፍተኛ ታዛቢነት መርህ (HOP)

የከፍተኛ ታዛቢነት መርህ አንዱ ነው በኮንቴይነር የተያዙ አፕሊኬሽኖችን ለመንደፍ መርሆዎች. በማይክሮ ሰርቪስ አርክቴክቸር ውስጥ፣ አገልግሎቶቹ ጥያቄያቸው እንዴት እንደሚስተናገዱ አይጨነቁም (እና በትክክል)፣ ነገር ግን ወሳኙ ነገር ከተቀባይ አገልግሎቶች እንዴት ምላሽ እንደሚያገኙ ነው። ለምሳሌ ተጠቃሚን ለማረጋገጥ አንድ ኮንቴይነር የኤችቲቲፒ ጥያቄን ለሌላ ይልካል፣ በተወሰነ ቅርጸት ምላሽ ይጠብቃል - ያ ብቻ ነው። PythonJS እንዲሁ ጥያቄውን ማስተናገድ ይችላል፣ እና Python Flask ምላሽ ሊሰጥ ይችላል። ኮንቴይነሮች እርስ በርስ የተደበቁ ይዘቶች እንደ ጥቁር ሳጥኖች ናቸው. ነገር ግን፣ የNOP መርህ እያንዳንዱ አገልግሎት ምን ያህል ጤናማ እንደሆነ፣ እንዲሁም ዝግጁነቱን እና የስህተት መቻቻል ሁኔታን የሚያሳዩ በርካታ የኤፒአይ የመጨረሻ ነጥቦችን እንዲያጋልጥ ይፈልጋል። ኩበርኔትስ እነዚህን አመላካቾች የሚጠይቀው ለማዘዋወር እና ለጭነት ማመጣጠን በሚቀጥሉት ደረጃዎች ለማሰብ ነው።

በደንብ የተነደፈ የደመና መተግበሪያ መደበኛውን የ I/O ዥረቶች STDERR እና STDOUT በመጠቀም ዋና ዋና ክስተቶችን ይመዘግባል። ቀጥሎ ረዳት አገልግሎት ይመጣል፣ ለምሳሌ filebeat፣ logstash ወይም fluentd፣ ምዝግብ ማስታወሻዎችን ወደ የተማከለ የክትትል ስርዓት (ለምሳሌ ፕሮሜቲየስ) እና የምዝግብ ማስታወሻ አሰባሰብ ስርዓት (ELK software suite) ማድረስ። ከዚህ በታች ያለው ሥዕላዊ መግለጫ የደመና አፕሊኬሽን እንዴት እንደሚሰራ በጤና ምርመራ ንድፍ እና በከፍተኛ ታዛቢነት መርህ ላይ ያሳያል።

በ Kubernetes ውስጥ ያለውን የጤና ምርመራ ንድፍ እንዴት ተግባራዊ ማድረግ እንደሚቻል?

ከሳጥኑ ውስጥ፣ k8s ከተቆጣጣሪዎቹ አንዱን በመጠቀም የፖዳዎቹን ሁኔታ ይከታተላል (ትግበራዎች, ReplicaSets, ዴሞን አዘጋጅ, StatefulSets ወዘተ ወዘተ.) ፖድው በሆነ ምክንያት መውደቁን ካወቀ በኋላ መቆጣጠሪያው እንደገና ለማስጀመር ወይም ወደ ሌላ መስቀለኛ መንገድ ለማንቀሳቀስ ይሞክራል። ነገር ግን፣ ፖድ መስራቱን እና እየሰራ መሆኑን ሪፖርት ሊያደርግ ይችላል፣ ነገር ግን እሱ ራሱ እየሰራ አይደለም። እስቲ አንድ ምሳሌ እንስጥ፡ አፕሊኬሽን Apacheን እንደ ዌብ ሰርቨር ይጠቀማል፡ ክፍሉን በበርካታ የክላስተር ፖድ ላይ ጭነዋል። ቤተ መፃህፍቱ በስህተት የተዋቀረ በመሆኑ፣ ሁሉም የመተግበሪያው ጥያቄዎች በኮድ 500 (የውስጥ አገልጋይ ስህተት) ምላሽ ይሰጣሉ። ማቅረቢያ ሲፈተሽ የፖዳዎችን ሁኔታ መፈተሽ የተሳካ ውጤት ያስገኛል ነገርግን ደንበኞች በተለየ መንገድ ያስባሉ። ይህንን የማይፈለግ ሁኔታ እንደሚከተለው እንገልፃለን-

በእኛ ምሳሌ, k8s ያደርጋል ተግባራዊነት ማረጋገጥ. በዚህ አይነት የማረጋገጫ አይነት ኩብሌት በእቃው ውስጥ ያለውን የሂደቱን ሁኔታ ያለማቋረጥ ያረጋግጣል. ሂደቱ መቆሙን ከተረዳ በኋላ እንደገና ያስጀምረዋል. ስህተቱ በቀላሉ አፕሊኬሽኑን እንደገና በማስጀመር ሊፈታ የሚችል ከሆነ እና ፕሮግራሙ ማንኛውንም ስህተት ለመዝጋት የተነደፈ ከሆነ የሂደቱ የጤና ምርመራ የ NOP እና የጤና ምርመራ ንድፍን መከተል ብቻ ነው ። ብቸኛው አሳዛኝ ነገር እንደገና በመጀመር ሁሉም ስህተቶች አይወገዱም. በዚህ አጋጣሚ k8s በፖድ ላይ ያሉ ችግሮችን ለመለየት 2 ጥልቅ መንገዶችን ይሰጣል። livenessProbe и ዝግጁነት ፕሮቤ.

LivenessProbe

በ livenessProbe kubelet 3 አይነት ቼኮችን ያከናውናል፡ ፖዱ እየሰራ መሆኑን ብቻ ሳይሆን ለመቀበል እና ለጥያቄዎች በቂ ምላሽ ለመስጠት ዝግጁ መሆኑንም ይወስናል፡

• የኤችቲቲፒ ጥያቄን ወደ ፖድ ያዋቅሩ። ምላሹ ከ 200 እስከ 399 ባለው ክልል ውስጥ የኤችቲቲፒ ምላሽ ኮድ መያዝ አለበት ። ስለዚህ ፣ ምንም እንኳን ሂደቱ እየሄደ ቢሆንም ፣ 5xx እና 4xx ኮዶች ፖዱ ችግር እንዳለበት ያሳያል።
• ፖድዎችን ኤችቲቲፒ ካልሆኑ አገልግሎቶች (ለምሳሌ የፖስትፊክስ መልእክት አገልጋይ) ለመሞከር የ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 የኤችቲቲፒ 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 እቃውን ካልተሳካ ብቻ እንደገና ያስጀምራል። ዳግም ማስጀመር እቃው እንዳይሰራ የሚከለክለውን ስህተት ካላረመ ኩብሌት ችግሩን ለማስተካከል እርምጃ መውሰድ አይችልም።

ዝግጁነት ፕሮቤ

readinessProbe ከመላ መፈለጊያ እርምጃዎች በስተቀር ከ livenessProbes (GET ጥያቄዎች፣ የTCP ግንኙነቶች እና የትዕዛዝ አፈፃፀም) ጋር በተመሳሳይ መልኩ ይሰራል። አለመሳካቱ የተገኘበት መያዣ እንደገና አልተጀመረም, ነገር ግን ከሚመጣው ትራፊክ ተለይቷል. ከመያዣዎቹ ውስጥ አንዱ ብዙ ስሌቶችን እያከናወነ እንደሆነ ወይም በከባድ ጭነት ውስጥ እንዳለ አስብ, ይህም የምላሽ ጊዜዎች ይጨምራሉ. በ LivenessProbe ጉዳይ ላይ የምላሽ ተገኝነት ፍተሻ ይነሳል (በጊዜ ማብቂያ ሰከንድ ቼክ መለኪያ በኩል) ፣ ከዚያ በኋላ kubelet መያዣውን እንደገና ያስጀምራል። ሲጀመር ኮንቴይነሩ ሀብትን የሚጨምሩ ተግባራትን ማከናወን ይጀምራል እና እንደገና ይጀምራል። ይህ የምላሽ ፍጥነት ለሚያስፈልጋቸው መተግበሪያዎች ወሳኝ ሊሆን ይችላል. ለምሳሌ, አንድ መኪና በመንገድ ላይ እያለ ከአገልጋዩ ምላሽ እየጠበቀ, ምላሹ ዘግይቷል - እና መኪናው አደጋ ውስጥ ገብቷል.

የGET ጥያቄ ምላሽ ጊዜን ከሁለት ሰከንድ በላይ የሚያዘጋጅ የ rednessProbe ፍቺን እንፃፍ እና አፕሊኬሽኑ ለGET ጥያቄ ከ5 ሰከንድ በኋላ ምላሽ ይሰጣል። የ 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

በውጤቱ መጨረሻ ላይ አንዳንድ ክስተቶች ተመሳሳይ መሆናቸውን ማየት ይችላሉ ይሄኛው.

እንደሚመለከቱት, kubectl የፍተሻ ጊዜ ከ 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; DR
የደመና አፕሊኬሽኖች ከመምጣታቸው በፊት ምዝግብ ማስታወሻዎች የመተግበሪያ ጤናን ለመከታተል እና ለመፈተሽ ዋና መንገዶች ነበሩ። ይሁን እንጂ ምንም ዓይነት የእርምት እርምጃ ለመውሰድ የሚያስችል ዘዴ አልነበረም. የምዝግብ ማስታወሻዎች ዛሬም ጠቃሚ ናቸው፤ የአደጋ ጊዜ ሁኔታዎችን ለመተንተን እና ውሳኔዎችን ለማድረግ መሰብሰብ እና ወደ ሎግ ማሰባሰብ ስርዓት መላክ አለባቸው። [ይህ ሁሉ ያለ ደመና አፕሊኬሽኖች ለምሳሌ ሞኒትን በመጠቀም ሊከናወን ይችላል ነገር ግን በ k8s በጣም ቀላል ሆኗል :) - የአርታዒ ማስታወሻ. ]

ዛሬ፣ እርማቶች በእውነተኛ ጊዜ መደረግ ስላለባቸው መተግበሪያዎች ከአሁን በኋላ ጥቁር ሳጥኖች መሆን የለባቸውም። አይደለም፣ አስፈላጊ ከሆነ ወዲያውኑ ምላሽ እንዲሰጡ የክትትል ስርዓቶች እንዲጠይቁ እና ጠቃሚ መረጃዎችን ስለሂደቱ ሁኔታ እንዲሰበስቡ የሚያስችሉ የመጨረሻ ነጥቦችን ማሳየት አለባቸው። ይህ የከፍተኛ ታዛቢነት መርህ (HOP) የተከተለ የአፈጻጸም ሙከራ ንድፍ ንድፍ ይባላል።

Kubernetes በነባሪነት 2 ዓይነት የጤና ምርመራዎችን ያቀርባል፡ ዝግጁነት ፕሮብ እና livenessProbe። ሁለቱም ተመሳሳይ አይነት ቼኮች ይጠቀማሉ (የኤችቲቲፒ GET ጥያቄዎች፣ የTCP ግንኙነቶች እና የትዕዛዝ አፈፃፀም)። በፖዳዎች ውስጥ ለሚፈጠሩ ችግሮች ምላሽ በሚሰጡ ውሳኔዎች ይለያያሉ. livenessProbe ስህተቱ እንደገና እንደማይከሰት በማሰብ መያዣውን እንደገና ያስጀምረዋል እና ዝግጁነት ፕሮብ የችግሩ መንስኤ እስኪወገድ ድረስ ከገቢው ትራፊክ ይለየዋል።

ትክክለኛው የመተግበሪያ ንድፍ ሁለቱንም የፍተሻ ዓይነቶች ማካተት እና በቂ መረጃ መሰብሰባቸውን ማረጋገጥ አለበት፣በተለይ ልዩ ሁኔታ ሲጣል። እንዲሁም የክትትል ስርዓቱን (Prometheus) አስፈላጊ የጤና መለኪያዎችን የሚያቀርቡ አስፈላጊ የኤፒአይ የመጨረሻ ነጥቦችን ማሳየት አለበት።

ምንጭ: hab.com