Një aspekt i rëndësishëm në funksionimin e sistemeve të shpërndara është trajtimi i defekteve. Kubernetes ndihmon në këtë, duke përdorur kontrollet që mbikëqyrin gjendjen e sistemit tuaj dhe riaktivizojnë shërbimet që kanë ndaluar së funksionuari. Megjithatë, Kubernetes mund të ndalë me forcë aplikacionet tuaja për të garantuar përgjithësinë e sistemit. Në këtë seri, do të shqyrtojmë se si mund ta ndihmojmë Kubernetes të kryejë punën e tij më efektivisht dhe të reduktojë kohën e papunësisë së aplikacioneve.
Para fillimit të aplikimit të kontejnerëve, shumica e aplikacioneve funksiononin në makina virtuale ose fizike. Nëse një aplikacion dështonte ose ngjitej, merrte shumë kohë për të ndaluar detyrën në ekzekutim dhe për të ngarkuar përsëri programin. Në rastin më të keq, dikush duhej të zgjidhte këtë problem manualisht gjatë natës, në një kohë të papërshtatshme. Nëse një detyrë e rëndësishme kryhej nga vetëm 1-2 makina punuese, një dështim i tillë ishte plotësisht i papranueshëm.
Prandaj, në vend të riaktivizimit manual, filluan të përdorim monitorimin në nivelin e proceseve për të riaktivizuar automatikisht aplikacionin në rast se ai përfundonte në mënyrë të papritur. Nëse programi dështonte, procesi i monitorimit kap kodin e daljes dhe riaktivizon serverin. Me shfaqjen e sistemeve si Kubernetes, ky lloj reagimi ndaj dështimeve të sistemit u integrua thjesht në infrastrukturë.
Kubernetes pĂ«rdor njĂ« cikĂ«l ngjarjesh "vĂ«zhgo â regjistro ndryshime â ndĂ«rmerr veprime" pĂ«r tĂ« siguruar qĂ« burimet tĂ« ruajnĂ« funksionalitetin gjatĂ« kalimit nga kontejnerĂ«t nĂ« nyjat e vetĂ«.
Kjo do të thotë se nuk keni më nevojë të nisni manualisht monitorimin e proceseve. Nëse një burim nuk kalon kontrollin e funksionalitetit, Kubernetes thjesht do t'i sigurojë atij një zëvendësim automatikisht. Sidoqoftë, Kubernetes bën shumë më tepër sesa të mbikëqyrë dështimet e aplikacioneve tuaja. Ai mund të krijojë më shumë kopje të aplikacionit për të punuar në disa makina, të përditësojë aplikacionin ose të ekzekutojë disa versione të ndryshme të aplikacionit tuaj në të njëjtën kohë.
Prandaj, ka shumë arsye për të cilat Kubernetes mund të ndalë punën e një kontejneri të shëndoshë. Për shembull, nëse po përditësoni shpërndarjen tuaj, Kubernetes do të ndalë ngadalë pod-et e vjetra, ndërkohë që aktivizon të rejat. Nëse çoni poshtë një nyjë, Kubernetes do të ndalë të gjitha pod-et në atë nyjë. Fundja, nëse një nyje i përfundon burimet, Kubernetes do të ndalë të gjithë pod-et për të liruar këto burime.
Prandaj, është shumë e rëndësishme që aplikacioni juaj të ndalojë punën me ndikim minimal në përdoruesin e fundit dhe me kohë minimal rikuperimi. Kjo do të thotë që para se të ndalet, ai duhet të ruajë të gjithë të dhënat që janë të nevojshme për t'u ruajtur, të mbyllë të gjitha lidhjet në rrjet, të përfundojë detyrat e mbetura dhe të përfundojë detyrat e tjera urgjente.
NĂ« praktikĂ«, kjo do tĂ« thotĂ« qĂ« aplikacioni juaj duhet tĂ« jetĂ« nĂ« gjendje tĂ« trajtojĂ« mesazhin SIGTERM â sinjalin e pĂ«rfundimit tĂ« procesit, i cili Ă«shtĂ« sinjali i paracaktuar pĂ«r utilitarin kill nĂ« sistemet operuese tĂ« familjes Unix. Pasi tĂ« marrĂ« kĂ«tĂ« mesazh, aplikacioni duhet tĂ« ndalet.
Pasi Kubernetes vendosi të përfundojë pod-in, ndodhin një sërë ngjarjesh. Le të shqyrtojmë secilin hap që merr Kubernetes kur ndalon funksionimin e një kontejneri ose pod-i.
TĂ« supozojmĂ« se duam tĂ« pĂ«rfundojmĂ« njĂ« nga pod-et. NĂ« kĂ«tĂ« moment, ai do tĂ« ndalojĂ« nga pranimi i trafikut tĂ« ri â kontejnerĂ«t qĂ« funksionojnĂ« nĂ« pod nuk do tĂ« preken, por i gjithĂ« trafiku i ri do tĂ« bllokohet.
Le tĂ« shqyrtojmĂ« hukun preStop â kjo Ă«shtĂ« njĂ« komandĂ« e veçantĂ« ose njĂ« kĂ«rkesĂ« HTTP qĂ« dĂ«rgohet kontejnerĂ«ve nĂ« pod. NĂ«se aplikacioni juaj ndalon pa probleme me marrjen e SIGTERM, mund tĂ« pĂ«rdorni preStop pĂ«r ta pĂ«rfunduar nĂ« mĂ«nyrĂ« tĂ« duhur.
Shumica e programeve kur marrin sinjalin SIGTERM e përfundojnë punën në mënyrë të duhur, por nëse përdorni kod të palës së tretë ose një sistem që nuk mund ta kontrolloni plotësisht, huku preStop shërben si një mënyrë e shkëlqyer për të thirrur një ndalim të qetë pa ndryshuar aplikacionin.
Pas ekzekutimit të këtij huku, Kubernetes do t'u dërgojë kontejnerëve në pod sinjalin SIGTERM, i cili do t'i informojë ata se së shpejti do të jenë të ndaluar. Pasi të marrë këtë sinjal, kodi juaj do të kalojë në procesin e ndalimit. Ky proces mund të përfshijë ndalimin e çdo lidhjeje afatgjatë, siç është lidhja me bazën e të dhënave ose rrjedha WebSocket, ruajtjen e gjendjes aktuale dhe aspekte të tjerë të ngjashme.
Edhe nëse përdorni preStop hook, është shumë e rëndësishme të kontrolloni se çfarë ndodh me aplikacionin tuaj kur i dërgoni sinjalin SIGTERM, si sillet ai në këtë rast, që ngjarjet ose ndryshimet në funksionimin e sistemit, të shkaktuara nga ndalimi i pod-it, mos të jenë befasuese për ju.
Në këtë moment, përpara se të merrni veprime të tjera, Kubernetes do të presë për kohën e specifikuar, e cila quhet terminationGracePeriodSecond, ose periudhë për ndalim korrekt kur merr sinjalin SIGTERM.
NĂ« mĂ«nyrĂ« tĂ« parazgjedhur, kjo periudhĂ« Ă«shtĂ« 30 sekonda. Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se ajo zgjat paralelisht me preStop hook dhe sinjalin SIGTERM. Kubernetes nuk do tĂ« presĂ« derisa tĂ« pĂ«rfundojĂ« preStop hook dhe SIGTERM â nĂ«se aplikacioni juaj pĂ«rfundon para se tĂ« pĂ«rfundojĂ« periudha TerminationGracePeriod, Kubernetes do tĂ« kalojĂ« menjĂ«herĂ« nĂ« hapin tjetĂ«r. Prandaj, sigurohuni qĂ« vlera e kĂ«saj periudhe nĂ« sekonda tĂ« jetĂ« tĂ« paktĂ«n sa koha e nevojshme pĂ«r njĂ« ndalim tĂ« saktĂ« tĂ« pod-it, dhe nĂ«se e tejkalon 30 sekonda, rritni periudhĂ«n nĂ« masĂ«n e duhur nĂ« YAML. NĂ« shembullin e dhĂ«nĂ« Ă«shtĂ« 60 sekonda.
Dhe pĂ«rfundimisht, hapi i fundit â nĂ«se kontejnerĂ«t ende vazhdojnĂ« tĂ« funksionojnĂ« pas skadimit tĂ« terminationGracePeriod, ata do tĂ« dĂ«rgojnĂ« sinjalin SIGKILL dhe do tĂ« fshihen pĂ«r forcĂ«. NĂ« kĂ«tĂ« moment, Kubernetes gjithashtu do tĂ« pastrojĂ« tĂ« gjithĂ« objektet e tjera tĂ« pod-it.
Kubernetes ndalon pod-et për shumë arsye, prandaj sigurohuni që në çdo rast aplikacioni juaj të përfundojë siç duhet, për të garantuar funksionimin e qëndrueshëm të shërbimit.
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
