Sistemat e shpërndara mund të jenë të vështira për t'u menaxhuar për shkak të numrit të madh të elementeve të lëvizshme që i kanë, dhe të gjithë duhet të funksionojnë siç duhet për të siguruar funksionalitetin e sistemit. Nëse një nga elementët dështon, sistemi duhet ta zbulojë, ta anashkalojë dhe ta riparojë atë, dhe gjithçka duhet të bëhet automatikisht. Në këtë seri 'Kubernetes Best Practices', do të mësojmë se si të konfigurojmë testet Readiness dhe Liveness për të verifikuar 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 një instancë e aplikacionit tuaj është në funksionim apo jo. Nëse një instancë e aplikacionit tuaj nuk po funksionon, shërbimet e tjera nuk duhet të lidhen me të ose t'i dërgojnë ajo kërkesa. Në vend të kësaj, kërkesa duhet të dërgohet te një instancë tjetër aplikacioni që është tashmë aktive ose do të aktivizohet më vonë. Gjithashtu, sistemi duhet të rikthejë aplikacionit tuaj funksionalitetin e humbur.
Në mënyrë standarde, Kubernetes do të fillojë të dërgojë trafik në pod kur të gjitha kontejnerët brenda pod-eve të jenë aktivizuar, dhe do të rinovojë kontejnerët kur ata dështojnë. Në fillim, kjo sjellje e sistemit në mënyrë default mund të jetë mjaft e mirë, megjithatë mund të rritni besueshmërinë e implementimit të produktit tuaj duke përdorur testet e personalizuara të shëndetit.
Fatmirësisht, Kubernetes lejon që kjo të bëhet mjaft lehtë, prandaj nuk ka asnjë justifikim për ta injoruar këtë kontroll. Kubernetes ofron dy lloje testesh Health Check, dhe është e rëndësishme të kuptohet dallimi në përdorimin e secilit prej tyre.
Testi i gatishmërisë Readiness është i destinuar për të informuar Kubernetes në lidhje me gatishmërinë e aplikacionit tuaj për të shërbyer trafik. Para se të lejojë shërbimin 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 testi të kalojë me sukses.
Testi i gjallërisë Liveness informon Kubernetes nëse aplikacioni juaj është i gjallë apo i vdekur. Në rastin e parë, Kubernetes do ta lë atë në paqe, në rastin e dytë do të heqë pod-in e vdekur dhe do ta zëvendësojë me një të ri.
Le të paraqesim një skenar ku aplikacionit tuaj i duhen 1 minutë për 'ngrohje' dhe aktivizim. Shërbimi juaj nuk do të fillojë të funksionojë deri sa aplikacioni të jetë ngarkuar dhe aktivizuar plotësisht, megjithatë procesi i punës ka filluar tashmë. Gjithashtu, do të hasni në probleme nëse dëshironi të shkallëzoni këtë implementim në disa kopje, pasi këto kopje nuk duhet të marrin trafik derisa të jenë plotësisht të gatshme. Megjithatë, Kubernetes do të fillojë dërgimin e trafikut menjëherë pas fillimit të proceseve brenda kontejnerit si standard.
Duke përdorur testin e gatishmërisë Readiness, Kubernetes do të presë deri sa aplikacioni të jetë plotësisht i aktivizuar dhe vetëm pastaj do t'i lejojë shërbimit të dërgojë trafik në kopjen e re.
Le të paraqesim një skenar tjetër, ku aplikacioni ngec për një kohë të gjatë dhe ndalon së shërbyeri kërkesat. Ndërsa procesi vazhdon të ekzekutohet, në mënyrë standarde Kubernetes do ta mendojë që gjithçka është në rregull dhe do të vazhdojë të dërgojë kërkesa në pod-in që nuk funksionon. Por, me përdorimin e Liveness, Kubernetes do të zbulojë se aplikacioni nuk po shërben kërkesa më dhe për standard do të rinovojë pod-in e papërshtatshëm.
Le të shohim se si testohet gatishmëria dhe gjallëria. Ekzistojnë tre mënyra të testimit – HTTP, Command dhe TCP. Për verifikim, ju mund të përdorni cilëndo prej tyre. Mënyra më e zakonshme e testit të personalizuar është HTTP probe.
Edhe nëse aplikacioni juaj nuk është një server HTTP, ju mund të krijoni një server HTTP të lehtë brenda aplikacionit tuaj për t'u lidhur me testin Liveness. Pas kësaj, Kubernetes do të fillojë të pingojë pod-in, dhe nëse përgjigja HTTP është brenda intervalit 200 ose 300 ms, kjo do të nënkuptojë që pod-i është 'në formë të mirë'. Ndryshe, moduli do të shënohet si 'i papërshtatshëm'.
Për testet me Command, Kubernetes ekzekuton një komandë brenda kontejnerit tuaj. Nëse komanda kthehet me një kod dalës zero, atëherë kontejneri do të shënohet si i shëndetshëm, në përgjithësi, kur merr ndonjë numër dalës nga 1 deri në 255, kontejneri do të shënohet si 'i sëmurë'. Ky mënyrë testimi është e dobishme nëse nuk mund të ekzekutoni ose nuk dëshironi të aktivizoni një server HTTP, por jeni në gjendje të ekzekutoni një komandë që do të verifikojë 'shëndetin' e aplikacionit tuaj.
Mekanizmi i fundit i kontrollit është testi TCP. Kubernetes do të përpiqet të krijojë një lidhje TCP në portin e caktuar. Nëse arrin ta bëjë këtë, kontejneri konsiderohet i shëndetshëm, nëse jo – i pavendosur. Ky metodë mund të jetë e dobishme nëse jeni duke përdorur një skenar ku testimi me kërkesë HTTP ose ekzekutimi i komandave funksionon jo shumë mirë. Për shembull, shërbimet kryesore për testim me TCP do të jenë gRPC ose FTP.
Testet mund të konfigurohen në disa mënyra me parametra të ndryshëm. Mund të përcaktoni sa shpesh duhet të kryhen, cilat janë vlerat kufitare për sukses dhe dështim, sa gjatë të prisni për përgjigje. Informacione më të detajuara janë përshkruar në dokumentacionin për testet Readiness dhe Liveness. Megjithatë, ka një pikë shumë të rëndësishme në konfigurimin e testit Liveness – vonesën fillestare të testit initialDelaySeconds. Siç përmenda, dështimi i këtij testi do të çojë në rilidhjen e modulit. Prandaj, duhet të siguroheni që testimi të mos fillojë derisa aplikacioni të jetë gati për të punuar, përndryshe do të fillojë të rilidhet në cikle. Unë rekomandoj të përdorni kohën e nisjes P99 ose mesataren e kohës së nisjes së aplikacionit nga bufri. Mos harroni të rregulloni këtë vlerë ndërsa koha e nisjes së aplikacionit tuaj bëhet gjithnjë e më e shpejtë ose më e ngadalshme.
Shumica e specialistëve do të konfirmojnë se Kontrollet e Shëndetit janë një kontroll i domosdoshëm për çdo sistem të shpërndarë, dhe Kubernetes nuk është përjashtim. Përdorimi i kontrollit të "shëndetit" të shërbimeve siguron funksionimin e besueshëm dhe pa ndalime të Kubernetes dhe nuk përbën asnjë shqetësim për përdoruesit.
Vazhdimi do të vijë shumë shpejt…
Pak reklamë 🙂
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish më i lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
