Athugið. þýð.: þetta efni er úr fræðsluverkefni er svarið við vinsælli spurningu þegar verið er að hanna innviði sem byggir á Kubernetes. Við vonum að nokkuð nákvæmar lýsingar á kostum og göllum hvers valkosts muni hjálpa þér að gera besta valið fyrir verkefnið þitt.
TL; DR: sama sett af vinnuálagi er hægt að keyra á nokkrum stórum þyrpingum (hver þyrping mun hafa mikið af vinnuálagi) eða á mörgum litlum (með litlum fjölda álags í hverjum klasa).
Hér að neðan er tafla sem metur kosti og galla hverrar aðferðar:
Þegar Kubernetes er notað sem vettvang til að keyra forrit vakna oft nokkrar grundvallarspurningar um ranghala uppsetningu klasa:
- Hversu marga klasa ætti ég að nota?
- Hvað ætti ég að gera þær stórar?
- Hvað ætti hver klasi að innihalda?
Í þessari grein mun ég reyna að svara öllum þessum spurningum með því að greina kosti og galla hverrar aðferðar.
Yfirlýsing spurningar
Sem hugbúnaðarhönnuður þróar þú og rekur líklega mörg forrit á sama tíma.
Að auki er líklegt að mörg tilvik þessara forrita keyri í mismunandi umhverfi - til dæmis geta þau verið það dev, próf и prod.
Niðurstaðan er heilt fylki af forritum og umhverfi:
Umsóknir og umhverfi
Dæmið hér að ofan sýnir 3 forrit og 3 umhverfi, sem leiðir til alls 9 mögulegra valkosta.
Hvert forritstilvik er sjálfstætt dreifingareining sem hægt er að vinna með óháð öðrum.
takið eftir því umsóknardæmi getur samanstandið af mörgum hluti, svo sem framenda, bakenda, gagnagrunns osfrv. Ef um er að ræða smáþjónustuforrit mun tilvikið innihalda allar örþjónusturnar.
Þess vegna hafa Kubernetes notendur nokkrar spurningar:
- Ætti öll umsóknartilvik að vera sett í einn klasa?
- Er það þess virði að hafa sérstakan klasa fyrir hvert forritstilvik?
- Eða ætti kannski að nota blöndu af ofangreindum aðferðum?
Allir þessir valkostir eru alveg raunhæfir þar sem Kubernetes er sveigjanlegt kerfi sem takmarkar ekki getu notandans.
Hér eru nokkrar af mögulegum leiðum:
- einn stór sameiginlegur klasi;
- margir litlir mjög sérhæfðir klasar;
- einn klasi fyrir hverja umsókn;
- einn þyrping í hverju umhverfi.
Eins og sýnt er hér að neðan eru fyrstu tvær aðferðirnar á sitt hvorum enda valkostakvarða:
Frá nokkrum stórum þyrpingum (vinstri) til margra lítilla (hægri)
Almennt séð er einn þyrping talinn „stærri“ en annar ef hann hefur stærri summa af hnútum og fræbelgjum. Til dæmis er þyrping með 10 hnúta og 100 belg stærri en þyrping með 1 hnút og 10 belg.
Jæja, við skulum byrja!
1. Ein stór sameiginleg þyrping
Fyrsti kosturinn er að setja allt vinnuálag í einn klasa:
Einn stór þyrping
Innan þessarar nálgunar er klasinn notaður sem alhliða innviðavettvangur — þú setur einfaldlega allt sem þú þarft í núverandi Kubernetes þyrping.
Kubernetes gerir kleift að aðgreina hluta þyrpingarinnar rökrétt frá hvor öðrum, þannig að hvert forritstilvik getur haft sitt eigið nafnrými.
Við skulum skoða kosti og galla þessarar aðferðar.
+ Skilvirk nýting auðlinda
Með einum klasa þarftu aðeins eitt eintak af öllum tilföngum sem þarf til að keyra og stjórna Kubernetes klasanum.
Þetta á til dæmis við um aðalhnúta. Venjulega hefur hver Kubernetes þyrping 3 aðalhnúta, þannig að fyrir einn stakan klasa verður fjöldi þeirra áfram þannig (til samanburðar þurfa 10 klasar 30 aðalhnúta).
Ofangreind fíngerð á einnig við um aðra þjónustu sem starfar yfir allan klasann, svo sem álagsjafnara, inngöngustýringar, auðkenningar-, skráningar- og eftirlitskerfi.
Í einum klasa er hægt að nota allar þessar þjónustur í einu fyrir allt vinnuálag (ekki þarf að búa til afrit af þeim eins og er með marga klasa).
+ Ódýrt
Sem afleiðing af ofangreindu eru færri klasar venjulega ódýrari vegna þess að það er enginn yfirkostnaður.
Þetta á sérstaklega við um aðalhnúta, sem geta kostað umtalsverða upphæð óháð því hvernig þeir eru hýstir (inni á staðnum eða í skýinu).
Sumar stýrðar Kubernetes þjónustur, svo sem eða , gefðu upp stjórnunarlagið ókeypis. Í þessu tilviki er kostnaðarmálið minna bráð.
Það eru líka stýrðar þjónustur sem taka fast gjald fyrir rekstur hvers Kubernetes klasa (td. ).
+ Skilvirk stjórnsýsla
Að stjórna einum klasa er auðveldara en að stjórna nokkrum.
Stjórnun getur falið í sér eftirfarandi verkefni:
- Kubernetes útgáfa uppfærsla;
- setja upp CI/CD leiðslu;
- að setja upp CNI viðbótina;
- setja upp notendavottunarkerfi;
- uppsetning aðgangsstýringar;
og margir aðrir…
Ef um einn klasa er að ræða þarftu að gera allt þetta aðeins einu sinni.
Fyrir marga klasa þarf að endurtaka aðgerðir oft, sem mun líklega krefjast einhverrar sjálfvirkni í ferlum og verkfærum til að tryggja samræmi og samræmi í ferlinu.
Og nú nokkur orð um gallana.
- Einn bilunarpunktur
Ef um synjun er að ræða sá eini þyrpingin hættir strax að virka allt vinnuálag!
Það eru margar leiðir sem hlutir geta farið úrskeiðis:
- uppfærsla Kubernetes leiðir til óvæntra aukaverkana;
- Hluti fyrir þyrpinguna (til dæmis CNI viðbót) byrjar að virka ekki eins og búist var við;
- einn af klasahlutunum er ekki rétt stilltur;
- bilun í undirliggjandi innviðum.
Eitt slíkt atvik getur valdið alvarlegum skaða á öllu vinnuálagi sem hýst er í sameiginlegum klasa.
- Engin stíf einangrun
Að keyra í sameiginlegum klasa þýðir að forrit deila vélbúnaði, netgetu og stýrikerfi á klasahnútunum.
Í vissum skilningi eru tveir gámar með tveimur mismunandi forritum sem keyra á sama hnút eins og tveir ferlar sem keyra á sömu vélinni sem keyra sama OS kjarnann.
Linux gámar veita einhvers konar einangrun, en hún er ekki nærri eins sterk og sú sem sýndarvélar bjóða upp á. Í meginatriðum er ferli í gámi sama ferli sem keyrir á stýrikerfi gestgjafans.
Þetta getur verið öryggisvandamál: þetta fyrirkomulag leyfir fræðilega ótengdum forritum að eiga samskipti sín á milli (annað hvort viljandi eða óvart).
Að auki, allt vinnuálag í Kubernetes klasa deilir einhverri þjónustu um alla klasa eins og - þetta gerir forritum kleift að finna þjónustu annarra forrita í klasanum.
Allir ofangreindir punktar geta haft mismunandi merkingu eftir öryggiskröfum forritsins.
Kubernetes býður upp á ýmis verkfæri til að koma í veg fyrir öryggisvandamál eins og и . Hins vegar að setja þau upp rétt krefst nokkurrar reynslu; auk þess geta þeir ekki lokað nákvæmlega öllum öryggisgötum.
Það er mikilvægt að muna alltaf að Kubernetes var upphaflega hannað fyrir deila, ekki fyrir einangrun og öryggi.
− Skortur á strangri fjöleignarleigu
Í ljósi þess hversu mikið af sameiginlegum auðlindum er í Kubernetes klasa, þá eru margar leiðir til að mismunandi forrit geti stigið hvert á tærnar á öðru.
Til dæmis gæti forrit einokað sameiginlega auðlind (eins og CPU eða minni) og neitað öðrum forritum sem keyra á sama hnút aðgang að því.
Kubernetes býður upp á ýmsar aðferðir til að stjórna þessari hegðun, svo sem (sjá einnig greinina “"- ca. þýðing.), и . Hins vegar, eins og í tilfelli öryggis, er uppsetning þeirra frekar ólétt og þau geta ekki komið í veg fyrir algerlega allar ófyrirséðar aukaverkanir.
- Mikill fjöldi notenda
Ef um einn klasa er að ræða þarftu að opna aðgang að honum fyrir marga. Og því meiri sem fjöldi þeirra er, því meiri hætta er á að þeir „brjóti“ eitthvað.
Innan klasans geturðu stjórnað hver getur gert hvað með því að nota (sjá grein “"- ca. þýðing.). Hins vegar mun það ekki koma í veg fyrir að notendur „brjóti“ eitthvað innan marka ábyrgðarsviðs þeirra.
− Klasar geta ekki vaxið endalaust
Klasinn sem er notaður fyrir allt vinnuálag mun líklega vera nokkuð stór (miðað við fjölda hnúta og belg).
En hér kemur annað vandamál upp: klasar í Kubernetes geta ekki vaxið endalaust.
Það eru fræðileg takmörk fyrir klasastærð. Í Kubernetes er það um það bil .
Hins vegar, í raunveruleikanum, geta vandamál byrjað miklu fyrr - til dæmis bara með .
Staðreyndin er sú að stórir klasar leggja mikið álag á Kubernetes stjórnlagið. Með öðrum orðum, að halda þyrpingunni gangandi á skilvirkan hátt krefst vandlegrar stillingar.
Þetta mál er skoðað í tengdri grein á upprunalega blogginu sem heitir "'.
En við skulum íhuga gagnstæða nálgun: marga litla klasa.
2. Margir litlir sérhæfðir klasar
Með þessari nálgun notarðu sérstakan klasa fyrir hvern þátt sem þú setur upp:
Margir litlir klasar
Að því er varðar þessa grein, skv útfæranlegur þáttur vísar til tilviks um forrit - til dæmis þróunarútgáfu af sérstöku forriti.
Þessi stefna notar Kubernetes sem sérhæfðan keyrslutími fyrir einstök umsóknartilvik.
Við skulum skoða kosti og galla þessarar aðferðar.
+ Takmarkaður „sprengjuradíus“
Þegar klasi mistekst takmarkast neikvæðu afleiðingarnar aðeins við það vinnuálag sem var komið fyrir í þeim klasa. Allt annað vinnuálag er ósnortið.
+ Einangrun
Vinnuálag sem hýst er í einstökum klösum deilir ekki auðlindum eins og örgjörva, minni, stýrikerfi, neti eða annarri þjónustu.
Niðurstaðan er þétt einangrun milli óskyldra forrita, sem getur verið gagnlegt fyrir öryggi þeirra.
+ Lítill fjöldi notenda
Í ljósi þess að hver þyrping inniheldur aðeins takmarkað sett af vinnuálagi, fækkar notendum sem hafa aðgang að honum.
Því færri sem hafa aðgang að þyrpingunni, því minni hætta er á að eitthvað „brotni“.
Við skulum skoða gallana.
− Óhagkvæm nýting auðlinda
Eins og fyrr segir, krefst hver Kubernetes þyrping ákveðins hóps stjórnunarauðlinda: aðalhnúta, stjórnlagahluta, eftirlits- og skráningarlausnir.
Ef um er að ræða fjölda lítilla klasa þarf að verja stærri hluta fjármagns til stjórnenda.
— Dýrt
Óhagkvæm nýting auðlinda hefur sjálfkrafa mikinn kostnað í för með sér.
Til dæmis, að viðhalda 30 aðalhnútum í stað þriggja með sama tölvugetu mun endilega hafa áhrif á kostnað.
− Erfiðleikar í stjórnsýslu
Að stjórna mörgum Kubernetes þyrpingum er miklu erfiðara en að stjórna aðeins einum.
Til dæmis verður þú að stilla auðkenningu og heimild fyrir hvern klasa. Einnig þarf að uppfæra Kubernetes útgáfuna nokkrum sinnum.
Þú munt líklega þurfa að nota sjálfvirkni til að gera öll þessi verkefni skilvirkari.
Nú skulum við skoða minna öfgakenndar aðstæður.
3. Einn klasi fyrir hverja umsókn
Í þessari nálgun býrðu til sérstakan klasa fyrir öll tilvik tiltekins forrits:
Klasi fyrir hverja umsókn
Líta má á þessa leið sem alhæfingu á meginreglunni „sér þyrping á hvert lið“, þar sem venjulega er hópur verkfræðinga að þróa eitt eða fleiri forrit.
Við skulum skoða kosti og galla þessarar aðferðar.
+ Hægt er að aðlaga klasann að forritinu
Ef forrit hefur sérþarfir er hægt að útfæra þær í klasa án þess að hafa áhrif á aðra klasa.
Slíkar þarfir geta verið GPU starfsmenn, ákveðin CNI viðbætur, þjónustunet eða einhver önnur þjónusta.
Hægt er að sníða hvern klasa að forritinu sem keyrir í honum þannig að það innihaldi aðeins það sem þarf.
− Mismunandi umhverfi í einum klasa
Ókosturinn við þessa nálgun er að forritatilvik frá mismunandi umhverfi eru til í sama klasanum.
Til dæmis keyrir prod útgáfan af forritinu í sama klasa og dev útgáfan. Þetta þýðir líka að forritarar starfa í sama klasa og framleiðsluútgáfa forritsins er rekin í.
Ef, vegna aðgerða þróunaraðila eða bilana í þróunarútgáfunni, kemur upp bilun í þyrpingunni, þá gæti framleiðsluútgáfan einnig orðið fyrir þjáningum - mikill galli við þessa nálgun.
Og að lokum, síðasta atburðarásin á listanum okkar.
4. Einn þyrping í hverju umhverfi
Þessi atburðarás felur í sér að úthluta sérstökum klasa fyrir hvert umhverfi:
Einn þyrping í hverju umhverfi
Til dæmis gætir þú verið með klasa dev, próf и prod, þar sem þú munt keyra öll tilvik af forritinu sem er tileinkað tilteknu umhverfi.
Hér eru kostir og gallar þessarar aðferðar.
+ Einangrun framleiðsluumhverfisins
Innan þessarar nálgunar er allt umhverfi einangrað hvert frá öðru. Hins vegar, í reynd, er þetta sérstaklega mikilvægt í framleiðsluumhverfi.
Framleiðsluútgáfur forritsins eru nú óháðar því sem er að gerast í öðrum klösum og umhverfi.
Þannig, ef vandamál koma skyndilega upp í þróunarklasanum, munu framleiðsluútgáfur forritanna halda áfram að virka eins og ekkert hafi í skorist.
+ Hægt er að aðlaga klasann að umhverfinu
Hægt er að aðlaga hvern klasa að umhverfi sínu. Til dæmis geturðu:
- setja upp verkfæri fyrir þróun og villuleit í dev þyrpingunni;
- setja upp prófunarramma og verkfæri í klasanum próf;
- nota öflugri vélbúnað og netrásir í klasanum prod.
Þetta gerir þér kleift að auka skilvirkni bæði þróunar forrita og reksturs.
+ Að takmarka aðgang að framleiðsluklasanum
Þörfin fyrir að vinna beint með framleiðsluklasa kemur sjaldan upp, svo þú getur takmarkað verulega hóp fólks sem hefur aðgang að honum.
Þú getur gengið enn lengra og neitað fólki um aðgang að þessum klasa með öllu og framkvæmt allar dreifingar með því að nota sjálfvirkt CI/CD tól. Slík nálgun mun lágmarka hættuna á mannlegum mistökum nákvæmlega þar sem hún á mest við.
Og nú nokkur orð um gallana.
- Engin einangrun á milli forrita
Helsti ókosturinn við nálgunina er skortur á vélbúnaði og auðlindaeinangrun milli forrita.
Ótengd forrit deila klasaauðlindum: kerfiskjarna, örgjörva, minni og einhverri annarri þjónustu.
Eins og fram hefur komið getur þetta verið hættulegt.
- Vanhæfni til að staðsetja forritaháð
Ef umsókn hefur sérstakar kröfur, þá verður að uppfylla þær í öllum klasa.
Til dæmis, ef forrit krefst GPU, þá verður hver þyrping að innihalda að minnsta kosti einn starfsmann með GPU (jafnvel þótt það sé aðeins notað af því forriti).
Afleiðingin er sú að við hættum meiri kostnaði og óhagkvæmri nýtingu auðlinda.
Ályktun
Ef þú ert með ákveðið sett af forritum er hægt að setja þau í nokkra stóra klasa eða marga litla.
Greinin fjallar um kosti og galla ýmissa aðferða, allt frá einum alþjóðlegum klasa til nokkurra lítilla og mjög sérhæfðra:
- einn stór almennur klasi;
- margir litlir mjög sérhæfðir klasar;
- einn klasi fyrir hverja umsókn;
- einn þyrping í hverju umhverfi.
Svo hvaða nálgun ættir þú að taka?
Eins og alltaf veltur svarið á notkunartilvikinu: þú þarft að vega kosti og galla mismunandi aðferða og velja ákjósanlegasta kostinn.
Hins vegar er valið ekki takmarkað við dæmin hér að ofan - þú getur notað hvaða samsetningu sem er!
Til dæmis er hægt að skipuleggja nokkra klasa fyrir hvert lið: þróunarklasa (þar sem verður umhverfi dev и próf) og þyrping fyrir framleiðslu (hvar framleiðsluumhverfið verður staðsett).
Byggt á upplýsingum í þessari grein geturðu fínstillt kosti og galla í samræmi við tiltekna atburðarás. Gangi þér vel!
PS
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com