Distribuiranim sustavima može biti teško upravljati jer imaju mnogo pokretnih, promjenjivih elemenata koji svi moraju ispravno raditi kako bi sustav funkcionirao. Ako neki od elemenata zakaže, sustav ga mora detektirati, zaobići i popraviti, a sve to mora biti učinjeno automatski. U ovoj seriji Kubernetes najboljih praksi naučit ćemo kako postaviti testove spremnosti i živosti za testiranje ispravnosti Kubernetes klastera.
Provjera stanja jednostavan je način da sustavu javite radi li vaša instanca aplikacije ili ne. Ako vaša instanca aplikacije ne radi, druge usluge joj ne bi trebale pristupati niti joj slati zahtjeve. Umjesto toga, zahtjev se mora poslati drugoj instanci aplikacije koja je već pokrenuta ili će biti pokrenuta kasnije. Osim toga, sustav bi trebao vratiti izgubljenu funkcionalnost vaše aplikacije.
Prema zadanim postavkama, Kubernetes će početi slati promet podu kada svi spremnici unutar podova budu pokrenuti i ponovno pokrenuti spremnike kada se sruše. Ovo zadano ponašanje sustava može biti dovoljno dobro za početak, ali možete poboljšati pouzdanost implementacije vašeg proizvoda korištenjem prilagođenih provjera ispravnosti.
Srećom, Kubernetes to čini prilično jednostavnim, tako da nema isprike za ignoriranje ovih provjera. Kubernetes pruža dvije vrste provjera stanja i važno je razumjeti razlike u načinu na koji se svaka od njih koristi.
Test spremnosti osmišljen je da kaže Kubernetesu da je vaša aplikacija spremna za rukovanje prometom. Prije nego što dopusti usluzi slanje prometa u pod, Kubernetes mora potvrditi da je provjera spremnosti uspješna. Ako test spremnosti ne uspije, Kubernetes će prestati slati promet u pod dok test ne prođe.
Liveness test govori Kubernetesu je li vaša aplikacija živa ili mrtva. U prvom slučaju, Kubernetes će ga ostaviti na miru, u drugom će izbrisati mrtvi pod i zamijeniti ga novim.
Zamislimo scenarij u kojem vašoj aplikaciji treba 1 minuta da se zagrije i pokrene. Vaša usluga neće početi raditi dok se aplikacija u potpunosti ne učita i pokrene, iako je tijek rada već započeo. Također ćete imati problema ako ovu implementaciju želite proširiti na više kopija, jer te kopije ne bi trebale primati promet dok ne budu u potpunosti spremne. Međutim, prema zadanim postavkama Kubernetes će početi slati promet čim se pokrenu procesi unutar spremnika.
Kada koristite test spremnosti, Kubernetes će pričekati dok se aplikacija u potpunosti ne pokrene prije nego što dopusti usluzi slanje prometa na novu kopiju.
Zamislimo drugi scenarij u kojem aplikacija visi dugo vremena, zaustavljajući servisiranje zahtjeva. Kako se proces nastavlja izvoditi, Kubernetes će prema zadanim postavkama pretpostaviti da je sve u redu i nastaviti slati zahtjeve grupi koja ne radi. Ali kada koristite Liveness, Kubernetes će otkriti da aplikacija više ne poslužuje zahtjeve i ponovno će pokrenuti mrtvi modul prema zadanim postavkama.
Pogledajmo kako se testiraju spremnost i održivost. Postoje tri metode testiranja - HTTP, Command i TCP. Za provjeru možete koristiti bilo koji od njih. Najčešći način testiranja korisnika je HTTP sonda.
Čak i ako vaša aplikacija nije HTTP poslužitelj, svejedno možete stvoriti lagani HTTP poslužitelj unutar svoje aplikacije za interakciju s Liveness testom. Nakon toga, Kubernetes će početi pingati pod, a ako je HTTP odgovor u rasponu od 200 ili 300 ms, to će značiti da je pod zdrav. U suprotnom, modul će biti označen kao "neispravan".
Za testove naredbe, Kubernetes pokreće naredbu unutar vašeg spremnika. Ako se naredba vrati s nultim izlaznim kodom, tada će spremnik biti označen kao ispravan, u suprotnom, po primitku broja statusa izlaza od 1 do 255, spremnik će biti označen kao "bolestan". Ova metoda testiranja korisna je ako ne možete ili ne želite pokrenuti HTTP poslužitelj, ali možete pokrenuti naredbu koja će provjeriti ispravnost vaše aplikacije.
Konačni mehanizam provjere je TCP test. Kubernetes će pokušati uspostaviti TCP vezu na navedenom priključku. Ako se to može učiniti, kontejner se smatra zdravim; ako ne, smatra se da nije održiv. Ova metoda može biti korisna ako koristite scenarij u kojem testiranje s HTTP zahtjevom ili izvršavanje naredbe ne funkcionira dobro. Na primjer, glavne usluge za provjeru pomoću TCP-a bile bi gRPC ili FTP.
Testovi se mogu konfigurirati na nekoliko načina s različitim parametrima. Možete odrediti koliko često se trebaju izvršavati, koji su pragovi uspjeha i neuspjeha i koliko dugo treba čekati odgovore. Za više informacija pogledajte dokumentaciju za testove spremnosti i živosti. Međutim, postoji jedna vrlo važna točka u postavljanju Liveness testa - početna postavka odgode testiranja initialDelaySeconds. Kao što sam spomenuo, neuspjeh ovog testa rezultirat će ponovnim pokretanjem modula. Stoga se morate pobrinuti da testiranje ne započne sve dok aplikacija nije spremna za rad, inače će početi ciklički ponovna pokretanja. Preporučujem korištenje vremena pokretanja P99 ili prosječnog vremena pokretanja aplikacije iz međuspremnika. Ne zaboravite prilagoditi ovu vrijednost kako vrijeme pokretanja vaše aplikacije postaje brže ili sporije.
Većina stručnjaka potvrdit će da su provjere stanja obavezne provjere za svaki distribuirani sustav, a Kubernetes nije iznimka. Korištenje provjera ispravnosti usluge osigurava pouzdan rad Kubernetesa bez problema i jednostavno je za korisnike.
Nastavak uskoro...
Neki oglasi 🙂
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com