Banatutako sistemen funtzionamenduan puntu garrantzitsu bat hutsegiteen kudeaketa da. Kubernetes-ek horretan laguntzen du zure sistemaren osasuna kontrolatzen duten eta funtzionatzeari utzi dioten zerbitzuak berrabiarazten dituzten kontrolagailuak erabiliz. Hala ere, Kubernetes-ek zure aplikazioak indarrez geldi ditzake sistemaren osasun orokorra ziurtatzeko. Serie honetan, Kubernetes-ek bere lana modu eraginkorragoan egiten eta aplikazioen geldialdi-denbora murrizten nola lagundu ikusiko dugu.
Edukiontzien aurretik, aplikazio gehienak makina birtualetan edo fisikoetan exekutatzen ziren. Aplikazioa huts egin edo izoztu bazen, denbora asko behar izan zen abian zegoen zeregina bertan behera uzteko eta programa berriro kargatzeko. Kasurik txarrenean, norbaitek arazo hau eskuz konpondu behar izan zuen gauez, ordu desegokietan. 1-2 lan-makinek zeregin garrantzitsu bat egiten bazuten, eten hori guztiz onartezina zen.
Hori dela eta, eskuz berrabiarazi beharrean, prozesu-mailako monitorizazioa erabiltzen hasi ziren aplikazioa automatikoki berrabiarazteko amaiera anormal bat gertatuz gero. Programak huts egiten badu, jarraipen-prozesuak irteera kodea hartzen du eta zerbitzaria berrabiarazten du. Kubernetes bezalako sistemen agerpenarekin, sistemaren hutsegiteen erantzun mota hau azpiegituran integratu besterik ez zen egin.
Kubernetes-ek behatu-diferentzia-hartu ekintza-gertaeren begizta bat erabiltzen du baliabideak osasuntsu mantentzen direla bermatzeko, edukiontzietatik nodoetara bidaiatzen duten bitartean.
Horrek esan nahi du jada ez duzula prozesuen monitorizazioa eskuz exekutatu beharrik. Baliabide batek Osasun-egiaztapenean huts egiten badu, Kubernetes-ek automatikoki ordezko batekin hornituko du. Hala ere, Kubernetes-ek zure aplikazioa akatsak kontrolatzea baino askoz gehiago egiten du. Aplikazioaren kopia gehiago sor ditzake hainbat makinatan exekutatzeko, aplikazioa eguneratzeko edo zure aplikazioaren hainbat bertsio aldi berean exekutatzeko.
Hori dela eta, arrazoi asko daude Kubernetes-ek ezin hobeto osasuntsu dagoen edukiontzi bat amaitzeko. Adibidez, zure inplementazioa berritzen baduzu, Kubernetes-ek poliki poliki geldituko ditu pod zaharrak berriak hasten dituen bitartean. Nodo bat ixten baduzu, Kubernetes-ek nodo horretako pod guztiak exekutatzen utziko du. Azkenik, nodo bat baliabiderik gabe geratzen bada, Kubernetes-ek ontzi guztiak itxiko ditu baliabide horiek askatzeko.
Hori dela eta, ezinbestekoa da zure aplikazioa amaitzea azken erabiltzailearengan eragin minimoarekin eta berreskuratzeko denbora minimoarekin. Horrek esan nahi du itzali aurretik, gorde behar diren datu guztiak gorde behar dituela, sareko konexio guztiak itxi, geratzen diren lanak amaitu eta premiazko beste zeregin batzuk kudeatu behar dituela.
Praktikan, horrek esan nahi du zure aplikazioak SIGTERM mezua kudeatu behar duela, Unix sistema eragileetan hiltzeko utilitatearen seinale lehenetsia den prozesua amaitzeko seinalea. Mezu hau jasotzean, aplikazioa itxi egin beharko litzateke.
Kubernetes-ek pod bat amaitzea erabakitzen duenean, hainbat gertaera gertatzen dira. Ikus ditzagun Kubernetes-ek edukiontzi edo ontzi bat ixtean ematen duen urrats bakoitza.
Demagun leketako bat amaitu nahi dugula. Une honetan, trafiko berria jasotzeari utziko dio - ontzian ibiltzen diren edukiontziak ez du eraginik izango, baina trafiko berri guztia blokeatuta egongo da.
Ikus dezagun preStop kakoa, hau da, ontzi bateko edukiontzietara bidaltzen den komando edo HTTP eskaera berezi bat. SIGTERM jasotzean zure aplikazioa behar bezala ixten ez bada, preStop erabil dezakezu behar bezala ixteko.
Programa gehienak dotore irtengo dira SIGTERM seinalea jasotzen dutenean, baina hirugarrenen kodea edo guztiz kontrolatzen ez duzun sistemaren bat erabiltzen ari bazara, preStop kakoa modu bikaina da aplikazioa aldatu gabe itzali dotorea behartzeko.
Hook hau exekutatu ondoren, Kubernetes-ek SIGTERM seinalea bidaliko die ontziko edukiontziei, laster deskonektatuko direla jakinarazteko. Seinale hau jasotzean, zure kodea itzaltze prozesura jarraituko du. Prozesu honek iraupen luzeko konexioak geldiaraztea izan daiteke, hala nola datu-basearen konexioa edo WebSocket korrontea, uneko egoera gordetzea eta antzekoak.
PreStop kako bat erabiltzen baduzu ere, oso garrantzitsua da SIGTERM seinalea bidaltzen diozunean zure aplikazioarekin zer gertatzen den zehatz-mehatz egiaztatzea eta nola jokatzen duen. sorpresa bat zuretzat.
Une honetan, Kubernetes-ek denbora zehatz bat itxarongo du, terminationGracePeriodSecond izenekoa, edo SIGTERM seinalea jasotzen duenean ongi itzaltzeko epea, neurri gehiago hartu aurretik.
Berez, epe hori 30 segundokoa da. Kontuan izan behar da preStop kakoarekin eta SIGTERM seinalearekin paraleloan doala. Kubernetes ez da itxarongo preStop amua eta SIGTERM amaitzen diren arte; zure aplikazioa TerminationGracePeriod amaitu baino lehen irteten bada, Kubernetes berehala pasatuko da hurrengo urratsera. Hori dela eta, egiaztatu aldi honen balioa segundotan ez dela poda behar bezala ixteko behar den denbora baino txikiagoa, eta 30s gainditzen baditu, areagotu epea YAML-n nahi den balioraino. Emandako adibidean, 60ko hamarkadakoa da.
Eta, azkenik, azken urratsa, GracePeriod amaitu ondoren edukiontziak oraindik martxan badira, SIGKILL seinalea bidaliko dute eta indarrez ezabatuko dira. Une honetan, Kubernetes-ek gainerako pod objektu guztiak ere garbituko ditu.
Kubernetes-ek arrazoi askorengatik amaitzen ditu pod-ak, beraz, ziurtatu zure aplikazioa ongi amaitzen dela edozein kasutan, zerbitzu egonkorra bermatzeko.
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com