Bêste praktiken foar Kubernetes-konteners: sûnenskontrôles

TL; DR

• Om hege observabiliteit fan konteners en mikrotsjinsten te berikken, binne logs en primêre metriken net genôch.
• Foar rapper herstel en ferhege fearkrêft moatte applikaasjes it High Observability Principle (HOP) tapasse.
• Op it tapassingsnivo fereasket NOP: juste logging, nauwe tafersjoch, sûnenskontrôles, en prestaasjes / oergong tracing.
• Brûk sjeks as elemint fan NOR reewilligensProbe и livenessProbe Kubernetes.

Wat is in sjabloan foar sûnenskontrôle?

By it ûntwerpen fan in missy-krityske en heul beskikbere applikaasje is it heul wichtich om te tinken oer sa'n aspekt as fouttolerânsje. In applikaasje wurdt beskôge as fouttolerant as it fluch herstelt fan mislearring. In typyske wolkapplikaasje brûkt in microservices-arsjitektuer - wêr't elke komponint yn in aparte kontener wurdt pleatst. En om derfoar te soargjen dat de applikaasje op k8s heech beskikber is as jo in kluster ûntwerpe, moatte jo bepaalde patroanen folgje. Under harren is it Health Check Template. It definiearret hoe't de applikaasje kommunisearret oan k8s dat it sûn is. Dit is net allinnich ynformaasje oer oft de pod rint, mar ek oer hoe't it ûntfangt en reagearret op fersiken. Hoe mear Kubernetes wit oer de sûnens fan 'e pod, hoe tûker besluten it makket oer ferkearsrouting en loadbalancing. Sa lit it prinsipe fan hege observabiliteit de applikaasje op 'e tiid reagearje op oanfragen.

High Observability Principle (HOP)

It prinsipe fan hege observabiliteit is ien fan prinsipes foar it ûntwerpen fan containerized applikaasjes. Yn in arsjitektuer fan mikrotsjinsten skele tsjinsten net oer hoe't har fersyk wurdt ferwurke (en mei rjocht), mar wat fan belang is is hoe't se antwurden krije fan 'e ûntfangende tsjinsten. Bygelyks, om in brûker te autentisearjen, stjoert ien kontener in HTTP-fersyk nei in oar, ferwachtet in antwurd yn in bepaald formaat - dat is alles. PythonJS kin ek ferwurkje it fersyk, en Python Flask kin reagearje. Containers binne as swarte doazen mei ferburgen ynhâld oan elkoar. It NOP-prinsipe fereasket lykwols dat elke tsjinst meardere API-einpunten bleatstelle dy't oanjaan hoe sûn it is, lykas har reewilligens en flatertolerânsjestatus. Kubernetes freget dizze yndikatoaren om te tinken troch de folgjende stappen foar routing en load balancing.

In goed ûntworpen wolkapplikaasje logt har haadeveneminten mei de standert I/O-streams STDERR en STDOUT. Dêrnei komt in helptsjinst, bygelyks filebeat, logstash of fluentd, it leverjen fan logs nei in sintralisearre monitoaringsysteem (bygelyks Prometheus) en in log-kolleksjesysteem (ELK software suite). It diagram hjirûnder lit sjen hoe't in wolkapplikaasje wurket neffens it Health Test Pattern en it High Observability Principle.

Hoe kinne jo it Health Check Pattern tapasse yn Kubernetes?

Ut it fak kontroleart k8s de status fan 'e pods mei ien fan' e controllers (Ynsetten, ReplikaSets, DaemonSets, StatefulSets ensfh., ensfh.). Nei't ûntdutsen is dat de pod om ien of oare reden fallen is, besiket de controller it opnij te starten of nei in oare knooppunt te ferpleatsen. In pod kin lykwols melde dat it op en rint, mar it sels wurket net. Litte wy in foarbyld jaan: jo applikaasje brûkt Apache as webserver, jo hawwe de komponint ynstalleare op ferskate pods fan it kluster. Sûnt de bibleteek is ferkeard ynsteld, reagearje alle oanfragen nei de applikaasje mei koade 500 (ynterne serverflater). By it kontrolearjen fan levering jout it kontrolearjen fan de status fan pods in suksesfol resultaat, mar klanten tinke oars. Wy sille dizze net-winske situaasje as folgjend beskriuwe:

Yn ús foarbyld docht k8s funksjonaliteit kontrôle. Yn dit soarte fan ferifikaasje kontrolearret de kubelet kontinu de steat fan it proses yn 'e kontener. As hy ienris begrypt dat it proses stoppe is, sil hy it opnij begjinne. As de flater kin wurde oplost troch gewoan de applikaasje opnij te starten, en it programma is ûntworpen om elke flater ôf te sluten, dan is in proses sûnenskontrôle alles wat jo nedich binne om de NOP en it Health Test Pattern te folgjen. It ienige meilijen is dat net alle flaters wurde eliminearre troch opnij starte. Yn dit gefal biedt k8s 2 djippere manieren om problemen mei de pod te identifisearjen: livenessProbe и reewilligensProbe.

LivenessProbe

By de livenessProbe kubelet fiert 3 soarten kontrôles: bepaalt net allinich oft de pod rint, mar ek oft it ree is om oanfragen te ûntfangen en adekwaat te reagearjen:

• Stel in HTTP-fersyk yn foar de pod. It antwurd moat befetsje in HTTP antwurd koade yn it berik fan 200 oan 399. Sa, koades 5xx en 4xx sinjaal dat de pod hat problemen, ek al it proses rint.
• Om pods te testen mei net-HTTP-tsjinsten (bygelyks de Postfix-posttsjinner), moatte jo in TCP-ferbining meitsje.
• In willekeurige kommando útfiere foar in pod (yntern). De kontrôle wurdt as suksesfol beskôge as de kommando-foltôgingskoade 0 is.

In foarbyld fan hoe't dit wurket. De folgjende pod-definysje befettet in NodeJS-applikaasje dy't in flater fan 500 smyt op HTTP-fersiken. Om der wis fan te wêzen dat de kontener opnij starte wurdt by it ûntfangen fan sa'n flater, brûke wy de livenessProbe parameter:

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

Dit is net oars as in oare pod-definysje, mar wy foegje in objekt ta .spec.containers.livenessProbe... Parameter httpGet akseptearret it paad wêrnei't it HTTP GET-fersyk wurdt stjoerd (yn ús foarbyld is dit /, mar yn combat senario der kin wêze wat as /api/v1/status). In oare livenessProbe akseptearret in parameter initialDelaySeconds, dy't de ferifikaasjeoperaasje ynstruearret om in spesifisearre oantal sekonden te wachtsjen. De fertraging is nedich om't de kontener tiid nedich hat om te begjinnen, en as it opnij starte sil it in skoft net beskikber wêze.

Om dizze ynstelling ta te passen op in kluster, brûk:

kubectl apply -f pod.yaml

Nei in pear sekonden kinne jo de ynhâld fan 'e pod kontrolearje mei it folgjende kommando:

kubectl describe pods node500

Oan 'e ein fan' e útfier, fine dat is wat.

Sa't jo sjen kinne, inisjearre livenessProbe in HTTP GET-fersyk, de kontener generearre in flater 500 (wat it is programmearre om te dwaan), en de kubelet opnij starte.

As jo ​​jo ôffreegje hoe't de NideJS-applikaasje is programmearre, hjir is de app.js en Dockerfile dy't waarden brûkt:

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" ]

It is wichtich om dit op te merken: livenessProbe sil de kontener allinich opnij starte as it mislearret. As in trochstart de flater net korrigeart dy't foarkomt dat de kontener rint, kin de kubelet gjin aksje nimme om it probleem te korrigearjen.

reewilligensProbe

readinessProbe wurket fergelykber mei livenessProbes (GET-oanfragen, TCP-kommunikaasje en kommando-útfiering), útsein foar aksjes foar probleemoplossing. De kontener wêryn't de flater ûntdutsen wurdt, wurdt net opnij opstart, mar is isolearre fan ynkommend ferkear. Stel jo foar dat ien fan 'e konteners in protte berekkeningen útfiert of ûnder swiere lading is, wêrtroch't antwurdtiden tanimme. Yn it gefal fan livenessProbe wurdt de kontrôle beskikberens fan antwurden aktivearre (fia de timeoutSeconds check parameter), wêrnei't de kubelet de kontener opnij starte. As it is begon, begjint de kontener boarne-yntinsive taken út te fieren en wurdt opnij starte. Dit kin kritysk wêze foar applikaasjes dy't antwurdsnelheid nedich binne. Bygelyks, in auto wylst op 'e dyk wachtet op in antwurd fan de tsjinner, it antwurd wurdt fertrage - en de auto komt yn in ûngelok.

Litte wy in redinessProbe-definysje skriuwe dy't de GET-fersyk-antwurdtiid sil ynstelle op net mear as twa sekonden, en de applikaasje sil nei 5 sekonden reagearje op it GET-fersyk. It pod.yaml-bestân moat der sa útsjen:

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

Litte wy in pod ynsette mei kubectl:

kubectl apply -f pod.yaml

Litte wy in pear sekonden wachtsje en dan sjen hoe't de ReadinessProbe wurke:

kubectl describe pods nodedelayed

Oan 'e ein fan' e útfier kinne jo sjen dat guon fan 'e eveneminten ferlykber binne dizze.

Sa't jo sjen kinne, hat kubectl de pod net opnij starte doe't de kontrôletiid 2 sekonden grutter wie. Ynstee, hy annulearre it fersyk. Ynkommende kommunikaasje wurdt omlaat nei oare, wurkjende pods.

Tink derom dat no't de pod ôfladen is, kubectl fersiken der wer nei rûte: antwurden op GET-oanfragen wurde net langer fertrage.

Foar fergeliking is hjirûnder it wizige app.js-bestân:

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
Foar de komst fan wolkapplikaasjes wiene logs it primêre middel foar it kontrolearjen en kontrolearjen fan applikaasjes sûnens. D'r wie lykwols gjin middel om korrigearjende maatregels te nimmen. Logboeken binne hjoed noch nuttich; se moatte wurde sammele en stjoerd nei in logboeksammelsysteem foar it analysearjen fan needsituaasjes en it meitsjen fan besluten. [Dit alles koe wurde dien sûnder wolk applikaasjes mei help fan bygelyks monit, mar mei k8s waard it folle makliker :) - redaksje notysje. ]

Tsjintwurdich moatte korreksjes hast yn echte tiid makke wurde, sadat applikaasjes gjin swarte doazen mear hoege te wêzen. Nee, se moatte einpunten sjen litte dy't tafersjochsystemen tastean om weardefolle gegevens te freegjen en te sammeljen oer de steat fan prosessen, sadat se as nedich direkt kinne reagearje. Dit wurdt it Performance Test Design Pattern neamd, dat folget it High Observability Principle (HOP).

Kubernetes biedt standert 2 soarten sûnenskontrôles: readinessProbe en livenessProbe. Beide brûke deselde soarten kontrôles (HTTP GET-oanfragen, TCP-kommunikaasje en kommando-útfiering). Se ferskille yn hokker besluten se nimme as antwurd op problemen yn 'e pods. livenessProbe start de kontener opnij yn 'e hope dat de flater net wer barre sil, en readinessProbe isolearret de pod fan ynkommende ferkear oant de oarsaak fan it probleem is oplost.

Goed applikaasjeûntwerp moat beide soarten kontrôle omfetsje en soargje dat se genôch gegevens sammelje, foaral as in útsûndering wurdt smiten. It moat ek de nedige API-einpunten sjen litte dy't it tafersjochsysteem (Prometheus) mei wichtige sûnensmetriken leverje.

Boarne: www.habr.com