Një nga momentet kyçe në punën e sistemeve të shpërndara është trajtimi i defekteve. Kubernetes ndihmon në këtë drejtim duke përdorur kontrollues që monitorojnë gjendjen e sistemit tuaj dhe rindezin shërbimet që kanë ndaluar së punuari. Megjithatë, Kubernetes mund të ndalë me forcë funksionimin e aplikacioneve tuaja për të siguruar qëndrueshmërinë e përgjithshme të 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 ndërprerjes së aplikacioneve.
Para fillimit të përdorimit të kontejnerëve, shumica e aplikacioneve punonin në makina virtuale ose fizike. Nëse një aplikacion dështonte ose ngrinte, merrte shumë kohë për të hequr detyrën e ekzekutimit dhe për ta ngarkuar përsëri programin. Në rastin më të keq, dikush duhej ta zgjidhte këtë problem manualisht gjatë natës, në orët më të papërshtatshme. Nëse një detyrë e rëndësishme ekzekutoheshin nga vetëm 1-2 makina të punës, një dështim i tillë ishte krejtësisht i papranueshëm.
Prandaj, në vend të rindezjes manuale, filluan të përdorin monitorimin në nivelin e proceseve për të rindezur automatikisht aplikacionin në rast të përfundimit të tij në mënyrë të papritur. Nëse programi dështonte, procesi i monitorimit kap kodin e daljes dhe rindez serverin. Me shfaqjen e sistemeve si Kubernetes, ky lloj reagimi ndaj dështimeve u integrua thjesht në infrastrukturë.
Kubernetes përdor ciklin e ngjarjeve "monitorim - regjistrimi i ndryshimeve - veprimi" për të siguruar që burimet të ruajnë funksionalitetin e tyre ndërsa kalojnë nga kontejnerët në nodet përkatëse.
Kjo do të thotë se nuk keni më nevojë të nisni manualisht monitorimin e proceseve. Nëse një burim dështon shkak për kontrollin e funksionalitetit, Kubernetes thjesht do t'i ofrojë automatikisht një zëvendësim. Në të njëjtën kohë, Kubernetes bën shumë më tepër se sa thjesht të monitorojë 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ë njëkohësisht disa versione të aplikacionit tuaj.
Prandaj, ka shumë arsye pse Kubernetes mund të pezullonte një kontejner të shëndoshë. Për shembull, nëse po e azhurnoni shpërndarjen tuaj, Kubernetes do të ndalë ngadalë pod-et e vjetra, ndërkohë që do të nisë ato të reja. Nëse e çmoni një nod, Kubernetes do të ndalë të gjitha pod-et në atë nod. Për më tepër, nëse një nod përfundon burimet, Kubernetes do të ndalë të gjitha pod-et për të liruar këto burime.
Prandaj, është shumë e rëndësishme që aplikacioni juaj të ndalojë punën me një ndikim minimal te përdoruesi përfundimtar dhe me një kohë rikuperimi minimale. Kjo do të thotë se para se të ndalej, duhet të ruajë të gjitha të dhënat që duhen ruajtur, të mbyllë të gjitha lidhjet rrjetërore, të përfundojë punët e mbetura dhe të bëjë detyrat e tjera urgjente.
NĂ« praktikĂ«, kjo do tĂ« thotĂ« se aplikacioni juaj duhet tĂ« jetĂ« nĂ« gjendje tĂ« pĂ«rballojĂ« mesazhin SIGTERM â sinjali pĂ«r ndalimin e procesit, i cili Ă«shtĂ« sinjali i paracaktuar pĂ«r utilitarin kill nĂ« sistemet operativ tĂ« familjes Unix. Pasi tĂ« marrĂ« kĂ«tĂ« mesazh, aplikacioni duhet tĂ« ndalojĂ«.
Pasi Kubernetes vendosi të përfundojë një pod, ndodhin një sërë ngjarjesh. Le të shohim çdo hap që merr Kubernetes gjatë ndalimit të punës së një kontejneri apo pod-i.
Supozoni se dĂ«shirojmĂ« tĂ« pĂ«rfundojmĂ« njĂ« nga pod-et. NĂ« kĂ«tĂ« moment, ai do tĂ« ndalojĂ« tĂ« marrĂ« trafikun e ri â kontejnerĂ«t qĂ« punojnĂ« brenda pod-it nuk do tĂ« preken, por tĂ« gjithĂ« trafiku i ri do tĂ« bllokohet.
Le tĂ« shohim mĂ«nyrĂ«n preStop â kjo Ă«shtĂ« njĂ« komandĂ« e veçantĂ« ose njĂ« kĂ«rkesĂ« HTTP qĂ« dĂ«rgohet kontejnerĂ«ve nĂ« pod. NĂ«se aplikacioni juaj nuk ndalon siç duhet kur merr SIGTERM, mund tĂ« pĂ«rdorni preStop pĂ«r tĂ« ndaluar nĂ« mĂ«nyrĂ« tĂ« saktĂ«.
Shumica e programeve, kur marrin sinjalin SIGTERM, ndalojnë punën e tyre në mënyrë të duhur, por nëse po përdorni kod të jashtëm ose një sistem që nuk mund ta kontrolloni plotësisht, hubi preStop shërben si një mënyrë e shkëlqyer për të thirrur një ndalim elegant pa ndryshuar aplikacionin.
Pas ekzekutimit të këtij hook, Kubernetes do të dërgojë sinjalin SIGTERM për enët në pod, i cili do t'u tregojë atyre se do të fikën së shpejti. Pas marrjes së këtij sinjali, kodi juaj do të kalojë në procesin e fikjes. Ky proces mund të përfshijë ndalimin e çdo lidhjeje afatgjatë, siç është lidhja me bazën e të dhënave ose streaming WebSocket, ruajtjen e gjendjes aktuale dhe të ngjashme.
Edhe nëse po përdorni hook-un preStop, është shumë e rëndësishme të verifikoni se çfarë ndodh me aplikacionin tuaj kur dërgoni sinjalin SIGTERM, si e menaxhon ai këtë, në mënyrë që ngjarjet ose ndryshimet në punën e sistemit, të shkaktuara nga fikja e pod-it, mos të jenë një befasi për ju.
Në këtë moment, përpara se të ndërmerrni veprime të mëtejshme, Kubernetes do të presë për periudhën e specifikuar të kohës, e cila quhet terminationGracePeriodSecond, ose periudha për fikjen e duhur pas marrjes së sinjalit SIGTERM.
PĂ«r default, kjo periudhĂ« Ă«shtĂ« 30 sekonda. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se ajo zgjat paralelisht me hook-un preStop dhe sinjalin SIGTERM. Kubernetes nuk do tĂ« presĂ« derisa tĂ« pĂ«rfundojĂ« preStop hook dhe SIGTERM - nĂ«se aplikacioni juaj shkĂ«putet 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Ă« e paktĂ«n aq sa koha e nevojshme pĂ«r fikjen e duhur tĂ« pod-it, dhe nĂ«se ajo e tejkalon 30 sekonda, rritni periudhĂ«n nĂ« madhĂ«sinĂ« e nevojshme nĂ« YAML. NĂ« shembullin e dhĂ«nĂ«, ajo Ă«shtĂ« 60 sekonda.
Dhe nĂ« fund, hapi i fundit â nĂ«se kontenierĂ«t ende vazhdojnĂ« tĂ« punojnĂ« pas skadimit tĂ« terminationGracePeriod, ata do tĂ« dĂ«rgojnĂ« sinjalin SIGKILL dhe do tĂ« fiken me forcĂ«. NĂ« kĂ«tĂ« moment, Kubernetes gjithashtu do tĂ« pastrojĂ« tĂ« gjitha objektet e tjera tĂ« pod-it.
Kubernetes fik pod-et për shumë arsye, prandaj sigurohuni që aplikacioni juaj të mbyllet siç duhet në çdo rast, për të garantuar stabilitetin e shërbimit.
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
