Sistemet e shpërndara mund të jenë të vështira për t'u menaxhuar sepse ato kanë shumë elementë lëvizës, në ndryshim që të gjithë duhet të funksionojnë siç duhet që sistemi të funksionojë. Nëse një nga elementët dështon, sistemi duhet ta zbulojë, ta anashkalojë dhe ta rregullojë dhe e gjithë kjo duhet të bëhet automatikisht. Në këtë seri të praktikave më të mira të Kubernetes, ne do të mësojmë se si të konfigurojmë testet e gatishmërisë dhe të gjallërisë për të testuar shëndetin e një grupi Kubernetes.
Kontrolli shëndetësor është një mënyrë e thjeshtë për të njoftuar sistemin nëse shembulli i aplikacionit tuaj po funksionon apo jo. Nëse shembulli i aplikacionit tuaj nuk funksionon, atëherë shërbimet e tjera nuk duhet t'i qasen atij ose t'i dërgojnë kërkesa. Në vend të kësaj, kërkesa duhet të dërgohet në një shembull tjetër të aplikacionit që tashmë është duke u ekzekutuar ose që do të hapet më vonë. Përveç kësaj, sistemi duhet të rivendosë funksionalitetin e humbur të aplikacionit tuaj.
Si parazgjedhje, Kubernetes do të fillojë të dërgojë trafik në një pod kur të gjithë kontejnerët brenda pods janë duke u ekzekutuar dhe do të rindizojë kontejnerët kur ato rrëzohen. Kjo sjellje e parazgjedhur e sistemit mund të jetë mjaft e mirë për të filluar, por ju mund të përmirësoni besueshmërinë e vendosjes së produktit tuaj duke përdorur kontrolle të personalizuara të shëndetit.
Për fat të mirë, Kubernetes e bën këtë mjaft të lehtë për t'u bërë, kështu që nuk ka asnjë justifikim për të injoruar këto kontrolle. Kubernetes ofron dy lloje kontrollesh shëndetësore dhe është e rëndësishme të kuptohen ndryshimet në mënyrën se si përdoret secili.
Testi i gatishmërisë është krijuar për t'i treguar Kubernetes se aplikacioni juaj është gati për të trajtuar trafikun. Përpara se të lejojë një shërbim të dërgojë trafik në një pod, Kubernetes duhet të verifikojë që kontrolli i gatishmërisë është i suksesshëm. Nëse testi i gatishmërisë dështon, Kubernetes do të ndalojë dërgimin e trafikut në pod derisa testi të kalojë.
Testi Liveness i tregon Kubernetes nëse aplikacioni juaj është i gjallë apo i vdekur. Në rastin e parë, Kubernetes do ta lërë të qetë, në të dytën do të fshijë podin e vdekur dhe do ta zëvendësojë me një të ri.
Le të imagjinojmë një skenar ku aplikacioni juaj merr 1 minutë për t'u ngrohur dhe nisur. Shërbimi juaj nuk do të fillojë të funksionojë derisa aplikacioni të ngarkohet plotësisht dhe të funksionojë, megjithëse rrjedha e punës tashmë ka filluar. Do të keni gjithashtu probleme nëse dëshironi ta rritni këtë vendosje në kopje të shumta, sepse ato kopje nuk duhet të marrin trafik derisa të jenë plotësisht gati. Sidoqoftë, si parazgjedhje, Kubernetes do të fillojë të dërgojë trafik sapo të fillojnë proceset brenda kontejnerit.
Kur përdorni testin e gatishmërisë, Kubernetes do të presë derisa aplikacioni të funksionojë plotësisht përpara se të lejojë shërbimin të dërgojë trafik në kopjen e re.
Le të imagjinojmë një skenar tjetër në të cilin aplikacioni qëndron për një kohë të gjatë, duke ndaluar kërkesat e shërbimit. Ndërsa procesi vazhdon të funksionojë, si parazgjedhje Kubernetes do të supozojë se gjithçka është në rregull dhe do të vazhdojë të dërgojë kërkesa në podin që nuk funksionon. Por kur përdor Liveness, Kubernetes do të zbulojë se aplikacioni nuk po i shërben më kërkesave dhe do të rifillojë si parazgjedhje podin e vdekur.
Le të shohim se si testohen gatishmëria dhe qëndrueshmëria. Ekzistojnë tre metoda testimi - HTTP, Command dhe TCP. Ju mund të përdorni cilindo prej tyre për të kontrolluar. Mënyra më e zakonshme për të testuar një përdorues është një hetim HTTP.
Edhe nëse aplikacioni juaj nuk është një server HTTP, mund të krijoni një server HTTP të lehtë brenda aplikacionit tuaj për të bashkëvepruar me testin e Liveness. Pas kësaj, Kubernetes do të fillojë të tingëllojë në pod dhe nëse përgjigja HTTP është në intervalin 200 ose 300 ms, kjo do të tregojë se pod është i shëndetshëm. Përndryshe, moduli do të shënohet si "i pashëndetshëm".
Për testet e komandës, Kubernetes ekzekuton komandën brenda kontejnerit tuaj. Nëse komanda kthehet me një kod daljeje zero, atëherë kontejneri do të shënohet si i shëndetshëm, përndryshe, me marrjen e numrit të statusit të daljes nga 1 në 255, kontejneri do të shënohet si "i sëmurë". Kjo metodë testimi është e dobishme nëse nuk mundeni ose nuk dëshironi të ekzekutoni një server HTTP, por jeni në gjendje të ekzekutoni një komandë që do të kontrollojë shëndetin e aplikacionit tuaj.
Mekanizmi përfundimtar i verifikimit është testi TCP. Kubernetes do të përpiqet të krijojë një lidhje TCP në portin e specifikuar. Nëse kjo mund të bëhet, kontejneri konsiderohet i shëndetshëm, nëse jo, konsiderohet i papërshtatshëm. Kjo metodë mund të jetë e dobishme nëse jeni duke përdorur një skenar ku testimi me një kërkesë HTTP ose ekzekutimi i komandës nuk funksionon shumë mirë. Për shembull, shërbimet kryesore për verifikim duke përdorur TCP do të ishin 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ë pragjet e suksesit dhe dështimit dhe sa kohë të prisni për përgjigjet. Për më shumë informacion, shihni dokumentacionin për testet e gatishmërisë dhe gjallërisë. Sidoqoftë, ekziston një pikë shumë e rëndësishme në konfigurimin e testit të Liveness - vendosja fillestare e vonesës së testimit fillestarDelaySeconds. Siç e përmenda, dështimi i këtij testi do të rezultojë në rinisjen e modulit. Pra, duhet të siguroheni që testimi të mos fillojë derisa aplikacioni të jetë gati për t'u nisur, përndryshe ai do të fillojë të rifillojë me biçikletë. Unë rekomandoj përdorimin e kohës së fillimit të P99 ose kohës mesatare të nisjes së aplikacionit nga buferi. Mos harroni ta rregulloni këtë vlerë pasi koha e nisjes së aplikacionit tuaj bëhet më e shpejtë ose më e ngadaltë.
Shumica e ekspertëve do të konfirmojnë se Kontrollet Shëndetësore janë një kontroll i detyrueshëm për çdo sistem të shpërndarë dhe Kubernetes nuk bën përjashtim. Përdorimi i kontrolleve shëndetësore të shërbimit siguron funksionim të besueshëm dhe pa probleme të Kubernetes dhe është i lehtë për përdoruesit.
Vazhdon shume shpejt...
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më 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 dollarë! Lexoni rreth
Burimi: www.habr.com