Ekki flytja í Kubernetes of snemma — sjálfvirk endurheimt hefur rekstrarverð

Docker Compose getur dugað í framleiðslu þegar forritið keyrir á einum þjóni, handvirk stækkun nægir og skýrt ferli er til fyrir bilanir. Leiðbeiningar Docker um Compose í framleiðslu lýsa einum þjóni sem einföldustu uppsetningunni, mæla með sérstakri framleiðslustillingu og benda á Swarm þegar stækka þarf yfir klasa. Fjöldi gáma einn og sér segir því lítið um hvort tímabært sé að flytja.

Kubernetes verður sterkari kostur þegar þjónustan þarf að lifa af brottfall hnúts, fjölga eintökum sjálfkrafa eftir álagi eða aðgreina heimildir þeirra sem reka hana. Leiðbeiningar Kubernetes um framleiðsluklasa tengja þessa getu við áætlanir um tiltækni, afkastagetu, aðgangsstýringu og viðhald. Ávinningurinn er því háður rekstri klasans sjálfs, ekki aðeins því að færa forritið á annan vettvang.

Hvenær dugar einn þjónn?

Fyrsta viðmiðið er bilunin sem þjónustan þarf að þola. Skráið hvað gerist þegar einn gámur stöðvast, þegar Docker-þjónustan stöðvast og þegar allur hýsillinn verður óaðgengilegur. Endurræsingarregla í Compose getur ræst gám aftur, en hún getur ekki haldið þjónustu gangandi á hýsli sem hefur fallið út. Ef samþykktur niðritími rúmar handvirka enduruppsetningu á annarri vél getur sá möguleiki samt verið nægilegur.

Prófið þá forsendu með raunverulegu endurheimtarferli: Hvar er skilgreining þjónustunnar geymd, hver getur ræst hana á nýjum hýsli og hvaðan koma gögnin? Afrit sem aldrei hefur verið endurheimt segir ekki til um hversu lengi þjónustan verður ótiltæk. Skráður endurheimtartími gefur betri ákvörðunargrundvöll en almenn tilfinning fyrir því að einn þjónn sé orðinn of lítill.

Stækkun þarf líka að skilja frá bilanaþoli. Ef álag vex hægt má fjölga eintökum handvirkt eða bæta afkastagetu við hýsilinn án þess að taka upp klasastýringu. Sú leið breytir þó ekki því að öll eintökin deila sömu vél. Þegar krafan er áframhaldandi þjónusta þrátt fyrir brottfall hennar þarf að bera saman lausnir sem dreifa keyrslu milli hnúta.

Gátlisti fyrir flutning í klasa

Farið frá afmarkaðri kröfu að flóknari rekstri. Hvert atriði á að leiða til mælanlegrar niðurstöðu, svo sem niðritíma, biðtíma eftir aukinni afkastagetu eða lista yfir heimildir, áður en vettvangur er valinn.

1. Margir hnútar: Þarf þjónustan að keyra á fleiri vélum til að standast álag eða bilun, eða myndi öflugri hýsill leysa vandann? Ef dreifð keyrsla er nauðsynleg er einföld Compose-uppsetning á einum þjóni komin að mörkum sínum. Berið þá Kubernetes saman við aðra klasaleið, þar á meðal Swarm, með sömu kröfur fyrir báðar lausnir.
2. Bilanaþol: Ákveðið hversu lengi þjónustan má vera óaðgengileg ef heill hnútur fellur út. Til að hún haldi áfram þarf fleiri en eitt virkt eintak, dreifingu þeirra og næga afkastagetu á öðrum hnútum. Prófið brottfall hnúts og mælið tímann þar til notendur fá aftur svar; tilvist klasa ein og sér tryggir ekki þá niðurstöðu.
3. Sjálfvirk stækkun: Sýnið fram á að álag breytist hraðar en rekstraraðilar geta brugðist við með handvirkri fjölgun eintaka. Skilgreinið mælikvarða, mörk og tiltæka afkastagetu áður en sjálfvirkni er valin. Fjölgun vinnueininga hjálpar lítið ef nýju eintökin komast ekki fyrir á hnútunum eða sameiginleg gagnageymsla ræður ekki við álagið.
4. Aðskildar heimildir: Teljið upp hver má dreifa útgáfu, breyta klasastillingum, lesa leyndarmál og skoða rekstrargögn. Hlutverkatengd aðgangsstýring Kubernetes, RBAC, getur úthlutað afmörkuðum heimildum innan nafnsviðs eða yfir allan klasann. Sú geta skiptir máli þegar ólík teymi eða sjálfvirk kerfi þurfa aðgang að sömu innviðum með mismunandi réttindum.

Merki á listanum er ástæða til að bera saman lausnir, ekki sjálfvirk skipun um flutning. Sérstaklega þarf að greina á milli kröfu um fleiri eintök og kröfu um að þau lifi af brottfall heillar vélar. Þær krefjast ólíkrar uppsetningar þótt sama forritið sé keyrt í báðum tilvikum.

Hvað sjálfvirk endurheimt leysir

Lýsing Kubernetes á sjálfvirkri endurheimt greinir á milli endurræsingar bilaðs gáms, nýrrar vinnueiningar í stað þeirrar sem féll út og þess að fjarlægja bilaða vinnueiningu úr þjónustubeiningum. Þegar hnútur verður ótiltækur getur kerfið ræst vinnu á öðrum hnút. Þetta eru aðskildar leiðir til að bregðast við bilun; þær virka aðeins að fullu þegar uppsetning, heilbrigðisathuganir og afkastageta styðja við þær.

Endurræst eintak tekur með sér sömu forritsvillu ef orsök bilunarinnar liggur í hugbúnaðinum. Óaðgengileg gagnageymsla getur einnig stöðvað þjónustuna þótt ný vinnueining ræsist. Þess vegna þarf að prófa bilun í gámi, vinnueiningu, hnút og gagnatengingu sérstaklega. Niðurstaðan segir hvaða sjálfvirkni styttir raunverulega rof í þjónustu og hvar enn þarf viðgerð eða endurheimt gagna.

Rekstrarverðið fylgir kröfunni

Framleiðsluklasi kallar á ákvarðanir um stjórnflöt, vinnuhnúta, vottorð, afrit af klasastillingum, uppfærslur og aðgang. Há tiltækni stjórnflatar krefst annarrar uppsetningar en klasi á einni vél; annars getur stjórnflöturinn sjálfur orðið veikur hlekkur. Stýrð þjónusta getur tekið að sér hluta þessa rekstrar, en eftir standa ákvarðanir um afkastagetu vinnuhnúta, réttindi, stöðu forritsins og gögn þess.

Setjið þennan rekstur upp á móti mældum niðritíma og þeirri handvirku vinnu sem núverandi uppsetning krefst. Ef vandinn er fyrst og fremst óæfð endurheimt á einum þjóni er eðlilegt að laga það ferli fyrst. Ef þjónustan verður hins vegar að svara áfram við brottfall hnúts, stækka án handvirkra inngripa eða veita aðskilinn aðgang að sameiginlegum innviðum, er hægt að velja klasalausn út frá þeim kröfum og prófa hvort hún uppfylli þær.

Lestu einnig:

• MCP-aðgangslykill má ekki fara áfram — skiptu honum við þjónustumörkin
• Shopify eða WooCommerce: rekstrarkostnaðurinn byrjar eftir áskriftina
• Kit eða beehiiv: ókeypis plássið og sjálfvirknin ráða valinu