Distribuiranim sistemima može biti teško upravljati jer imaju mnogo pokretnih, promjenjivih elemenata koji su svi potrebni da bi ispravno funkcionirali kako bi sistem funkcionirao. Ako jedan od elemenata pokvari, sistem ga mora otkriti, zaobići i popraviti, a sve to mora biti urađeno automatski. U ovoj seriji Kubernetes najboljih praksi naučit ćemo kako postaviti testove spremnosti i živosti za testiranje zdravlja Kubernetes klastera.
Provjera zdravlja je jednostavan način da obavijestite sistem da li je instanca vaše aplikacije pokrenuta ili ne. Ako je vaša instanca aplikacije nedostupna, 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, sistem bi trebao vratiti izgubljenu funkcionalnost vaše aplikacije.
Podrazumevano, Kubernetes će početi slati promet u pod kada su svi kontejneri unutar podova pokrenuti i ponovo pokrenuti kontejnere kada se sruše. Ovo zadano ponašanje sistema može biti dovoljno dobro za početak, ali možete poboljšati pouzdanost implementacije vašeg proizvoda korištenjem prilagođenih provjera ispravnosti.
Na sreću, Kubernetes to čini prilično lakim za izvođenje, tako da nema izgovora za ignorisanje ovih provjera. Kubernetes pruža dvije vrste provjera zdravlja i važno je razumjeti razlike u načinu na koji se svaki koristi.
Test spremnosti je dizajniran da kaže Kubernetesu da je vaša aplikacija spremna za upravljanje prometom. Prije nego što dozvoli servisu da šalje promet na pod, Kubernetes mora provjeriti da li 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 da li je 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 scenario u kojem vašoj aplikaciji treba 1 minut 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 tok posla već započeo. Također ćete imati problema ako želite da proširite ovu implementaciju na više kopija, jer te kopije ne bi trebale primati promet dok nisu u potpunosti spremne. Međutim, po defaultu, Kubernetes će početi slati promet čim počnu procesi unutar kontejnera.
Kada koristite test spremnosti, Kubernetes će čekati dok se aplikacija u potpunosti ne pokrene prije nego što dozvoli servisu da pošalje promet na novu kopiju.
Zamislimo još jedan scenario u kojem aplikacija dugo visi, zaustavljajući servisiranje zahtjeva. Kako se proces nastavlja, Kubernetes će po defaultu pretpostaviti da je sve u redu i nastaviti slati zahtjeve nefunkcionalnom pod. Ali kada se koristi Liveness, Kubernetes će otkriti da aplikacija više ne opslužuje zahtjeve i po defaultu će ponovo pokrenuti mrtvi pod.
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 server, i dalje možete kreirati lagani HTTP server unutar svoje aplikacije za interakciju sa Liveness testom. Nakon toga, Kubernetes će početi pingovati pod, a ako je HTTP odgovor u rasponu od 200 ili 300 ms, to će ukazati da je pod zdrav. U suprotnom, modul će biti označen kao "nezdrav".
Za komandne testove, Kubernetes pokreće naredbu unutar vašeg kontejnera. Ako se komanda vrati sa nultim izlaznim kodom, tada će kontejner biti označen kao zdrav, u suprotnom, po prijemu izlaznog statusnog broja od 1 do 255, kontejner će biti označen kao "bolestan". Ova metoda testiranja je korisna ako ne možete ili ne želite pokrenuti HTTP server, ali možete pokrenuti naredbu koja će provjeriti zdravlje vaše aplikacije.
Konačni mehanizam verifikacije je TCP test. Kubernetes će pokušati uspostaviti TCP vezu na navedenom portu. Ako se to može učiniti, kontejner se smatra zdravim, a ako nije, smatra se neodrživim. Ova metoda može biti korisna ako koristite scenario u kojem testiranje s HTTP zahtjevom ili izvršavanjem naredbe ne funkcionira baš dobro. Na primjer, glavni servisi za verifikaciju koristeći TCP bi bili gRPC ili FTP.
Testovi se mogu konfigurirati na nekoliko načina s različitim parametrima. Možete odrediti koliko često treba da se izvršavaju, koji su pragovi uspjeha i neuspjeha i koliko dugo treba čekati na odgovore. Za više informacija pogledajte dokumentaciju za testove spremnosti i izdržljivosti. Međutim, postoji jedna vrlo važna tačka u postavljanju testa Liveness - početna postavka kašnjenja testiranja initialDelaySeconds. Kao što sam spomenuo, neuspjeh ovog testa će rezultirati ponovnim pokretanjem modula. Dakle, morate biti sigurni da testiranje ne počne sve dok aplikacija ne bude spremna za rad, u suprotnom će započeti ciklus kroz ponovno pokretanje. Preporučujem korištenje vremena pokretanja P99 ili prosječnog vremena pokretanja aplikacije iz bafera. Ne zaboravite prilagoditi ovu vrijednost kako vrijeme pokretanja vaše aplikacije bude brže ili sporije.
Većina stručnjaka će potvrditi da su provjere zdravlja obavezna provjera za svaki distribuirani sistem, a Kubernetes nije izuzetak. Korištenje provjere ispravnosti usluge osigurava pouzdan rad Kubernetesa bez problema i korisnicima je jednostavan.
Nastavak vrlo brzo...
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com