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
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 (
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
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
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
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