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
