Geriausia „Kubernetes“ konteinerių praktika: sveikatos patikrinimai

Lt; DR

• Norint pasiekti aukštą konteinerių ir mikropaslaugų stebėjimą, neužtenka žurnalų ir pirminės metrikos.
• Siekiant greitesnio atkūrimo ir didesnio atsparumo, programos turėtų taikyti didelio stebėjimo principą (HOP).
• Programos lygiu NOP reikalauja: tinkamo registravimo, atidaus stebėjimo, sveiko proto patikrinimų ir našumo / perėjimo sekimo.
• Naudokite čekius kaip NOR elementą pasirengimasZondas и gyvumo zondas Kubernetes.

Kas yra sveikatos patikrinimo šablonas?

Kuriant itin svarbią ir labai prieinamą programą, labai svarbu pagalvoti apie tokį aspektą kaip atsparumas gedimams. Programa laikoma atsparia gedimams, jei ji greitai atsigauna po gedimo. Įprastoje debesies programoje naudojama mikropaslaugų architektūra, kai kiekvienas komponentas dedamas į atskirą konteinerį. Ir norėdami įsitikinti, kad k8s programa yra labai prieinama, kai kuriate klasterį, turite laikytis tam tikrų modelių. Tarp jų yra sveikatos patikrinimo šablonas. Tai apibrėžia, kaip programa praneša k8s, kad ji yra sveika. Tai ne tik informacija apie tai, ar podas veikia, bet ir apie tai, kaip jis gauna ir reaguoja į užklausas. Kuo daugiau „Kubernetes“ žino apie „And“ būklę, tuo protingesnius sprendimus ji priima dėl srauto maršrutų nustatymo ir apkrovos balansavimo. Taigi didelio stebėjimo principas leidžia programai laiku atsakyti į užklausas.

Aukšto stebėjimo principas (HOP)

Aukšto stebimumo principas yra vienas iš konteinerinių programų projektavimo principai. Mikropaslaugų architektūroje paslaugoms nerūpi, kaip apdorojama jų užklausa (ir teisingai), bet svarbu, kaip jos gauna atsakymus iš gaunančių paslaugų. Pavyzdžiui, norėdamas autentifikuoti vartotoją, vienas konteineris siunčia HTTP užklausą kitam, tikėdamasis atsakymo tam tikru formatu – viskas. PythonJS taip pat gali apdoroti užklausą, o Python Flask gali atsakyti. Konteineriai yra tarsi juodos dėžės su paslėptu turiniu. Tačiau pagal NOP principą reikalaujama, kad kiekviena paslauga atskleistų kelis API galinius taškus, rodančius jos sveikumą, taip pat jos parengtį ir atsparumo gedimams būseną. „Kubernetes“ reikalauja šių rodiklių, kad galėtų apgalvoti tolesnius maršruto parinkimo ir apkrovos balansavimo veiksmus.

Gerai suprojektuota debesies programa registruoja savo pagrindinius įvykius naudodama standartinius įvesties / išvesties srautus STDERR ir STDOUT. Toliau ateina pagalbinė paslauga, pvz., filebeat, logstash arba fluentd, siunčianti žurnalus į centralizuotą stebėjimo sistemą (pvz., Prometheus) ir žurnalų rinkimo sistemą (ELK programinės įrangos paketą). Toliau pateiktoje diagramoje parodyta, kaip debesies programa veikia pagal sveikatos patikrinimo modelį ir didelio stebėjimo principą.

Kaip taikyti sveikatos patikrinimo modelį Kubernetes?

Išimtas iš dėžutės, k8s stebi ankščių būseną naudodamas vieną iš valdiklių (dislokavimo, ReplicaSets, DaemonSets, StatefulSets ir tt ir tt). Aptikęs, kad podas dėl kokios nors priežasties nukrito, valdiklis bando jį paleisti iš naujo arba perkelti į kitą mazgą. Tačiau talpykla gali pranešti, kad ji veikia, bet pati neveikia. Pateiksime pavyzdį: jūsų programa naudoja „Apache“ kaip žiniatinklio serverį, jūs įdiegėte komponentą keliuose klasterio blokuose. Kadangi biblioteka buvo sukonfigūruota neteisingai, visos programos užklausos atsako kodu 500 (vidinė serverio klaida). Tikrinant pristatymą, ankščių būklės patikrinimas duoda sėkmingą rezultatą, tačiau klientai galvoja kitaip. Šią nepageidaujamą situaciją apibūdinsime taip:

Mūsų pavyzdyje k8s tai daro funkcionalumo patikrinimas. Šio tipo patikros metu kubeletas nuolat tikrina proceso būseną konteineryje. Kai jis supras, kad procesas sustojo, jis pradės jį iš naujo. Jei klaidą galima išspręsti paprasčiausiai iš naujo paleidus programą, o programa sukurta taip, kad išsijungtų dėl bet kokios klaidos, tai viskas, ko jums reikia, kad būtų laikomasi NOP ir sveikatos testo modelio. Gaila tik, kad ne visos klaidos pašalinamos paleidus iš naujo. Šiuo atveju k8s siūlo 2 gilesnius būdus, kaip nustatyti podelio problemas: gyvumo zondas и pasirengimasZondas.

LivenessProbe

Per gyvumo zondas kubelet atlieka 3 tipų patikras: ne tik nustato, ar podas veikia, bet ir ar yra pasirengęs priimti ir tinkamai reaguoti į užklausas:

• Nustatykite HTTP užklausą prie grupės. Atsakyme turi būti HTTP atsako kodas, kurio diapazonas yra nuo 200 iki 399. Taigi kodai 5xx ir 4xx rodo, kad podelyje kyla problemų, net jei procesas vyksta.
• Norėdami išbandyti blokus su ne HTTP paslaugomis (pvz., „Postfix“ pašto serveriu), turite užmegzti TCP ryšį.
• Vykdykite savavališką rinkinio komandą (viduje). Patikrinimas laikomas sėkmingu, jei komandos užbaigimo kodas yra 0.

Pavyzdys, kaip tai veikia. Kitame pod apibrėžime yra NodeJS programa, kuri pateikia 500 klaidą HTTP užklausose. Norėdami įsitikinti, kad konteineris paleidžiamas iš naujo gavus tokią klaidą, naudojame parametrą 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

Tai niekuo nesiskiria nuo bet kurio kito podėlio apibrėžimo, bet mes pridedame objektą .spec.containers.livenessProbe. Parametras httpGet priima kelią, kuriuo siunčiama HTTP GET užklausa (mūsų pavyzdyje tai yra /, tačiau koviniuose scenarijuose gali būti kažkas panašaus /api/v1/status). Kitas gyvumasProbe priima parametrą initialDelaySeconds, kuri nurodo patvirtinimo operacijai palaukti nurodytą sekundžių skaičių. Delsimas reikalingas, nes konteineriui reikia laiko paleisti, o paleidus iš naujo jis kurį laiką bus nepasiekiamas.

Norėdami taikyti šį nustatymą klasteriui, naudokite:

kubectl apply -f pod.yaml

Po kelių sekundžių galite patikrinti paketo turinį naudodami šią komandą:

kubectl describe pods node500

Išvesties pabaigoje raskite štai ką.

Kaip matote, „livenessProbe“ inicijavo HTTP GET užklausą, konteineris sugeneravo 500 klaidą (būtent tai buvo užprogramuota), o „kubelet“ jį paleido iš naujo.

Jei jums įdomu, kaip buvo užprogramuota „NideJS“ programa, čia buvo naudojami „app.js“ ir „Dockerfile“ failai:

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

Svarbu atkreipti dėmesį į tai: „livenessProbe“ konteinerį paleis iš naujo, tik jei nepavyks. Jei paleidus iš naujo klaida, dėl kurios sudėtinis rodinys negali paleisti, neištaisoma, kubeletas negalės imtis veiksmų problemai išspręsti.

pasirengimasZondas

ReadinessProbe veikia panašiai kaip livenessProbes (GET užklausos, TCP ryšys ir komandų vykdymas), išskyrus trikčių šalinimo veiksmus. Konteineris, kuriame aptiktas gedimas, nėra paleidžiamas iš naujo, bet yra izoliuotas nuo gaunamo srauto. Įsivaizduokite, kad vienas iš konteinerių atlieka daug skaičiavimų arba yra labai apkrautas, todėl reakcijos laikas pailgėja. LivenessProbe atveju suaktyvinamas atsako pasiekiamumo patikrinimas (per timeoutSeconds check parametrą), po kurio kubeletas iš naujo paleidžia konteinerį. Paleidus konteinerį, jis pradeda atlikti daug išteklių reikalaujančias užduotis ir vėl paleidžiamas iš naujo. Tai gali būti labai svarbu programoms, kurioms reikalingas atsako greitis. Pavyzdžiui, automobilis kelyje laukia atsakymo iš serverio, atsakymas vėluoja – ir automobilis patenka į avariją.

Parašykime redinessProbe apibrėžimą, kuris nustatys GET užklausos atsakymo laiką ne ilgiau kaip dvi sekundes, o programa atsakys į GET užklausą po 5 sekundžių. Failas pod.yaml turėtų atrodyti taip:

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

Įdiegkime rinkinį su kubectl:

kubectl apply -f pod.yaml

Palaukime kelias sekundes ir pažiūrėkime, kaip veikė ReadinessProbe:

kubectl describe pods nodedelayed

Išvesties pabaigoje galite pamatyti, kad kai kurie įvykiai yra panašūs šitas.

Kaip matote, kubectl nepaleido iš naujo, kai tikrinimo laikas viršijo 2 sekundes. Vietoj to jis atšaukė prašymą. Įeinantys ryšiai nukreipiami į kitus veikiančius blokus.

Atminkite, kad dabar, kai podas iškraunamas, kubectl vėl nukreipia užklausas į jį: atsakymai į GET užklausas nebeatidedami.

Palyginimui, toliau pateikiamas modifikuotas failas 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')
})

Lt; DR
Prieš atsirandant debesų programoms, žurnalai buvo pagrindinė programos būklės stebėjimo ir tikrinimo priemonė. Tačiau nebuvo jokių priemonių imtis taisomųjų veiksmų. Žurnalai naudingi ir šiandien, juos reikia surinkti ir siųsti į žurnalų surinkimo sistemą, kad būtų galima analizuoti avarines situacijas ir priimti sprendimus. [Visa tai buvo galima padaryti be debesų aplikacijų naudojant, pavyzdžiui, monit, bet su k8s tai tapo daug lengviau :) – redaktoriaus pastaba. ]

Šiandien pataisymai turi būti atliekami beveik realiu laiku, todėl programos nebeturi būti juodosios dėžės. Ne, jie turėtų rodyti galinius taškus, leidžiančius stebėjimo sistemoms teikti užklausas ir rinkti vertingus duomenis apie procesų būseną, kad prireikus galėtų nedelsiant reaguoti. Tai vadinama „Performance Test Design Pattern“, kuri vadovaujasi aukšto stebėjimo principu (HOP).

Pagal numatytuosius nustatymus „Kubernetes“ siūlo 2 tipų sveikatos patikrinimus: ReadinessProbe ir LivenessProbe. Abu naudoja tų pačių tipų patikras (HTTP GET užklausas, TCP ryšį ir komandų vykdymą). Jie skiriasi tuo, kokius sprendimus priima reaguodami į ankščių problemas. livenessProbe iš naujo paleidžia konteinerį, tikėdamasis, kad klaida nepasikartos, o ReadinessProbe izoliuoja podą nuo gaunamo srauto, kol bus pašalinta problemos priežastis.

Tinkamas programos dizainas turėtų apimti abiejų tipų patikrinimus ir užtikrinti, kad jie surinktų pakankamai duomenų, ypač kai daroma išimtis. Jame taip pat turėtų būti parodyti būtini API galutiniai taškai, teikiantys stebėjimo sistemai („Prometheus“) svarbius sveikatos rodiklius.

Šaltinis: www.habr.com