Një pikë e rëndësishme në funksionimin e sistemeve të shpërndara është trajtimi i dështimit. Kubernetes ndihmon me këtë duke përdorur kontrollues që monitorojnë shëndetin e sistemit tuaj dhe rinisin shërbimet që kanë ndaluar së funksionuari. Sidoqoftë, Kubernetes mund të ndalojë me forcë aplikacionet tuaja për të siguruar shëndetin e përgjithshëm të sistemit. Në këtë seri, ne do të shikojmë se si mund ta ndihmoni Kubernetes të bëjë punën e tij në mënyrë më efikase dhe të zvogëlojë kohën e ndërprerjes së aplikacionit.
Përpara kontejnerëve, shumica e aplikacioneve funksiononin në makina virtuale ose fizike. Nëse aplikacioni u rrëzua ose ngriu, u desh një kohë e gjatë për të anuluar detyrën në vazhdim dhe për të ringarkuar programin. Në rastin më të keq, dikush duhej ta zgjidhte këtë problem me dorë gjatë natës, në orët më të papërshtatshme. Nëse vetëm 1-2 makina pune kryenin një detyrë të rëndësishme, një ndërprerje e tillë ishte plotësisht e papranueshme.
Prandaj, në vend të rindezjeve manuale, ata filluan të përdorin monitorimin e nivelit të procesit për të rifilluar automatikisht aplikacionin në rast të një përfundimi jonormal. Nëse programi dështon, procesi i monitorimit kap kodin e daljes dhe rinis serverin. Me ardhjen e sistemeve si Kubernetes, ky lloj reagimi ndaj dështimeve të sistemit u integrua thjesht në infrastrukturë.
Kubernetes përdor një qark ngjarjesh vëzhgim-diferencë-veprim-veprim për të siguruar që burimet të mbeten të shëndetshme ndërsa udhëtojnë nga kontejnerët në vetë nyjet.
Kjo do të thotë që nuk keni më nevojë të ekzekutoni manualisht monitorimin e procesit. Nëse një burim dështon në Kontrollin Shëndetësor, Kubernetes thjesht do ta sigurojë atë automatikisht me një zëvendësim. Sidoqoftë, Kubernetes bën shumë më tepër sesa thjesht të monitorojë aplikacionin tuaj për dështime. Mund të krijojë më shumë kopje të aplikacionit për t'u ekzekutuar në shumë makina, për të përditësuar aplikacionin ose për të ekzekutuar disa versione të aplikacionit tuaj njëkohësisht.
Prandaj, ka shumë arsye pse Kubernetes mund të përfundojë një enë krejtësisht të shëndetshme. Për shembull, nëse përmirësoni vendosjen tuaj, Kubernetes do të ndalojë ngadalë podet e vjetra ndërsa fillon të reja. Nëse mbyllni një nyje, Kubernetes do të ndalojë funksionimin e të gjitha podeve në atë nyje. Më në fund, nëse një nyje i mbaron burimet, Kubernetes do të mbyllë të gjitha pod-et për të çliruar ato burime.
Prandaj, është thelbësore që aplikacioni juaj të përfundojë me ndikim minimal tek përdoruesi përfundimtar dhe kohë minimale rikuperimi. Kjo do të thotë që përpara se të mbyllet, duhet të ruajë të gjitha të dhënat që duhen ruajtur, të mbyllë të gjitha lidhjet e rrjetit, të përfundojë punën e mbetur dhe të menaxhojë detyra të 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 që është sinjali i parazgjedhur për mjetin kill në sistemet operative Unix. Me marrjen e këtij mesazhi, aplikacioni duhet të mbyllet.
Pasi Kubernetes vendos të përfundojë një pod, ndodhin një sërë ngjarjesh. Le të shohim çdo hap që Kubernetes ndërmerr kur mbyll një kontejner ose pod.
Le të themi se duam të mbyllim një nga pods. Në këtë pikë, do të ndalojë marrjen e trafikut të ri - kontejnerët që funksionojnë në pod nuk do të preken, por i gjithë trafiku i ri do të bllokohet.
Le të shohim grepin preStop, i cili është një komandë speciale ose kërkesë HTTP që dërgohet te kontejnerët në një pod. Nëse aplikacioni juaj nuk fiket siç duhet kur merr SIGTERM, mund të përdorni preStop për ta mbyllur siç duhet.
Shumica e programeve do të dalin me hijeshi kur marrin një sinjal SIGTERM, por nëse përdorni kod të palës së tretë ose ndonjë sistem që nuk e kontrolloni plotësisht, fiksimi i preStop është një mënyrë e shkëlqyer për të detyruar një mbyllje të këndshme pa ndryshuar aplikacionin.
Pas ekzekutimit të kësaj goditjeje, Kubernetes do të dërgojë një sinjal SIGTERM te kontejnerët në pod, duke i bërë të ditur se së shpejti do të shkëputen. Me marrjen e këtij sinjali, kodi juaj do të vazhdojë në procesin e mbylljes. Ky proces mund të përfshijë ndalimin e çdo lidhjeje jetëgjatë, si p.sh. një lidhje me bazën e të dhënave ose transmetimin e WebSocket, ruajtjen e gjendjes aktuale dhe të ngjashme.
Edhe nëse përdorni një grep preStop, është shumë e rëndësishme të kontrolloni se çfarë ndodh saktësisht me aplikacionin tuaj kur i dërgoni një sinjal SIGTERM dhe si sillet, në mënyrë që ngjarjet ose ndryshimet në funksionimin e sistemit të shkaktuara nga një mbyllje pod të mos vijnë si nje surprize per ju.
Në këtë pikë, Kubernetes do të presë për një kohë të caktuar, të quajtur terminationGracePeriodSecond, ose periudhën për t'u mbyllur me hijeshi kur të marrë një sinjal SIGTERM, përpara se të ndërmarrë veprime të mëtejshme.
Si parazgjedhje kjo periudhë është 30 sekonda. Është e rëndësishme të theksohet se ai funksionon paralelisht me grepin preStop dhe sinjalin SIGTERM. Kubernetes nuk do të presë që fiksimi i parandalimit dhe SIGTERM të mbarojnë—nëse aplikacioni juaj del përpara përfundimit të TerminationGracePeriod, Kubernetes do të kalojë menjëherë në hapin tjetër. Prandaj, kontrolloni që vlera e kësaj periudhe në sekonda të mos jetë më e vogël se koha e nevojshme për të mbyllur saktë podin dhe nëse i kalon 30 sekonda, rrisni periudhën në vlerën e dëshiruar në YAML. Në shembullin e dhënë, është 60-ta.
Dhe së fundi, hapi i fundit është nëse kontejnerët vazhdojnë të funksionojnë pas përfundimit të GracePeriod, ata do të dërgojnë një sinjal SIGKILL dhe do të fshihen me forcë. Në këtë pikë, Kubernetes do të pastrojë gjithashtu të gjitha objektet e tjera të pod.
Kubernetes përfundon pods për shumë arsye, prandaj sigurohuni që aplikacioni juaj të përfundojë me hijeshi në çdo rast për të siguruar një shërbim të qëndrueshëm.
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