Docker Compose eða Kubernetes: einn þjónn getur sparað rekstrarteymi

|Höfundur: Ritstjórn QUASA|6 mín. lestur
Docker Compose eða Kubernetes: einn þjónn getur sparað rekstrarteymi

Docker Compose getur keyrt framleiðsluforrit á einum þjóni, eins og framleiðsluleiðbeiningar Docker lýsa. Fyrir lítið teymi sem þolir skilgreindan tíma til handvirkrar endurheimtar getur sú uppsetning sparað sérstaka umsjón með þyrpingu. Það á þó aðeins við ef afrit, vöktun og viðbrögð við bilun alls þjónsins eru raunhæf.

Kubernetes réttlætist þegar þjónustan þarf að lifa af brottfall vélar, dreifa álagi yfir hnúta eða veita ólíkum rekstraraðilum afmarkaðar heimildir. Framleiðsluskjöl Kubernetes tengja slíkar kröfur við stjórnplan, vinnuhnúta, álagsdreifingu, afkastagetu og aðgangsstýringu. Þyrping er því rekstrarákvörðun með eigin viðhaldi, ekki sjálfvirk trygging fyrir samfelldri þjónustu.

Hvað fæst með Compose á einum þjóni?

Compose skilgreinir þjónustur, net og geymslur í sameiginlegri uppsetningu. Sama grunnskrá getur fylgt forritinu úr þróun í framleiðslu, en sérstök yfirlagsskrá geymt þær breytingar sem framleiðslan þarf. Þar má meðal annars stilla önnur tengi á hýslinum, umhverfisbreytur og endurræsingarreglu án þess að halda utan um aðra heildarútgáfu af uppsetningunni.

Þetta einfaldar útgáfuferlið þegar fáir sjá um reksturinn. Við breytingu á forriti er hægt að endurbyggja gámamynd þess og endurgera aðeins viðkomandi þjónustu. Sú endurgerð stöðvar gamla gáminn áður en nýr tekur við; þjónusta sem þolir engan roftíma þarf því aðra útgáfuleið eða sérstaka dreifingu beiðna. Skýr fyrri útgáfa og prófuð leið til að snúa við breytingu skipta meira máli en hversu stutt skipunin er.

Endurræsingarregla getur komið gámi aftur af stað eftir að ferli stöðvast. Hún kemur forritinu hins vegar ekki fyrir á annarri vél ef hýsillinn verður óaðgengilegur. Sá munur skilur á milli viðráðanlegs einsþjónsreksturs og kröfu um áframhaldandi þjónustu við vélabilun.

Framboð ræðst af biluninni sem þarf að þola

Aðskildir þjónshnútar sýna hvernig fjölhnúta rekstur getur haldið áfram þegar einn hnútur bilar.

Áður en fleiri hnútar eru valdir þarf að ákveða hvaða rof þjónustan má þola. Eitt er að gámur stöðvist og ræsist aftur á sömu vél; annað er að vél, diskur eða tenging hennar hverfi. Ef ábyrgðaraðili má endurheimta forritið innan samþykkts tíma getur einn þjónn dugað. Ef beiðnir verða að fá svar áfram við brottfall vélar þarf vinnu og umframgetu á fleiri en einum bilunarstað.

Kubernetes getur aðeins staðið undir þeirri síðari kröfu ef þyrpingin sjálf er hönnuð fyrir hana. Stjórnplan sem keyrir á einni vél er áfram einn bilunarpunktur; háframboð kallar á dreift stjórnplan, álagsdreifingu að API þjóninum og nóga vinnuhnúta fyrir forritið. Að setja Kubernetes á eina vél breytir því ekki afleiðingu þess að vélin stöðvast.

Gagnageymslan ræður líka úrslitum. Nýtt eintak forrits á heilbrigðum hnút getur ekki sótt gögn sem voru eingöngu á bilaða hýslinum. Þegar samfelldur rekstur er krafa þarf að skoða gagnagrunn, skrár og tengingar með sömu bilunarforsendum og vefþjóninn. Afrit getur stytt endurheimtartíma, en tekur ekki sjálfkrafa við lifandi beiðnum á meðan þjónninn er niðri.

Hvenær breyta skölun og heimildir valinu?

Fjölgun gáma á sama hýsli getur nýtt lausa afkastagetu hans, en bætir ekki við annarri vél. Þegar mælt álag krefst þess að eintök dreifist milli hnúta, eða fjölgunin þarf að fylgja sveiflum án handvirkra inngripa, verða stýringareiginleikar Kubernetes verðmætari. Samanburður Spacelift greinir handvirka fjölgun Compose á einum hýsli frá sjálfvirkri skölun Kubernetes yfir þyrpingu.

Sjálfvirk fjölgun eintaka krefst þó mælikvarða, skilgreindra marka og lauss rýmis á hnútum. Ef eina tiltæka vélin er þegar full býr nýtt eintak ekki til meira minni eða örgjörvaafl. Álag sem vex hægt og fyrirsjáanlega getur aftur á móti leyft áætlaða stækkun án þess að taka upp stjórnplan og sjálfvirka skölun.

Aðgangur getur verið sjálfstæð ástæða fyrir breytingu. Þegar fleiri teymi setja út þjónustur á sameiginlegum innviðum getur hlutverkatengd aðgangsstýring Kubernetes afmarkað hver má breyta tilteknum auðlindum. Lítið teymi með einum útgáfuaðila þarf ekki endilega sömu skiptingu. Heimildakerfið nýtist aðeins ef einhver skilgreinir hlutverkin, heldur þeim við og fer yfir hver hefur aðgang að leyndarmálum og framleiðslu.

Viðbragðsvakt er hluti af reikningnum

Þyrping flytur ákveðin viðbrögð við biluðum gámum yfir í sjálfvirka stýringu, en bætir við verkefnum sem einn hýsill hefur ekki í sömu mynd. Það þarf að halda utan um uppfærslur stjórnplans og hnúta, vottorð, afkastamörk og afrit af stillingagögnum þyrpingarinnar. Vöktun þarf einnig að sýna hvort sjálfvirk endurheimt hafi tekist, ekki aðeins hvort forritið svari á því augnabliki.

Stýrð Kubernetes þjónusta getur tekið að sér hluta stjórnplans og uppfærslna. Rekstraraðilinn ber samt ábyrgð á uppsetningu forritsins, aðgangi, vinnuhnútum eftir þjónustuleið og varanlegum gögnum. Fyrir lítið teymi getur kostnaður í tíma og viðbragðsvakt vegið þyngra en ávinningur af sjálfvirkni sem þjónustukröfurnar kalla ekki á. Við mat á rekstrarverði sjálfvirkrar endurheimtar skiptir sérstaklega máli að spyrja hver tekur við þegar sjálfvirknin nær ekki að laga bilunina.

Kröfulisti sem skýrir mörk eins þjóns

Valið verður skýrara þegar hver krafa er orðuð sem afleiðing fyrir rekstur, fremur en ósk um tiltekinn eiginleika. Eftirfarandi spurningar aðgreina þörf fyrir stærri vél, betri endurheimt og raunverulega þörf fyrir þyrpingu:

  • Framboð: Má þjónustan bíða eftir handvirkri endurheimt þegar heil vél fellur út, og hver er hámarkstími þess rofs?
  • Fjöldi hnúta: Þarf forritið að svara áfram eftir bilun hýsils, eða nægir að bæta afkastagetu við núverandi vél?
  • Skölun: Sýna mælingar að álag breytist hraðar en hægt er að fjölga eintökum handvirkt, og er afkastageta annars staðar tiltæk?
  • Aðgangsstýring: Þurfa ólík teymi að setja út eigin þjónustur án þess að fá víðtækan aðgang að sama rekstrarumhverfi?
  • Viðbragðsvakt: Hver fær viðvörun, tekur ákvörðun um endurheimt og getur sinnt henni þegar aðalumsjónaraðili er fjarverandi?

Fjöldi þjónusta segir minna en svörin við þessum spurningum. Lítið forrit getur þurft fjölhnúta framboð vegna strangrar þjónustuskyldu, á meðan fleiri þjónustur með stöðugu álagi kunna að rúmast á einum hýsli. Það er því bilunarsviðið, álagið og verkaskiptingin sem gefa valinu efni.

Stigvaxandi leið frá einsþjónsrekstri

Afrit varanlegra gagna er tengt við endurheimtarbúnað svo hægt sé að prófa endurheimt einsþjónsreksturs.

Þegar einn þjónn uppfyllir kröfurnar er gagnlegt að gera reksturinn endurheimtanlegan áður en hann stækkar. Framleiðslustillingar eiga heima aðskildar frá þróunarstillingum; útgáfur gáma þurfa að vera rekjanlegar og varanleg gögn að eiga afrit. Prófuð endurheimt á öðrum hýsli sýnir raunverulegan niðritíma og leiðir í ljós hvort gögn, aðgangsheimildir eða stillingar vanti. Slík reynsla getur breytt óljósri kröfu um meira bilanaþol í mælanlega rekstrarkröfu.

Ef sú krafa verður fjölhnúta framboð þarf að hanna gagnaflæði, netleiðir, leyndarmál og útgáfuferli fyrir nýtt umhverfi. Compose skilgreining flyst ekki sjálfkrafa yfir í fullbúna Kubernetes uppsetningu, þó að sama forrit og sömu gámamyndir geti áfram nýst. Compose getur jafnframt haldið hlutverki sínu í staðbundinni þróun þegar framleiðslan keyrir annars staðar. Ákvörðunin snýst um hvaða þjónustustigi þarf að standast og hvort teymið hafi burði til að reka þá lausn sem það velur.

Lestu einnig:

Deila:

Gerstu áskrifandi að fréttabréfinu okkar

Fáðu nýjustu fréttir af Web3, gervigreind og rafmyntum beint í pósthólfið.

0