Bestu starfsvenjur fyrir Kubernetes gáma: Heilbrigðiseftirlit

TL; DR

• Til að ná fram mikilli athugun á gámum og örþjónustum duga ekki annálar og frummælingar.
• Til að ná hraðari bata og aukinni seiglu ættu umsóknir að beita High Observability Principle (HOP).
• Á umsóknarstigi krefst NOP: rétta skógarhögg, náið eftirlit, geðheilsueftirlit og frammistöðu/umskipti rakning.
• Notaðu ávísanir sem þátt NOR viðbúnaðurSkönnun и lífsreynsla Kubernetes.

Hvað er sniðmát fyrir heilsufarsskoðun?

Þegar verið er að hanna verkefni sem er mikilvægt og mjög tiltækt forrit er mjög mikilvægt að hugsa um slíkan þátt eins og bilanaþol. Umsókn telst bilanaþolin ef hún jafnar sig fljótt eftir bilun. Dæmigert skýjaforrit notar örþjónustuarkitektúr - þar sem hver hluti er settur í sérstakan ílát. Og til að tryggja að forritið á k8s sé mjög fáanlegt þegar þú hannar klasa þarftu að fylgja ákveðnum mynstrum. Þar á meðal er sniðmát fyrir heilbrigðiseftirlit. Það skilgreinir hvernig forritið miðlar k8s að það sé heilbrigt. Þetta eru ekki aðeins upplýsingar um hvort belgurinn sé í gangi heldur einnig um hvernig hann tekur við og bregst við beiðnum. Því meira sem Kubernetes veit um heilsu belgsins, því skynsamlegri ákvarðanir tekur það um umferðarleiðir og álagsjafnvægi. Þannig gerir High Observability Principle forritinu kleift að bregðast við beiðnum tímanlega.

High Observability Principle (HOP)

Meginreglan um mikla athugun er ein af meginreglur fyrir hönnun gámaforrita. Í örþjónustuarkitektúr er þjónustu ekki sama hvernig beiðni þeirra er unnin (og það er rétt), en það sem skiptir máli er hvernig þær fá svör frá móttökuþjónustunni. Til dæmis, til að auðkenna notanda, sendir einn gámur HTTP beiðni til annars og býst við svari á ákveðnu sniði - það er allt. PythonJS getur líka unnið úr beiðninni og Python Flask getur svarað. Ílát eru eins og svartir kassar með falið innihald hver við annan. Hins vegar, NOP meginreglan krefst þess að hver þjónusta afhjúpi marga API endapunkta sem gefa til kynna hversu heilbrigð hún er, svo og viðbúnað hennar og bilanaþolsstöðu. Kubernetes óskar eftir þessum vísbendingum til að hugsa í gegnum næstu skref fyrir leiðsögn og álagsjafnvægi.

Vel hannað skýjaforrit skráir helstu atburði sína með því að nota staðlaða I/O strauma STDERR og STDOUT. Næst kemur aukaþjónusta, til dæmis filebeat, logstash eða fluentd, sem afhendir annála í miðstýrt eftirlitskerfi (til dæmis Prometheus) og annálasöfnunarkerfi (ELK hugbúnaðarsvíta). Skýringarmyndin hér að neðan sýnir hvernig skýjaforrit virkar í samræmi við heilsuprófamynstrið og High Observability Principle.

Hvernig á að nota heilsuskoðunarmynstrið í Kubernetes?

Upp úr kassanum fylgist k8s með stöðu belgjanna með því að nota einn af stýringunum (Dreifing, Eftirlíkingarsett, Púkasett, StatefulSets o.s.frv., osfrv.). Eftir að hafa uppgötvað að belgurinn hefur fallið af einhverjum ástæðum reynir stjórnandinn að endurræsa hann eða færa hann yfir á annan hnút. Hins vegar getur fræbelgur tilkynnt að hann sé í gangi, en hann sjálfur virkar ekki. Við skulum gefa dæmi: forritið þitt notar Apache sem vefþjón, þú settir upp íhlutinn á nokkrum belgjum þyrpingarinnar. Þar sem bókasafnið var rangt stillt, svara allar beiðnir til forritsins með kóða 500 (innri netþjónsvilla). Þegar þú athugar afhendingu gefur það farsæla niðurstöðu að athuga stöðu belganna, en viðskiptavinir hugsa öðruvísi. Við munum lýsa þessu óæskilega ástandi sem hér segir:

Í dæminu okkar gerir k8s það virkniathugun. Í þessari tegund af sannprófun athugar kubelet stöðugt stöðu ferlisins í ílátinu. Þegar hann skilur að ferlið er hætt mun hann endurræsa það. Ef hægt er að leysa villuna með því einfaldlega að endurræsa forritið og forritið er hannað til að loka fyrir hvaða villu sem er, þá er heilsufarsskoðun allt sem þú þarft til að fylgja NOP og heilsuprófamynstrinu. Eina syndin er að ekki er öllum villum eytt með því að endurræsa. Í þessu tilviki býður k8s upp á 2 dýpri leiðir til að bera kennsl á vandamál með fræbelginn: lífsreynsla и viðbúnaðurSkönnun.

LivenessProbe

Á meðan lífsreynsla kubelet framkvæmir 3 tegundir athugana: ákvarðar ekki aðeins hvort hólfið sé í gangi, heldur einnig hvort það sé tilbúið til að taka á móti og svara beiðnum á fullnægjandi hátt:

• Settu upp HTTP beiðni á hólfið. Svarið verður að innihalda HTTP svarkóða á bilinu 200 til 399. Þannig gefa kóðar 5xx og 4xx merki um að belgurinn sé í vandræðum, þó að ferlið sé í gangi.
• Til að prófa pods með þjónustu sem ekki er HTTP (til dæmis Postfix póstþjóninn) þarftu að koma á TCP tengingu.
• Framkvæma handahófskennda skipun fyrir belg (innbyrðis). Athugunin er talin vel heppnuð ef skipunarkóði er 0.

Dæmi um hvernig þetta virkar. Næsta pod skilgreining inniheldur NodeJS forrit sem varpar 500 villu á HTTP beiðnir. Til að tryggja að ílátið sé endurræst þegar slík villa er móttekin notum við livenessProbe færibreytuna:

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

Þetta er ekkert frábrugðið hverri annarri belgskilgreiningu, en við erum að bæta við hlut .spec.containers.livenessProbe... Parameter httpGet samþykkir slóðina sem HTTP GET beiðnin er send til (í okkar dæmi er þetta /, en í bardagaaðstæðum gæti verið eitthvað eins og /api/v1/status). Annar livenessProbe samþykkir breytu initialDelaySeconds, sem gefur staðfestingaraðgerðinni fyrirmæli um að bíða í tiltekinn fjölda sekúnda. Töfin er nauðsynleg vegna þess að gámurinn þarf tíma til að ræsa sig og þegar hann er endurræstur verður hann ekki tiltækur í nokkurn tíma.

Til að nota þessa stillingu á klasa, notaðu:

kubectl apply -f pod.yaml

Eftir nokkrar sekúndur geturðu athugað innihald belgsins með því að nota eftirfarandi skipun:

kubectl describe pods node500

Í lok úttaksins, finndu þetta er hvað.

Eins og þú sérð, setti livenessProbe af stað HTTP GET beiðni, ílátið myndaði villu 500 (sem er það sem það var forritað til að gera) og kubelet endurræsti það.

Ef þú ert að velta fyrir þér hvernig NideJS forritið var forritað, hér er app.js og Dockerfile sem voru notuð:

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')
})

Dockerfil

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

Það er mikilvægt að hafa þetta í huga: livenessProbe mun aðeins endurræsa ílátið ef það mistekst. Ef endurræsing leiðréttir ekki villuna sem kemur í veg fyrir að ílátið gangi, mun kubelet ekki geta gripið til aðgerða til að leiðrétta vandamálið.

viðbúnaðurSkönnun

readinessProbe virkar svipað og livenessProbes (GET beiðnir, TCP samskipti og framkvæmd skipana), nema fyrir bilanaleit. Gámurinn sem bilunin greinist í er ekki endurræstur heldur er hann einangraður frá komandi umferð. Ímyndaðu þér að einn af gámunum sé að framkvæma mikið af útreikningum eða sé undir miklu álagi, sem veldur því að viðbragðstími eykst. Þegar um livenessProbe er að ræða, er könnun á framboði svars ræst (í gegnum færibreytuna timeoutSeconds check), eftir það endurræsir kubelet gáminn. Þegar byrjað er, byrjar gámurinn að framkvæma auðlindafrekar verkefni og er endurræstur aftur. Þetta getur verið mikilvægt fyrir forrit sem þurfa svarhraða. Til dæmis bíður bíll á veginum eftir svari frá þjóninum, svarið seinkar - og bíllinn lendir í slysi.

Við skulum skrifa redinessProbe skilgreiningu sem stillir svartíma GET beiðni á ekki meira en tvær sekúndur og forritið mun svara GET beiðninni eftir 5 sekúndur. Pod.yaml skráin ætti að líta svona út:

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

Við skulum dreifa belg með kubectl:

kubectl apply -f pod.yaml

Bíðum í nokkrar sekúndur og sjáum síðan hvernig viðbúnaðurinn virkaði:

kubectl describe pods nodedelayed

Í lok úttaksins má sjá að sumir atburðanna eru svipaðir þessi.

Eins og þú sérð endurræsti kubectl podinn ekki þegar eftirlitstíminn fór yfir 2 sekúndur. Þess í stað hætti hann við beiðnina. Innkomandi fjarskiptum er vísað á aðra, virka belg.

Athugaðu að nú þegar hólfið er losað, vísar kubectl beiðnir til hans aftur: svör við GET beiðnum eru ekki lengur seinkuð.

Til samanburðar, hér að neðan er breytt app.js skrá:

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
Áður en skýjaforrit komu til sögunnar voru annálar aðalleiðin til að fylgjast með og athuga heilsu forrita. Hins vegar var engin leið til að grípa til úrbóta. Dagskrár eru enn gagnlegar í dag, þær þarf að safna og senda í söfnunarkerfi til að greina neyðartilvik og taka ákvarðanir. [Allt þetta væri hægt að gera án skýjaforrita með því að nota td monit, en með k8s varð það miklu auðveldara :) – athugasemd ritstjóra. ]

Í dag þarf að gera leiðréttingar nánast í rauntíma, þannig að umsóknir þurfa ekki lengur að vera svartir kassar. Nei, þeir ættu að sýna endapunkta sem gera vöktunarkerfum kleift að spyrjast fyrir um og safna dýrmætum gögnum um stöðu ferla svo að þau geti svarað samstundis ef þörf krefur. Þetta er kallað Performance Test Design Pattern, sem fylgir High Observability Principle (HOP).

Kubernetes býður sjálfgefið upp á 2 tegundir af heilsufarsskoðunum: readyProbe og livenessProbe. Báðir nota sömu tegundir athugana (HTTP GET beiðnir, TCP samskipti og framkvæmd skipana). Misjafnt er hvaða ákvarðanir þeir taka til að bregðast við vandamálum í belgjunum. livenessProbe endurræsir gáminn í þeirri von að villa komi ekki fyrir aftur og readinessProbe einangrar belginn frá komandi umferð þar til orsök vandans er leyst.

Rétt forritshönnun ætti að innihalda báðar tegundir athugana og tryggja að þau safni nægum gögnum, sérstaklega þegar undantekning er hent. Það ætti einnig að sýna nauðsynlega API endapunkta sem veita eftirlitskerfinu (Prometheus) mikilvægar heilsumælingar.

Heimild: www.habr.com