Upravljanje distribuiranim sustavima može biti izazovno zbog brojnih promjenjivih elemenata, koji moraju raditi ispravno kako bi sustav bio funkcionalan. Ako jedan od elemenata prestane raditi, sustav ga mora otkriti, zaobići i ispraviti, a sve to treba raditi automatski. U ovoj seriji «Kubernetes Best Practices» saznat ćemo kako postaviti Readiness i Liveness testove za provjeru održivosti Kubernetes klastera.
Health Check je jednostavan način da sustav sazna radi li instanca vaše aplikacije ili ne. Ako instanca vaše aplikacije ne radi, druge usluge ne bi trebale slati zahtjeve ili se povezivati s njom. Umjesto toga, zahtjev bi trebao biti upućen drugoj instanci aplikacije koja je već pokrenuta ili će biti pokrenuta kasnije. Osim toga, sustav bi trebao vratiti vašu aplikaciju u funkcionalno stanje.
Prema zadanim postavkama, Kubernetes će početi slati promet u pod kada su svi kontejneri unutar poda pokrenuti, a ponovno će pokrenuti kontejnere kada se ruše. Na početku, takvo ponašanje sustava može biti sasvim zadovoljavajuće, no možete poboljšati pouzdanost implementacije svog proizvoda koristeći prilagođene provjere zdravlja.
Srećom, Kubernetes omogućuje da to postignete prilično jednostavno, pa nema opravdanja za ignoriranje takvih provjera. Kubernetes nudi dvije vrste Health Check testova, a važno je razumjeti razlike u primjeni svakog od njih.
Readiness test je osmišljen kako bi obavijestio Kubernetes da je vaša aplikacija spremna za obradu prometa. Prije nego što dopusti servisu da šalje promet u pod, Kubernetes mora osigurati uspješnost provjere spremnosti. Ako test Readiness ne prođe, Kubernetes će prestati slati promet u pod sve dok testiranje ne bude uspješno.
Liveness test obavještava Kubernetes je li vaša aplikacija živa ili mrtva. U prvom slučaju, Kubernetes će je ignorirati, dok će u drugom slučaju ukloniti mrtvi pod i zamijeniti ga novim.
Zamislite scenarij u kojem vašem aplikaciji treba 1 minuta da se "zagrije" i pokrene. Vaša usluga neće početi funkcionirati sve dok aplikacija potpuno ne završi učitavanje i ne pokrene se, iako je radni proces već započeo. Također ćete imati problema ako želite povećati broj kopija ove implementacije jer te kopije ne bi trebale primati promet dok nisu potpuno spremne. No, po defaultu, Kubernetes će početi slati promet odmah nakon pokretanja procesa unutar kontejnera.
Kada koristite test spremnosti Readiness, Kubernetes će čekati da se aplikacija potpuno pokrene i tek tada će dopustiti usluzi da šalje promet na novu kopiju.
Zamislite drugi scenarij u kojem aplikacija duže vrijeme ne reagira na zahtjeve. Budući da proces nastavlja djelovati, po defaultu će Kubernetes smatrati da je sve u redu i nastaviti slati zahtjeve na neispravan pod. Međutim, korištenjem Liveness, Kubernetes će otkriti da aplikacija više ne obrađuje zahtjeve i po defaultu će ponovno pokrenuti neispravan pod.
Pogledajmo kako se testira spremnost i vitalnost. Postoje tri načina testiranja — HTTP, Command i TCP. Možete koristiti bilo koji od njih za provjeru. Najčešći način korisničkog testiranja je HTTP probe.
Čak i ako vaša aplikacija nije HTTP poslužitelj, i dalje možete stvoriti lagani HTTP poslužitelj unutar vaše aplikacije za interakciju s testom Liveness. Nakon toga, Kubernetes će početi pingati pod, a ako HTTP odgovor bude unutar raspona od 200 ili 300 ms, to će značiti da je pod "zdrav". U suprotnom, modul će biti označen kao "bolestan".
Za testove koristeći Command, Kubernetes izvršava komandu unutar vašeg kontejnera. Ako se komanda vrati s nulom kao exit kod, kontejner će biti označen kao zdrav, u suprotnom, ako dobije status izlaza od 1 do 255, kontejner će biti označen kao "bolestan". Ova metoda testiranja je korisna ako ne možete ili ne želite pokretati HTTP poslužitelj, ali možete pokrenuti komandu koja će provjeriti "zdravlje" vaše aplikacije.
Posljednji mehanizam provjere je TCP test. Kubernetes će pokušati uspostaviti TCP vezu na navedenoj portu. Ako to uspije, kontejner se smatra zdravim, u suprotnom neupotrebljivim. Ova metoda može biti korisna ako koristite scenarij u kojem provjera putem HTTP zahtjeva ili izvršavanje komande ne radi dobro. Na primjer, glavni servisi za provjeru putem TCP-a bit će gRPC ili FTP.
Testove možete postaviti na nekoliko načina s različitim parametrima. Možete odrediti koliko često se trebaju izvoditi, koji su pragovi uspjeha i neuspjeha, koliko dugo čekati na odgovore. Detaljnije informacije navedene su u dokumentaciji za Readiness i Liveness testove. Međutim, postoji jedan vrlo važan aspekt u postavljanju Liveness testa – početna postavka kašnjenja testa initialDelaySeconds. Kao što sam spomenuo, neuspješno izvršenje ovog testa rezultirat će ponovnim pokretanjem modula. Stoga trebate osigurati da testiranje ne započne dok aplikacija ne bude spremna za rad, inače će se početi ciklički ponovo pokretati. Preporučujem korištenje P99 vremena pokretanja ili prosječnog vremena pokretanja aplikacije iz bafera. Ne zaboravite prilagoditi tu vrijednost dok vrijeme pokretanja vaše aplikacije postaje sve brže ili sporije.
Većina stručnjaka će potvrditi da su Health Check obavezna provjera za svaki distribuirani sustav, a Kubernetes nije iznimka. Korištenje provjere 'zdravlja' servisa osigurava pouzdan i besprijekoran rad Kubernetesa i ne predstavlja nikakvu poteškoću za korisnike.
Nastavak slijedi vrlo brzo...
Malo reklame 🙂
Hvala što ostajete s nama. Sviđa li vam se naše članke? Želite li vidjeti više zanimljivih materijala? Podržite nas narudžbom ili preporučite prijateljima, , jedinstveni analog entry-level servera koji smo razvili za vas: (dostupne opcije s RAID1 i RAID10, do 24 jezgre i do 40GB DDR4).
Dell R730xd je 2 puta jeftiniji u data centaru Equinix Tier IV u Amsterdamu? Samo kod nas u Nizozemskoj! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Pročitajte o tome
Izvor: habr.com
