Mikilvægur punktur í rekstri dreifðra kerfa er meðhöndlun bilana. Kubernetes hjálpar til við þetta með því að nota stýringar sem fylgjast með heilsu kerfisins þíns og endurræsa þjónustu sem eru hætt að virka. Hins vegar getur Kubernetes stöðvað forritin þín af krafti til að tryggja heildarheilbrigði kerfisins. Í þessari röð munum við skoða hvernig þú getur hjálpað Kubernetes að vinna starf sitt á skilvirkari hátt og draga úr niður í miðbæ forrita.
Fyrir gáma keyrðu flest forrit á sýndar- eða líkamlegum vélum. Ef forritið hrundi eða fraus tók það langan tíma að hætta við verkefnið sem var í gangi og endurhlaða forritið. Í versta falli þurfti einhver að leysa þetta vandamál handvirkt á nóttunni, á óheppilegustu tímum. Ef aðeins 1-2 vinnuvélar væru að sinna mikilvægu verkefni væri slík röskun algjörlega óviðunandi.
Þess vegna, í stað þess að endurræsa handvirkt, fóru þeir að nota eftirlit á ferlistigi til að endurræsa forritið sjálfkrafa ef óeðlileg uppsögn er. Ef forritið mistekst fangar eftirlitsferlið útgöngukóðann og endurræsir netþjóninn. Með tilkomu kerfa eins og Kubernetes var þessi tegund viðbragða við kerfisbilunum einfaldlega samþætt innviðina.
Kubernetes notar Observe-Difference-Act atburðarlykkju til að tryggja að auðlindir haldist heilbrigðar þegar þær ferðast frá gámunum að hnútunum sjálfum.
Þetta þýðir að þú þarft ekki lengur að keyra ferlivöktun handvirkt. Ef auðlind stenst ekki heilsufarsskoðun mun Kubernetes einfaldlega útvega það sjálfkrafa með vara. Hins vegar gerir Kubernetes miklu meira en bara að fylgjast með forritinu þínu fyrir bilanir. Það getur búið til fleiri afrit af forritinu til að keyra á mörgum vélum, uppfæra forritið eða keyra margar útgáfur af forritinu þínu samtímis.
Þess vegna eru margar ástæður fyrir því að Kubernetes getur lokað fullkomlega heilbrigðum íláti. Til dæmis, ef þú uppfærir dreifinguna þína, mun Kubernetes hægt og rólega stöðva gamla belg á meðan þú byrjar nýja. Ef þú lokar á hnút mun Kubernetes hætta að keyra alla belg á þeim hnút. Að lokum, ef hnút verður uppiskroppa með auðlindir, mun Kubernetes loka öllum belgjum til að losa um þær auðlindir.
Þess vegna er mikilvægt að forritinu þínu lýkur með lágmarksáhrifum á endanotandann og lágmarks endurheimtartíma. Þetta þýðir að áður en slökkt er á verður það að vista öll gögn sem þarf að vista, loka öllum nettengingum, klára vinnu sem eftir er og stjórna öðrum brýnum verkefnum.
Í reynd þýðir þetta að forritið þitt verður að geta meðhöndlað SIGTERM skilaboðin, ferlislokunarmerkið sem er sjálfgefið merki fyrir drápsforritið á Unix stýrikerfum. Þegar þessi skilaboð hafa borist ætti forritið að lokast.
Þegar Kubernetes ákveður að slíta belg, eiga sér stað nokkrir atburðir. Við skulum skoða hvert skref sem Kubernetes tekur þegar lokað er fyrir ílát eða belg.
Segjum að við viljum slíta einum af belgjunum. Á þessum tímapunkti mun það hætta að taka á móti nýrri umferð - gámar sem keyra í belgnum verða ekki fyrir áhrifum, en öll ný umferð verður lokuð.
Við skulum skoða preStop krókinn, sem er sérstök skipun eða HTTP beiðni sem er send í gáma í belg. Ef forritið þitt slekkur ekki á réttan hátt þegar þú færð SIGTERM geturðu notað preStop til að loka rétt.
Flest forrit hætta með þokkafullum hætti þegar þau fá SIGTERM merki, en ef þú ert að nota þriðja aðila kóða eða eitthvað kerfi sem þú stjórnar ekki að fullu, þá er preStop krókurinn frábær leið til að þvinga fram þokkafulla lokun án þess að breyta forritinu.
Eftir að hafa keyrt þennan krók mun Kubernetes senda SIGTERM merki til ílátanna í belgnum og láta þá vita að þeir verði bráðlega aftengdir. Þegar þú færð þetta merki mun kóðinn þinn halda áfram í lokunarferlið. Þetta ferli getur falið í sér að stöðva allar langvarandi tengingar eins og gagnagrunnstengingu eða WebSocket straum, vista núverandi ástand og þess háttar.
Jafnvel þótt þú notir preStop krók, þá er mjög mikilvægt að athuga hvað nákvæmlega gerist við forritið þitt þegar þú sendir því SIGTERM merki og hvernig það hegðar sér, svo að atburðir eða breytingar á kerfisrekstri sem orsakast af lokun pods komi ekki sem kemur þér á óvart.
Á þessum tímapunkti mun Kubernetes bíða í tiltekinn tíma, sem kallast terminationGracePeriodSecond, eða tímabilið til að loka af þokkafullum hætti þegar það fær SIGTERM merki, áður en frekari aðgerðir eru gerðar.
Sjálfgefið er að þetta tímabil sé 30 sekúndur. Það er mikilvægt að hafa í huga að það keyrir samhliða preStop króknum og SIGTERM merkinu. Kubernetes mun ekki bíða eftir að preStop krókinn og SIGTERM ljúki—ef forritið þitt hættir áður en TermminationGracePeriod lýkur mun Kubernetes fara strax í næsta skref. Þess vegna skaltu athuga að gildi þessa tímabils í sekúndum sé ekki minna en tíminn sem þarf til að slökkva á belgnum á réttan hátt og ef það fer yfir 30 sekúndur skaltu auka tímabilið í æskilegt gildi í YAML. Í dæminu sem gefið er er það 60s.
Og að lokum, síðasta skrefið er ef gámar eru enn í gangi eftir terminationGracePeriod, munu þeir senda SIGKILL merki og verður eytt með valdi. Á þessum tímapunkti mun Kubernetes einnig hreinsa upp alla aðra belghluti.
Kubernetes lokar belg af mörgum ástæðum, svo vertu viss um að forritinu þínu lýkur þokkalega í öllum tilvikum til að tryggja stöðuga þjónustu.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com