Kubernetes konteinerite parimad praktikad: töövõimekuse kontrollid

TL;DR

• Konteinerite ja mikroteenuste, logide ja algsete mõõdikute kõrge jälgitavuse saavutamiseks on ebapiisav ainult logimine.
• Rakenduste kiireks taastamiseks ja tõrgeteta töökindluse suurendamiseks peaksid rakendused rakendama kõrge jälgitavuse põhimõtet (HOP, High Observability Principle).
• Rakenduse tasandil kõrge jälgitavuse rakendamisel on vajalik: korralik logimine, hoolikas jälgimine, töökindluse kontrollid ja jõudluse / üleminekute jälgimine.
• Nõudmise elemendina kasutage kontrolle readinessProbe ja livenessProbe Kubernetes.

Mis on töökindluse kontrollimise mall?

Kui kavandatakse kriitilise tähtsusega ja pidevalt kätte saadavat rakendust, on oluline mõelda sellisele aspektile nagu tõrke taluvus. Rakendus on tõrke taluv, kui see taastub kiiresti rikke korral. Tüüpiline pilverakendus kasutab mikroteenuste arhitektuuri – iga komponent paigutatakse eraldi konteinerisse. Ja et veenduda, et rakendus k8s on pidevalt kätte saadav, tuleb klastrit kavandades järgida teatud mustreid. Nende hulka kuulub ka elujõudluse kontrollimise muster. See määratleb, kuidas rakendus teavitab k8s oma elujõudlusest. See ei ole mitte ainult teave selle kohta, kas pod töötab, vaid ka see, kuidas ta päringutele vastab. Mida rohkem Kubernetes teab pod'i elujõudlusest, seda nutikamaid otsuseid ta teeb liikluse suunamise ja koormuse tasakaalustamise osas. Seega peab kõrge jälgitavuse põhimõte rakendusele õigeaegselt päringutele vastama.

Kõrge jälgitavuse põhimõte (KJP)

Kõrge jälgitavuse põhimõte on üks konteneriseeritud rakenduste projekteerimise põhimõtteid. Mikroteenuse arhitektuuris ei oma teenustele tähtsust, kuidas nende päringut töödeldakse (ja see on õige), vaid oluline on, kuidas saada vastuseid vastuvõtvate teenuste käest. Näiteks kasutaja autentimiseks saadab üks konteiner teisele HTTP-päringu, oodates vastust teatud formaadis – ja see on kõik. Päringut võib töödelda PythonJS ning vastata võib Python Flask. Konteinerid on üksteise jaoks nagu mustad kastid, mille sisu on varjatud. Siiski nõuab NORA põhimõte, et iga teenus avalikustaks mitu API lõpp-punkti, mis näitavad, kui hästi see töötab, samuti selle valmiduse ja tõrkekindluse seisundit. Need näitajad küsib Kubernetes, et teha läbi mõeldud järgmised sammud marsruutimise ja koormuse tasakaalu seadistamisel.

Hästi kavandatud pilve rakendus logib oma põhitegevusi, kasutades standardseid sisendi- ja väljundi vooge STDERR ja STDOUT. Seejärel töötab abiteenus, näiteks filebeat, logstash või fluentd, mis edastab logid tsentraliseeritud jälgimissüsteemi (nt Prometheus) ja logide kogumise süsteemi (ELK tarkvarakogum). Allolevas skeemis on näidatud, kuidas pilve rakendus töötab töökindluse kontrollimise Malli ja kõrge jälgitavuse põhimõtte kohaselt.

Kuidas rakendada töökindluse kontrollimise Malli Kuberneteses?

Karbist välja k8s jälgib pod'ide seisundit ühe kontrollimise abil (Deployments, ReplicaSets, DaemonSets, StatefulSets ja ja muud). Kui k8s avastab, et pod mingil põhjusel on kukkunud, üritab kontroller seda taaskäivitada või teisele sõlmele üle viia. Kuid pod võib teatada, et see on käivitatud ja töötab, samas aga ei täida oma ülesandeid. Näiteks: teie rakendus kasutab veebiserverina Apache't ja olete seadnud komponendi mitmele pod'ile klastris. Kuna teek on valesti konfigureeritud – kõik rakendusele suunatud päringud vastavad koodiga 500 (sisemine serveri viga). Toimuvate kontrollide ajal annab pod'ide oleku kontrollimine positiivse tulemuse, kuid kliendid arvavad teisiti. Kirjeldame seda soovimatut olukorda järgmiselt:

Meie näites k8s teostab olekukontrolli. Sellisel kontrolli vormil kontrollib kubelet pidevalt konteineriprotsessi seisundit. Kui ta mõistab, et protsess on seisma jäänud, ta taaskäivitab selle. Kui viga lahendatakse rakenduse lihtsa taaskäivitamisega ning programm on loodud nii, et see lülitub välja iga vea korral, siis piisab töökindluse ja töövõimekuse kontrollimiseks protsessi seisundi jälgimisest. Kahju, et mitte kõik vead ei lahene taaskäivitamisega. Selleks pakub k8s kahte sügavamat viisi pod'i tööprobleemide tuvastamiseks: livenessProbe ja readinessProbe.

LivenessProbe

Ajal livenessProbe kubelet teostab 3 tüüpi kontrolle: selgitatakse välja mitte ainult see, kas pod töötab, vaid ka see, kas see on valmis vastu võtma ja adekvaatselt vastama päringutele:

• Seadke HTTP-päring pod'ile. Vastus peab sisaldama HTTP-koodi vahemikus 200 kuni 399. Seega, koodid 5xx ja 4xx annavad märku pod'i probleemidest, isegi kui protsess töötab.
• Pod'ide kontrollimiseks, kus on mitte-HTTP teenused (näiteks postiserver Postfix), tuleb luua TCP-ühendus.
• Võimaldage sisemiselt suvalise käsu täitmine pod'ile. Kontroll loetakse edukaks, kui käsu lõpetamise kood on 0.

Näide sellest, kuidas see töötab. Järgmise pod'i määratlemine sisaldab NodeJS rakendust, mis tagastab HTTP-päringutele veakoodi 500. Veendumiseks, et konteiner taaskäivitub, kui see viga ilmneb, kasutame parameetrit 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

See ei erine ühegi teise pod'i määratlemisest, kuid me lisame objekti .spec.containers.livenessProbe. Parameeter httpGet võtab tee, kuhu saadetakse HTTP GET päring (meie näites on see /, kuid tootmisstsenaariumides võib see olla ka midagi sellist nagu /api/v1/status). Samuti võtab livenessProbe parameetri initialDelaySeconds, mis määrab, et kontrollimise operatsioon peab ootama määratud arvu sekundeid. Ooteaeg on vajalik, kuna konteiner vajab käivitamiseks aega ja taaskäivitamisel ei ole see mõnda aega saadaval.

Selle seadistuse rakendamiseks klastrile, kasutage:

kubectl apply -f pod.yaml

Mõne sekundi pärast saab pod'i sisu kontrollida järgmisel käsul:

kubectl describe pods node500

Lõpus väljundi leidmiseks otsige sellist asja.

Kuidas näha, livenessProbe käivitas HTTP GET päringu, konteiner andis vea 500 (nagu oli ette nähtud), kubelet taaskäivitas selle.

Kui teid huvitab, kuidas NideJS rakendust programmeeritud, siin on fail app.js ja Dockerfile, mida kasutati:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("Oleme sattunud veassen");
});

server.listen(3000, function() {
    console.log('Server töötab aadressil 3000')
})

Dockerfile

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

Oluline on tähele panna järgmist: livenessProbe taaskäivitab konteineri ainult tõrke korral. Kui taaskäivitamine ei paranda viga, mis takistab konteineri tööd, ei saa kubelet astuda samme rikke kõrvaldamiseks.

readinessProbe

readinessProbe töötab samamoodi nagu livenessProbe (GET-päringud, TCP ühendused ja käsu täitmine), välja arvatud tõrkeotsingu tegevused. Konteiner, millel on ilmnenud tõrge, ei taaskäivitu, vaid eraldatakse sissetulevast liiklusest. Kujutage ette, et üks konteineritest teeb palju arvutusi või talub suurt koormust, mistõttu vastuse aeg päringutele tõuseb. LivenessProbe puhul kontrollitakse vastuse kättesaadavust (parameetri timeoutSeconds kaudu), mille järel kubelet taaskäivitab konteineri. Kui konteiner käivitub, hakkab ta tegema ressursimahukaid ülesandeid ja teda taaskäivitavad taas. See võib olla kriitiline rakenduste jaoks, millele on oluline vastuse kiirus. Näiteks auto ootab serverilt vastust, vastus viibib – ja auto satub avariisse.

Kirjutame readinessProbe määratluse, mis seadistab GET-päringu vastuse aja mitte üle kahe sekundi ja rakendus vastab GET-päringule viie sekundi jooksul. Fail pod.yaml peaks välja nägema järgmiselt:

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

Käivitame pod'i kubectl-iga:

kubectl apply -f pod.yaml

Ootame paar sekundit ja seejärel vaatame, kuidas readinessProbe tööle hakkas:

kubectl describe pods nodedelayed

Väljundi lõpus võib näha, et osa sündmusi on sarnane sellega.

Nagu näete, ei käivitanud kubectl pod'i uuesti, kui kontrolli aeg ületas 2 sekundit. Selle asemel tühistati päring. Sisse tulevad ühendused suunatakse teistele, töötavatele pod'idele.

Märkige: nüüd, kui pod'il on vähenenud koormus, suunab kubectl taas päringud sellele: GET-päringutele vastamine ei viibinud enam.

Võrdluseks: allpool on toodud muudetud fail 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
Enne pilvetehnoloogia rakenduste tekkimist olid logid põhi tööriistad rakenduste jälgimiseks ja oleku kontrollimiseks. Siiski puudusid meetodid tõrgete kõrvaldamiseks. Logid on endiselt kasulikud, neid tuleb koguda ja saata logide kogumisse süsteemi analüüsimiseks ning otsuste tegemiseks. [Seda kõik sai teha ka ilma pilvetehnoloogiateta, näiteks monitiga, kuid k8s-i abil on see saanud oluliselt lihtsamaks 🙂 – toimetaja kommentaar. ]

Tänapäeval tuleb muudatusi teha peaaegu reaalajas, seega ei tohiks rakendused enam olla mustad karbid. Ei, need peaksid näitama lõpp-punkte, mis võimaldavad jälgimissüsteemidel küsida ja koguda väärtuslikku teavet protsesside oleku kohta, et reageerida vajadusel hetkega. Seda nimetatakse töövõimekuse kontrollimise kujundimudeliks, mis järgib kõrge jälgitavuse printsiipi (NORM).

Kubernetes pakub vaikimisi kahte tüüpi kasutatavuse kontrolli: readinessProbe ja livenessProbe. Mõlemad kasutavad samu kontrollitüüpe (HTTP GET-päringud, TCP-ühendused ja käskude täitmine). Erinevus seisneb selles, milliseid otsuseid nad teevad, kui pod’ides esineb tõrkeid. livenessProbe taaskäivitab konteineri, lootes, et viga enam ei kordu, samas kui readinessProbe eraldab pod’i sisenevast liiklusest kuni tõrke põhjuse kõrvaldamiseni.

Rakenduse õige projekteerimine peab hõlmama mõlemat tüüpi kontrolli ning koguma piisavalt andmeid, eriti siis, kui tekib erandlik olukord. Samuti peab see näitama vajalikke API lõpp-punkte, mis edastavad süsteemile jälgimiseks (nt Prometheus) olulisi jõudluse oleku mõõdikuid.

Allikas: habr.com