Najbolji primjeri iz prakse za Kubernetes kontejnere: Provjere ispravnosti

TL; DR

• Da bi se postigla visoka vidljivost spremnika i mikroservisa, dnevnici i primarna metrika nisu dovoljni.
• Za brži oporavak i povećanu otpornost, aplikacije bi trebale primjenjivati ​​načelo visoke vidljivosti (HOP).
• Na razini aplikacije, NOP zahtijeva: pravilno bilježenje, pažljivo praćenje, provjere ispravnosti i praćenje performansi/prijelaza.
• Koristite čekove kao element NOR-a spremnost Probe и živost Probe Kubernetes.

Što je predložak za provjeru stanja?

Prilikom dizajniranja kritične i visoko dostupne aplikacije, vrlo je važno razmišljati o takvom aspektu kao što je tolerancija na pogreške. Aplikacija se smatra tolerantnom na greške ako se brzo oporavi od kvara. Tipična aplikacija u oblaku koristi arhitekturu mikroservisa – gdje se svaka komponenta nalazi u zasebnom spremniku. A kako biste bili sigurni da je aplikacija na k8s vrlo dostupna kada dizajnirate klaster, morate slijediti određene obrasce. Među njima je predložak za provjeru stanja. Definira kako aplikacija komunicira s k8s da je zdrava. Ovo nije samo informacija o tome radi li pod, već i o tome kako prima zahtjeve i odgovara na njih. Što više Kubernetes zna o zdravlju modula, donosi pametnije odluke o usmjeravanju prometa i balansiranju opterećenja. Dakle, princip visoke vidljivosti omogućuje aplikaciji da odgovori na zahtjeve na vrijeme.

Načelo visoke vidljivosti (HOP)

Načelo visoke uočljivosti jedno je od načela za projektiranje kontejnerskih aplikacija. U arhitekturi mikroservisa, servisima nije bitno kako se njihov zahtjev obrađuje (i to je s pravom), već je važno kako primaju odgovore od servisa primatelja. Na primjer, za autentifikaciju korisnika, jedan spremnik šalje HTTP zahtjev drugome, očekujući odgovor u određenom formatu - to je sve. PythonJS također može obraditi zahtjev, a Python Flask može odgovoriti. Kontejneri su poput crnih kutija sa skrivenim sadržajem jedni drugima. Međutim, NOP načelo zahtijeva od svake usluge da izloži više API krajnjih točaka koje pokazuju koliko je zdrava, kao i njenu spremnost i status tolerancije na greške. Kubernetes zahtijeva ove indikatore kako bi razmislio o sljedećim koracima za usmjeravanje i balansiranje opterećenja.

Dobro dizajnirana aplikacija u oblaku bilježi svoje glavne događaje pomoću standardnih I/O tokova STDERR i STDOUT. Zatim dolazi pomoćna usluga, na primjer filebeat, logstash ili fluentd, koja isporučuje zapise centraliziranom nadzornom sustavu (na primjer Prometheus) i sustavu za prikupljanje zapisa (programski paket ELK). Donji dijagram prikazuje kako aplikacija u oblaku radi prema uzorku testiranja zdravlja i načelu visoke vidljivosti.

Kako primijeniti obrazac provjere stanja u Kubernetesu?

Izvan kutije, k8s prati status mahuna pomoću jednog od kontrolera (implementacija, ReplikaSetovi, DaemonSets, StatefulSets itd. itd.). Nakon što otkrije da je modul iz nekog razloga pao, kontroler ga pokušava ponovno pokrenuti ili premjestiti na drugi čvor. Međutim, modul može prijaviti da radi i radi, ali sam ne funkcionira. Navedimo primjer: vaša aplikacija koristi Apache kao web poslužitelj, instalirali ste komponentu na nekoliko podova klastera. Budući da je knjižnica pogrešno konfigurirana, svi zahtjevi prema aplikaciji odgovaraju kodom 500 (interna pogreška poslužitelja). Kod provjere isporuke, provjera statusa mahuna daje uspješan rezultat, ali kupci misle drugačije. Ovu neželjenu situaciju opisat ćemo na sljedeći način:

U našem primjeru, k8s to radi provjera funkcionalnosti. U ovoj vrsti verifikacije, kubelet kontinuirano provjerava stanje procesa u spremniku. Nakon što shvati da je proces zaustavljen, ponovno će ga pokrenuti. Ako se pogreška može riješiti jednostavnim ponovnim pokretanjem aplikacije, a program je dizajniran da se isključi u slučaju bilo kakve pogreške, tada je provjera ispravnosti procesa sve što trebate slijediti NOP i obrazac za testiranje zdravlja. Jedina je šteta što se sve greške ne uklanjaju ponovnim pokretanjem. U ovom slučaju k8s nudi 2 dublja načina za prepoznavanje problema s modulom: živost Probe и spremnost Probe.

LivenessProbe

Tijekom živost Probe kubelet obavlja 3 vrste provjera: ne samo da utvrđuje radi li pod, već i je li spreman primiti i adekvatno odgovoriti na zahtjeve:

• Postavite HTTP zahtjev za pod. Odgovor mora sadržavati HTTP kod odgovora u rasponu od 200 do 399. Dakle, kodovi 5xx i 4xx signaliziraju da modul ima problema, iako se proces izvodi.
• Za testiranje podova s ​​uslugama koje nisu HTTP (na primjer, Postfix poslužitelj e-pošte), trebate uspostaviti TCP vezu.
• Izvršite proizvoljnu naredbu za pod (interno). Provjera se smatra uspješnom ako je kod završetka naredbe 0.

Primjer kako ovo funkcionira. Sljedeća definicija modula sadrži NodeJS aplikaciju koja na HTTP zahtjeve daje pogrešku 500. Kako bismo bili sigurni da se spremnik ponovno pokreće kada primi takvu pogrešku, koristimo parametar 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

Ovo se ne razlikuje od bilo koje druge definicije mahuna, ali mi dodajemo objekt .spec.containers.livenessProbe. Parametar httpGet prihvaća stazu na koju se šalje HTTP GET zahtjev (u našem primjeru to je /, ali u borbenim scenarijima može biti nešto slično /api/v1/status). Druga livenessProbe prihvaća parametar initialDelaySeconds, koji nalaže operaciji provjere da čeka određeni broj sekundi. Odgoda je potrebna jer spremniku treba vremena za pokretanje, a kada se ponovno pokrene, bit će nedostupan neko vrijeme.

Za primjenu ove postavke na klaster, upotrijebite:

kubectl apply -f pod.yaml

Nakon nekoliko sekundi, možete provjeriti sadržaj mahune pomoću sljedeće naredbe:

kubectl describe pods node500

Na kraju izlaza pronađite to je što.

Kao što možete vidjeti, livenessProbe je pokrenuo HTTP GET zahtjev, spremnik je generirao pogrešku 500 (za što je programiran), a kubelet ga je ponovno pokrenuo.

Ako se pitate kako je aplikacija NideJS programirana, evo app.js i Dockerfile koji su korišteni:

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

Važno je napomenuti ovo: livenessProbe će ponovno pokrenuti spremnik samo ako ne uspije. Ako ponovno pokretanje ne ispravi pogrešku koja sprječava rad spremnika, kubelet neće moći poduzeti radnje da ispravi problem.

spremnost Probe

readinessProbe radi slično kao livenessProbes (GET zahtjevi, TCP komunikacije i izvršavanje naredbi), osim za radnje rješavanja problema. Spremnik u kojem je otkriven kvar ne pokreće se ponovno, ali se izolira od dolaznog prometa. Zamislite da jedan od spremnika izvodi mnogo izračuna ili je pod velikim opterećenjem, što uzrokuje povećanje vremena odgovora. U slučaju livenessProbe, pokreće se provjera dostupnosti odgovora (putem parametra provjere timeoutSeconds), nakon čega kubelet ponovno pokreće spremnik. Kada se pokrene, spremnik počinje izvršavati zadatke koji zahtijevaju velike resurse i ponovno se pokreće. To može biti kritično za aplikacije kojima je potrebna brzina odziva. Na primjer, automobil dok je na cesti čeka odgovor poslužitelja, odgovor kasni - i automobil upada u nesreću.

Napišimo definiciju redinessProbe koja će postaviti vrijeme odgovora na GET zahtjev na najviše dvije sekunde, a aplikacija će odgovoriti na GET zahtjev nakon 5 sekundi. Datoteka pod.yaml trebala bi izgledati ovako:

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

Idemo implementirati pod s kubectl:

kubectl apply -f pod.yaml

Pričekajmo nekoliko sekundi i onda vidimo kako je ReadinessProbe radio:

kubectl describe pods nodedelayed

Na kraju ispisa možete vidjeti da su neki od događaja slični ovaj.

Kao što vidite, kubectl nije ponovno pokrenuo modul kada je vrijeme provjere premašilo 2 sekunde. Umjesto toga, poništio je zahtjev. Dolazna komunikacija se preusmjerava na druge, radne jedinice.

Imajte na umu da sada kada je pod rasterećen, kubectl ponovno usmjerava zahtjeve prema njemu: odgovori na GET zahtjeve više nisu odgođeni.

Za usporedbu, u nastavku je modificirana app.js datoteka:

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
Prije pojave aplikacija u oblaku, dnevnici su bili primarni način praćenja i provjere ispravnosti aplikacija. Međutim, nije bilo načina da se poduzmu bilo kakve korektivne mjere. Zapisi su i danas korisni; potrebno ih je prikupiti i poslati u sustav za prikupljanje zapisa za analizu hitnih situacija i donošenje odluka. [Sve se to moglo učiniti bez aplikacija u oblaku pomoću monita, na primjer, ali s k8s je postalo puno lakše :) – napomena urednika. ]

Danas se ispravci moraju raditi gotovo u stvarnom vremenu, pa aplikacije više ne moraju biti crne kutije. Ne, trebali bi prikazivati ​​krajnje točke koje sustavima za nadzor omogućuju postavljanje upita i prikupljanje vrijednih podataka o stanju procesa kako bi mogli trenutno odgovoriti ako je potrebno. To se naziva uzorak dizajna testa izvedbe, koji slijedi načelo visoke vidljivosti (HOP).

Kubernetes prema zadanim postavkama nudi 2 vrste provjera zdravlja: readinessProbe i livenessProbe. Oba koriste iste vrste provjera (HTTP GET zahtjevi, TCP komunikacije i izvršavanje naredbi). Razlikuju se po tome koje odluke donose kao odgovor na probleme u kapsulama. livenessProbe ponovno pokreće spremnik u nadi da se pogreška neće ponoviti, a readinessProbe izolira modul od dolaznog prometa dok se uzrok problema ne riješi.

Ispravan dizajn aplikacije trebao bi uključivati ​​obje vrste provjere i osigurati da prikupljaju dovoljno podataka, posebno kada se pojavi iznimka. Također bi trebao prikazati potrebne krajnje točke API-ja koje sustavu nadzora (Prometheus) pružaju važne zdravstvene metrike.

Izvor: www.habr.com