Sistemet e shpërndara janë të vështira për t'u menaxhuar për shkak të numrit të madh të elementeve të ndryshueshme, të cilat të gjitha duhet të funksionojnë normalisht për të siguruar funksionalitetin e sistemit. Nëse një nga elementet dështon, sistemi duhet ta zbulojë, ta rrethojë dhe ta rregullojë automatikisht. Në këtë seri 'Praktikat më të Mira Kubernetes' do të mësojmë si të konfigurojmë testet Readiness dhe Liveness për të kontrolluar jetëgjatësinë e klasterit Kubernetes.
Kontrolli i shëndetit Health Check është një mënyrë e thjeshtë për t'i bërë sistemit të dijë nëse instanca e aplikacionit tuaj është në punë apo jo. Nëse instanca e aplikacionit tuaj nuk po punon, shërbime të tjera nuk duhet të lidhen me të ose t'i dërgojnë kërkesa. Në vend të kësaj, kërkesa duhet të dërgohet te një instancë tjetër të aplikacionit që tashmë është e mbajtur ose do të iniciohet më vonë. Për më tepër, sistemi duhet të rikthejë aplikacionin tuaj në gjendje pune.
Sipas parazgjedhjeve, Kubernetes do të fillojë të dërgojë trafik në pod kur të gjitha konteinerët brenda pod-eve të jenë nisur dhe të rinis konteinerët kur ata dështojnë. Fillimisht, ky sjellje i sistemit mund të jetë mjaft e mirë, megjithatë ju mund të rritni besueshmërinë e implementimit të produktit tuaj duke përdorur kontrollime të personalizuara për funksionimin.
Fatmirësisht, Kubernetes e bën këtë mjaft të thjeshtë, kështu që nuk ka justifikim për të injoruar këto kontrollime. Kubernetes ofron dy lloje testi Health Check, dhe është e rëndësishme të kuptohet dallimi në aplikimin e secilit prej tyre.
Testi i gatishmërisë Readiness është krijuar për të informuar Kubernetes mbi gatishmërinë e aplikacionit tuaj për të shërbyer trafik. Para se të lejohet shërbimi të dërgojë trafik në pod, Kubernetes duhet të sigurohet për suksesin e testit të gatishmërisë. Nëse testi Readiness dështon, Kubernetes do të ndalojë dërgimin e trafikut në pod derisa testimi të kalojë me sukses.
Testi i jetëgjatësisë Liveness i raporton Kubernetes nëse aplikacioni juaj është jeton apo jo. Në rastin e parë, Kubernetes do ta lërë atë në paqe, ndërsa në rastin e dytë do të fshijë pod-in e vdekur dhe do ta zëvendësojë atë me një të ri.
Le tĂ« imagjinojmĂ« njĂ« skenar ku aplikacionit tuaj i nevojiten 1 minutĂ« pĂ«r tĂ« u ângrohurâ dhe pĂ«r t'u nisur. ShĂ«rbimi juaj nuk do tĂ« fillojĂ« derisa aplikacioni tĂ« jetĂ« ngarkuar plotĂ«sisht dhe tĂ« jetĂ« nisur, megjithatĂ« procesi i punĂ«s ka filluar tashmĂ«. Po ashtu, do tĂ« hasni probleme nĂ«se dĂ«shironi tĂ« shkallĂ«zoni kĂ«tĂ« shpĂ«rndarje nĂ« disa kopje, pasi kĂ«to kopje nuk duhet tĂ« marrin trafik derisa tĂ« jenĂ« plotĂ«sisht tĂ« gatshme. Por, sipas parazgjedhjes, Kubernetes do tĂ« fillojĂ« dĂ«rgimin e trafikut sapo tĂ« fillojnĂ« proceset brenda kontejnerit.
Kur përdorni testin e gatishmërisë Readiness, Kubernetes do të presë derisa aplikacioni të jetë plotësisht i nisur dhe vetëm atëherë do të lejojë shërbimin të dërgojë trafik në një kopje të re.
Le të imagjinojmë një skenar tjetër, në të cilin aplikacioni ngec për një kohë të gjatë, duke ndaluar së shërbyeri kërkesat. Duke qenë se procesi vazhdon të ekzekutohet, sipas parazgjedhjes Kubernetes do të mendojë se gjithçka është në rregull dhe do të vazhdojë të dërgojë kërkesa në pod-in e papun. Por, me përdorimin e Liveness, Kubernetes do të zbulojë se aplikacioni nuk po shërben më kërkesat dhe sipas parazgjedhjes do ta rinisë pod-in e papun.
TĂ« shohim se me çfarĂ« testohet gatishmĂ«ria dhe jetĂ«sia. Ka tri mĂ«nyra pĂ«r testimin â HTTP, Command dhe TCP. PĂ«r verifikim mund tĂ« pĂ«rdorni cilĂ«ndo prej tyre. MĂ«nyra mĂ« e zakonshme e testit tĂ« pĂ«rdoruesit Ă«shtĂ« probe HTTP.
Edhe nĂ«se aplikacioni juaj nuk Ă«shtĂ« njĂ« shĂ«rbim HTTP, ju ende mund tĂ« krijoni njĂ« shĂ«rbim HTTP tĂ« lehtĂ« brenda aplikacionit tuaj pĂ«r t'u lidhur me testin Liveness. Pasi tĂ« bĂ«het kjo, Kubernetes do tĂ« fillojĂ« tĂ« pingojĂ« pod-in, dhe nĂ«se pĂ«rgjigja HTTP Ă«shtĂ« nĂ« intervalin 200 ose 300 ms, kjo do tĂ« tregojĂ« se pod-i Ă«shtĂ« âi shĂ«ndetshĂ«mâ. PĂ«rndryshe, moduli do tĂ« shkruhet si âi sĂ«murĂ«â.
PĂ«r testet me Command, Kubernetes ekzekuton njĂ« komandĂ« brenda kontejnerit tuaj. NĂ«se komanda kthehet me njĂ« kod daljeje zero, atĂ«herĂ« kontejneri do tĂ« karakterizohet si i shĂ«ndetshĂ«m, pĂ«rndryshe, nĂ«se merr njĂ« numĂ«r tĂ« statusit tĂ« daljes nga 1 nĂ« 255, kontejneri do tĂ« etiketohen si âi sĂ«murĂ«â. Kjo mĂ«nyrĂ« testimi Ă«shtĂ« e dobishme, nĂ«se nuk mund tĂ« ose nuk dĂ«shironi tĂ« ekzekutoni njĂ« shĂ«rbim HTTP, por jeni nĂ« gjendje tĂ« ekzekutoni njĂ« komandĂ« qĂ« do tĂ« kontrollojĂ« âshĂ«ndetinâ e aplikacionit tuaj.
Mekanizmi i fundit i kontrollit është testi TCP. Kubernetes do të përpiqet të vendosë një lidhje TCP në portin e caktuar. Nëse arrin ta bëjë këtë, kontejneri do të konsiderohet të jetë i shëndetshëm, përndryshe do të jetë i paefektshëm. Ky metodë mund të jetë e dobishme nëse po përdorni një skenar ku testimi përmes një kërkesë HTTP ose ekzekutimi i një komande nuk funksionon shumë mirë. Për shembull, shërbimet kryesore për verifikimin me TCP do të jenë gRPC ose FTP.
Testet mund tĂ« konfigurohen nĂ« disa mĂ«nyra me parametra tĂ« ndryshĂ«m. Ju mund tĂ« specifikoni se sa shpesh duhet tĂ« ekzekutohen, cilat janĂ« vlerat kufitare pĂ«r suksesin dhe dĂ«shtimin, si dhe sa gjatĂ« duhet tĂ« pritet pĂ«rgjigjen. MĂ« shumĂ« informacion Ă«shtĂ« nĂ« dokumentacionin e testeve Readiness dhe Liveness. MegjithatĂ«, ka njĂ« pikĂ« shumĂ« tĂ« rĂ«ndĂ«sishme nĂ« konfigurimin e testit Liveness â vendosja fillestare e vonesĂ«s sĂ« testimit initialDelaySeconds. Siç e pĂ«rmenda, dĂ«shtimi nĂ« kĂ«tĂ« test do tĂ« çojĂ« nĂ« rinisjen e modulit. Prandaj, duhet tĂ« siguroni qĂ« testimi tĂ« mos fillojĂ« derisa aplikacioni tĂ« jetĂ« gati pĂ«r tu drejtuar, pĂ«rndryshe do tĂ« rifillojĂ« ciklikisht. UnĂ« rekomandoj tĂ« pĂ«rdorni kohĂ«n e startup-it P99 ose mesataren e kohĂ«s sĂ« startit tĂ« aplikacionit nga bufferi. Mos harroni tĂ« rregulloni kĂ«tĂ« vlerĂ« ndĂ«rkohĂ« qĂ« koha e startit tĂ« aplikacionit tuaj bĂ«het gjithnjĂ« e mĂ« e shpejtĂ« ose e ngadalshĂ«m.
Shumica e specialistëve do të konfirmojnë se kontrollet e shëndetit janë një verifikim i detyrueshëm për çdo sistem të shpërndarë, dhe Kubernetes nuk është një përjashtim. Përdorimi i kontrolleve të 'shëndetit' të shërbimeve siguron një funksionim të besueshëm dhe të pandërprerë të Kubernetes dhe nuk përbën asnjë shqetësim për përdoruesit.
Do të vazhdojë shumë shpejt...
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
