TL; DR
- Për të arritur vëzhgueshmëri të lartë të kontejnerëve dhe mikroshërbimeve, shkrimet dhe metrikat kryesore nuk janë të mjaftueshme.
- Për rikuperim më të shpejtë dhe rritje të elasticitetit, aplikacionet duhet të zbatojnë Parimin e Vëzhgueshmërisë së Lartë (HOP).
- Në nivelin e aplikimit, NOP kërkon: regjistrimin e duhur, monitorim të ngushtë, kontrolle të arsyeshme dhe gjurmim të performancës/tranzicionit.
- Përdorni çeqet si një element të NOR gatishmëriProbe и Sonda e gjallërisë Kubernetes.
Çfarë është një shabllon i kontrollit shëndetësor?
Kur hartoni një aplikacion kritik dhe shumë të disponueshëm për misionin, është shumë e rëndësishme të mendoni për një aspekt të tillë si toleranca ndaj gabimeve. Një aplikacion konsiderohet tolerant ndaj gabimeve nëse rikuperohet shpejt nga dështimi. Një aplikacion tipik cloud përdor një arkitekturë mikroshërbimesh - ku secili komponent vendoset në një enë të veçantë. Dhe për t'u siguruar që aplikacioni në k8s është shumë i disponueshëm kur hartoni një grup, duhet të ndiqni modele të caktuara. Midis tyre është modeli i kontrollit shëndetësor. Ai përcakton se si aplikacioni i komunikon k8s se është i shëndetshëm. Ky nuk është vetëm informacion nëse pod po funksionon, por edhe për mënyrën se si ai merr dhe u përgjigjet kërkesave. Sa më shumë të dijë Kubernetes për shëndetin e podit, aq më të zgjuara merr vendime për drejtimin e trafikut dhe balancimin e ngarkesës. Kështu, Parimi i Vëzhgueshmërisë së Lartë i lejon aplikacionit t'u përgjigjet kërkesave në kohën e duhur.
Parimi i Vëzhgueshmërisë së Lartë (HOP)
Parimi i vëzhgueshmërisë së lartë është një nga
Një aplikacion cloud i projektuar mirë regjistron ngjarjet e tij kryesore duke përdorur transmetimet standarde I/O STDERR dhe STDOUT. Më pas vjen një shërbim ndihmës, për shembull filebeat, logstash ose fluentd, duke ofruar regjistra në një sistem monitorimi të centralizuar (për shembull Prometheus) dhe një sistem të mbledhjes së regjistrave (komutë softuerësh ELK). Diagrami më poshtë tregon se si funksionon një aplikacion cloud sipas Modelit të Testit Shëndetësor dhe Parimit të Vëzhgueshmërisë së Lartë.
Si të aplikoni modelin e kontrollit shëndetësor në Kubernetes?
Nga kutia, k8s monitoron statusin e pods duke përdorur një nga kontrollorët (
Në shembullin tonë, k8s bën kontrolli i funksionalitetit. Në këtë lloj verifikimi, kubelet kontrollon vazhdimisht gjendjen e procesit në kontejner. Sapo të kuptojë se procesi ka ndaluar, ai do ta rifillojë atë. Nëse gabimi mund të zgjidhet thjesht duke rifilluar aplikacionin dhe programi është krijuar për të mbyllur çdo gabim, atëherë një kontroll shëndetësor i procesit është gjithçka që ju nevojitet për të ndjekur NOP dhe modelin e testit shëndetësor. E vetmja keqardhje është se jo të gjitha gabimet eliminohen duke rifilluar. Në këtë rast, k8s ofron 2 mënyra më të thella për të identifikuar problemet me podin:
LivenessProbe
gjatë Sonda e gjallërisë kubelet kryen 3 lloje kontrollesh: jo vetëm që përcakton nëse pod po funksionon, por edhe nëse është gati për të marrë dhe për t'iu përgjigjur në mënyrë adekuate kërkesave:
- Vendosni një kërkesë HTTP në pod. Përgjigja duhet të përmbajë një kod përgjigjeje HTTP në intervalin nga 200 në 399. Kështu, kodet 5xx dhe 4xx sinjalizojnë se pod ka probleme, edhe pse procesi po funksionon.
- Për të testuar pods me shërbime jo HTTP (për shembull, serveri i postës Postfix), duhet të krijoni një lidhje TCP.
- Ekzekutoni një komandë arbitrare për një pod (brenda). Kontrolli konsiderohet i suksesshëm nëse kodi i përfundimit të komandës është 0.
Një shembull se si funksionon kjo. Përkufizimi tjetër i pod përmban një aplikacion NodeJS që hedh një gabim 500 në kërkesat HTTP. Për t'u siguruar që kontejneri të riniset kur merr një gabim të tillë, ne përdorim parametrin 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
Ky nuk është i ndryshëm nga çdo përkufizim tjetër i pod, por ne po shtojmë një objekt .spec.containers.livenessProbe
... Parametri httpGet
pranon rrugën në të cilën dërgohet kërkesa HTTP GET (në shembullin tonë kjo është /
, por në skenarë luftarakë mund të ketë diçka të tillë /api/v1/status
). Një tjetër livenessProbe pranon një parametër initialDelaySeconds
, i cili udhëzon operacionin e verifikimit të presë një numër të caktuar sekondash. Vonesa është e nevojshme sepse kontejneri ka nevojë për kohë për t'u nisur dhe kur të rindizet ai do të jetë i padisponueshëm për ca kohë.
Për të aplikuar këtë cilësim në një grup, përdorni:
kubectl apply -f pod.yaml
Pas disa sekondash, mund të kontrolloni përmbajtjen e pod duke përdorur komandën e mëposhtme:
kubectl describe pods node500
Në fund të prodhimit, gjeni
Siç mund ta shihni, livenessProbe inicioi një kërkesë HTTP GET, kontejneri gjeneroi një gabim 500 (që është ajo që ishte programuar të bënte) dhe kubelet e rifilloi atë.
Nëse po pyesni se si u programua aplikacioni NideJS, këtu janë app.js dhe Dockerfile që janë përdorur:
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" ]
Është e rëndësishme të kihet parasysh kjo: livenessProbe do të rifillojë kontejnerin vetëm nëse dështon. Nëse një rinisje nuk korrigjon gabimin që po pengon funksionimin e kontejnerit, kubelet nuk do të jetë në gjendje të ndërmarrë veprime për të korrigjuar problemin.
gatishmëriProbe
ReadinessProbe punon në mënyrë të ngjashme me livenessProbes (kërkesat GET, komunikimet TCP dhe ekzekutimi i komandave), me përjashtim të veprimeve për zgjidhjen e problemeve. Kontejneri në të cilin zbulohet dështimi nuk riniset, por është i izoluar nga trafiku në hyrje. Imagjinoni që një nga kontejnerët po kryen shumë llogaritje ose është nën ngarkesë të madhe, duke bërë që koha e përgjigjes të rritet. Në rastin e livenessProbe, aktivizohet kontrolli i disponueshmërisë së përgjigjes (përmes parametrit të kontrollit timeoutSeconds), pas së cilës kubelet rinis kontejnerin. Kur niset, kontejneri fillon të kryejë detyra me burime intensive dhe riniset përsëri. Kjo mund të jetë kritike për aplikacionet që kanë nevojë për shpejtësi përgjigjeje. Për shembull, një makinë ndërsa është në rrugë është duke pritur për një përgjigje nga serveri, përgjigja vonohet - dhe makina futet në një aksident.
Le të shkruajmë një përkufizim redinessProbe që do të vendosë kohën e përgjigjes së kërkesës GET në jo më shumë se dy sekonda dhe aplikacioni do t'i përgjigjet kërkesës GET pas 5 sekondash. Skedari pod.yaml duhet të duket kështu:
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
Le të vendosim një pod me kubectl:
kubectl apply -f pod.yaml
Le të presim disa sekonda dhe pastaj të shohim se si funksionoi ReadinessProbe:
kubectl describe pods nodedelayed
Në fund të daljes mund të shihni se disa nga ngjarjet janë të ngjashme
Siç mund ta shihni, kubectl nuk e rifilloi podin kur koha e kontrollit i kaloi 2 sekonda. Në vend të kësaj, ai e anuloi kërkesën. Komunikimet hyrëse ridrejtohen në pods të tjera funksionale.
Vini re se tani që pod është shkarkuar, kubectl i drejton përsëri kërkesat tek ai: përgjigjet ndaj kërkesave GET nuk vonohen më.
Për krahasim, më poshtë është skedari i modifikuar 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
Para ardhjes së aplikacioneve cloud, regjistrat ishin mjetet kryesore të monitorimit dhe kontrollit të shëndetit të aplikacionit. Megjithatë, nuk kishte asnjë mjet për të ndërmarrë ndonjë veprim korrigjues. Regjistrat janë ende të dobishëm sot; ato duhet të mblidhen dhe të dërgohen në një sistem të mbledhjes së regjistrave për të analizuar situatat emergjente dhe për të marrë vendime. [E gjithë kjo mund të bëhej pa aplikacione cloud duke përdorur monit, për shembull, por me k8 u bë shumë më e lehtë :) - shënimi i redaktorit. ]
Sot, korrigjimet duhet të bëhen pothuajse në kohë reale, kështu që aplikacionet nuk duhet të jenë më kuti të zeza. Jo, ato duhet të tregojnë pikat përfundimtare që lejojnë sistemet e monitorimit të kërkojnë dhe të mbledhin të dhëna të vlefshme për gjendjen e proceseve në mënyrë që ata të mund të përgjigjen menjëherë nëse është e nevojshme. Ky quhet modeli i dizajnit të testit të performancës, i cili ndjek Parimin e Vëzhgueshmërisë së Lartë (HOP).
Kubernetes ofron 2 lloje kontrollesh shëndetësore si parazgjedhje: ReadinessProbe dhe LivenessProbe. Të dy përdorin të njëjtat lloje kontrollesh (kërkesat HTTP GET, komunikimet TCP dhe ekzekutimi i komandave). Ato ndryshojnë në vendimet që marrin në përgjigje të problemeve në bishtaja. livenessProbe rinis kontejnerin me shpresën se gabimi nuk do të ndodhë më dhe ReadinessProbe izolon podin nga trafiku në hyrje derisa të zgjidhet shkaku i problemit.
Dizajni i duhur i aplikacionit duhet të përfshijë të dy llojet e kontrollit dhe të sigurojë që ato të mbledhin të dhëna të mjaftueshme, veçanërisht kur bëhet një përjashtim. Ai gjithashtu duhet të tregojë pikat fundore të nevojshme të API-së që i ofrojnë sistemit të monitorimit (Prometheus) metrika të rëndësishme shëndetësore.
Burimi: www.habr.com