Parimad praktikad Kubernetes konteinerite jaoks: töökindluse kontrollimine

TL;DR

• Konteinerite ja mikroteenuste, logide ja primaarsete mõõdikute kõrge jälgitavuse saavutamiseks on vähe.
• Kiiremaks taasteks ja rakenduse tõrketaluvuse suurendamiseks peavad rakendused rakendama kõrge jälgitavuse põhimõtteid (HOP, High Observability Principle).
• Rakenduse tasandil nõuab HOP nõuetekohast logimist, hoolikal jälgimist, töökindluse kontrolli ja jõudluse/üleminekute jälgimist.
• HOP-i elemendina kasutage kontrollimisi readinessProbe ja livenessProbe Kuberneteses.

Mis on töökindluse kontrolli mall?

Kriitiliselt olulise ja kõrgelt kättesaadava rakenduse kavandamisel on väga oluline mõelda sellisele aspektile nagu tõrketaluvus. Rakendus on tõrketaluv, kui see taasteb kiiresti pärast ebaõnnestumist. Tüüpiline pilvrakendus kasutab mikroteenuste arhitektuuri – kus iga komponent asetatakse eraldi konteinerisse. Ja et veenduda, et rakendus k8s-is on kõrgelt kättesaadav, tuleb klastrit kavandades järgida teatud malli. Nende seas on töökindluse kontrolli mall. See määratleb, kuidas rakendus teatab k8s-ile oma töökindlusest. See ei ole ainult teave selle kohta, kas pod töötab, vaid ka selle kohta, kuidas see päringuid vastu võtab ja neile vastab. Mida rohkem Kubernetes teab pod’i töökindlusest, seda nutikamaid otsuseid ta teeb liikluse suunamise ja koormuse tasakaalustamise osas. Seega peab rakendus järgima kõrge jälgitavuse põhimõtteid, et õigeaegselt vastata päringutele.

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

Kõrge jälgitavuse põhimõte on üks konteineriseeritud rakenduste projekteerimise põhimõtteidMikroteenuste arhitektuuris ei oma teenused mingit tähtsust sellele, kuidas nende päringut töödeldakse (ja see on õige), kuid oluline on see, kuidas saada vastuseid vastuvõtvate teenuste käest. Näiteks, kasutaja autentimiseks saadab üks konteiner teisele HTTP päringu, oodates vastust kindlas vormingus – ja see on kõik. Päringut võib töödelda PythonJS ja vastuse võib anda Python Flask. Konteinerid on üksteise jaoks justkui mustad kastid, mille sisu on varjatud. Siiski nõuab NOR põhimõte, et iga teenus avaldaks mitmeid API lõpp-punkte, mis näitavad, kui hästi see töötab, samuti oma valmisoleku ja vigade taluvuse seisundit. Need näitajad küsib Kubernetes, et mõelda järgmiste sammude üle marsruutimise ja koormuse tasakaalu mateerimise osas.

Hästi projekteeritud pilve rakendus logib oma põhieevents kasutades standardseid sisend- ja väljundvooge STDERR ja STDOUT. Järgmisena töötab abiteenus, näiteks filebeat, logstash või fluentd, mis toimetavad logid tsentraliseeritud jälgimisse süsteemi (nt Prometheus) ja logide kogumise süsteemi (ELK tarkvara komplekt). Alloleval skeemil on näidatud, kuidas pilve rakendus töötab vastavalt töökindluse kontrollimise šabloonile ja kõrge jälgitavuse põhimõttele.

Kuidas rakendada töökindluse kontrollimise šablooni Kuberneteses?

K8s jälgib välja pandud pod’ide olekut välja arvatud kontrollijate abil (Deployments, ReplicaSets, DaemonSets, StatefulSets jne, jne). Kui kontrollija tuvastab, et pod mingi põhjusel kukkus, proovib see selle taaskäivitada või ümber ajastada teisele sõlmele. Siiski võib pod teatada, et see on käivitunud ja töötab, kuid tegelikult ei tööta see. Toome näite: teie rakendus kasutab veebiserverina Apache’t, olete paigaldanud komponendi mitmesse pod’ide klastrisse. Kuna teek on halvasti konfigureeritud – kõik päringud rakendusele tagastavad koodi 500 (sisevea). Tarnimise kontrollimisel annab pod’ide oleku kontrollimise tulemus positiivse tulemuse, kuid kliendid arvavad teisiti. Kirjeldame seda ebasoovitavat olukorda järgmiselt:

Meie näites teeb k8s töökindluse kontrollimistSelles kontrolliviisis kontrollib kubelet pidevalt konteineri protsessi seisundit. Kui ta mõistab, et protsess on seisma jäänud, käivitab ta selle uuesti. Kui viga lahendatakse lihtsalt rakenduse taaskäivitamisega ja programm on üles ehitatud selleks, et igasuguste vigade korral sulguda, siis piisab NORM-i ja tööoleku kontrolldiagrammi järgimiseks protsessi tööoleku kontrollimisest. Kahju ainult, et mitte kõik vead ei lahene taaskäivitamisega. Selleks pakub k8s kahte sügavamat viis, kuidas pod’i tõrkeid avastada: livenessProbe ja readinessProbe.

LivenessProbe

Ajal livenessProbe kubelet viib ellu 3 tüüpi kontrolli: see mitte ainult ei selgita, kas pod töötab, vaid kontrollib ka, kas see on valmis vastu võtma ja adekvaatselt vastama päringutele:

• Seadistage HTTP-päring pod'ile. Vastus peab sisaldama HTTP-koodi vahemikus 200 kuni 399. Nii tähendavad 5xx ja 4xx koodid, et pod'il on probleeme, isegi kui protsess töötab.
• Pod'ide kontrollimiseks, millel ei ole HTTP teenuseid (nt Postfixi meiliserver), tuleb luua TCP-ühendus.
• Siseprotsessi taotlemine pod'ile. Kontroll loetakse edukaks, kui käsu väljumiskood on 0.

Näide, kuidas see töötab. Järgmise pod'i määratlemine sisaldab NodeJS rakendust, mis reageerib HTTP-päringutele veateatega 500. Veenduda, et konteiner taaskäivitub, kui selline 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 millegi poolest igasugusest muust pod'i määratlemisest, kuid me lisame objekti .spec.containers.livenessProbe. Parameeter httpGet võtab vastu tee, kuhu saadetakse HTTP GET päring (meie näites see on /, kuid tõelistel stsenaariumitel võib see olla midagi sellist nagu /api/v1/status). Samuti võtab livenessProbe vastu parameetri initialDelaySeconds, mis määrab, kui kaua kontrollimise tegevustele oodatakse. Ooteaeg on vajalik seetõttu, et konteineril on käivitamiseks aega, ja taaskäivitamise korral on see mõnda aega kättesaamatu.

Selle seadistuse rakendamiseks klastrile kasutage:

kubectl apply -f pod.yaml

Mõne sekundi pärast saate pod'i sisu kontrollida järgmise käsuga:

kubectl describe pods node500

Väljundi lõpus leidke selline asi.

Nagu näete, livenessProbe käivitas HTTP GET päringu, konteiner andis sisendi 500 (milleks ta oligi programmeeritud), kubelet ta taaskäivitada.

Kui teil on huvi, kuidas oli programmeeritud NodeJS rakendus, siis 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 kohtunud veaga
");
});

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

Dockerfile

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

Oluline on tähele panna, et livenessProbe taaskäivitab konteineri ainult rikke korral. Kui taaskäivitamine ei paranda muudatust, mis takistab konteineri tööd, ei suuda kubelet tegeleda tõrke kõrvaldamisega.

readinessProbe

readinessProbe töötab sarnaselt livenessProbes'ile (GET-päringud, TCP ühendused ja käskude täitmine), välja arvatud tõrgete kõrvaldamise toimingud. Konnteiner, kus rike on registreeritud, ei taaskäivita, vaid isoleeritakse sissetulevast liiklusest. Kujutage ette, et üks konteiner teeb palju arvutusi või sellest on suur koormus, mis põhjustab vastuste aeglustumist. LivenessProbe'i puhul aktiveeritakse vastuvõtu kättesaadavuse kontroll (timeoutSeconds parameetri kaudu), pärast mida kubelet taaskäivitab konteineri. Taevas konteiner hakkab uuesti ressursimahukaid ülesandeid täitma ja taaskäivitavad seda taas. See võib olla kriitiline rakendustele, mis peavad vastama kiiresti. Näiteks masin on õigeaegselt serveri vastuse ootuses, vastus viibib - ja masin satub avariisse.

Kirjutame readinessProbe'i määratlemise, mis seab GET-päringute vastuseaja mitte rohkem kui kaks sekundit, samas kui rakendus vastab GET-päringule 5 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äivita pod kubectliga:

kubectl apply -f pod.yaml

Ootame paar sekundit ja siis vaatame, kuidas readinessProbe töötab:

kubectl describe pods nodedelayed

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

Nagu näete, ei taaskäivitanud kubectl pod'i, kui kontrollimise aeg ületas 2 sekundit. Selle asemel tühistati päring. Sissetulevad ühendused suunatakse teistele, töötavatele pod'idele.

Märkus: nüüd, kui pod’ilt on eemaldatud liigne koormus, suunab kubectl taas päringud sellele: GET-päringute vastused ei viivita enam.

Võrdluseks: allpool on 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 pilveteenuste ilmumist olid rakenduste jälgimise ja oleku kontrollimise põhivahendid logid. Kuid puudusid vahendid, et probleemide lahendamiseks midagi ette võtta. Logid on tänapäeval endiselt kasulikud, neid tuleb koguda ja saata logide kogumisse süsteemi analüüsimiseks ja otsuste tegemiseks. [kõike seda oleks saanud teha ka ilma pilveteenusteta, näiteks monit’i abil, kuid k8s on teinud selle palju lihtsamaks 🙂 – toimetaja märkus. ]

Tänapäeval peavad parandused toimuma peaaegu reaalajas, seega ei tohiks rakendused enam olla mustad kastid. Ei, nad peavad näitama lõpp-punkte, mis võimaldavad jälgimissüsteemidel koguda väärtuslikke andmeid protsesside oleku kohta, et vajadusel kiirelt reageerida. Seda nimetatakse Töökindluse kontrollimise disainimustriks, mis järgib Kõrge Jälgitavuse Printsiipi (HOP).

Kubernetes pakub vaikimisi kahte tüüpi töökindluse kontrollimist: readinessProbe ja livenessProbe. Mõlemad kasutavad samu kontrollimise tüüpe (HTTP GET päringud, TCP ühendused ja käskude täitmine). Need erinevad selles, milliseid otsuseid tehakse pod’ide probleemide korral. livenessProbe taaskäivitab konteineri lootuses, et viga ei kordu, samas kui readinessProbe eraldab pod’i sissetulevast liiklusest – kuni probleemi põhjus on kõrvaldatud.

Rakenduse õige projekteerimine peaks hõlmama mõlemat tüüpi kontrolli ning need peaksid koguma piisavalt andmeid, eriti erandlike olukordade korral. Samuti peab see näitama vajalikke API lõpp-punkte, mis edastavad jälgimissüsteemile (näiteks Prometheus) olulisi töökindluse oleku mõõdikuid.

Allikas: habr.com