Kubernetes: opinn uppspretta vs seljandasértækur

Halló, ég heiti Dmitry Krasnov. Í meira en fimm ár hef ég verið að stjórna Kubernetes klasa og smíða flókna örþjónustuarkitektúra. Í byrjun þessa árs settum við á markað þjónustu til að stjórna Kubernetes klasa sem byggir á Containerum. Með því að nota þetta tækifæri mun ég segja þér hvað Kubernetes er og hvernig samþætting við söluaðila er frábrugðin opnum uppspretta.

Til að byrja með, hvað er Kubernetes. Þetta er kerfi til að stjórna gámum á fjölda véla. Frá grísku, við the vegur, er það þýtt sem „flugmaður“ eða „stýrimaður“. Upphaflega þróað af Google og síðan gefið sem tækniframlag til Cloud Native Computing Foundation, alþjóðlegra sjálfseignarstofnunar sem sameinar leiðandi þróunaraðila heims, endanotendur og gámatækniveitendur.

Stjórna miklum fjölda gáma

Nú skulum við reikna út hvers konar ílát þetta eru. Þetta er forrit með öllu umhverfi sínu - aðallega söfnunum sem forritið er háð. Öllu þessu er pakkað í skjalasafn og sett fram í formi myndar sem hægt er að keyra óháð stýrikerfi, prófa og fleira. En það er vandamál - það er mjög erfitt að stjórna gámum á miklum fjölda gestgjafa. Þess vegna var Kubernetes búið til.

Gámamynd táknar forrit auk ósjálfstæðis þess. Forritið, ósjálfstæði þess og OS skráarkerfismyndin eru staðsett á mismunandi hlutum myndarinnar, svokölluð lög. Hægt er að endurnýta lög fyrir mismunandi ílát. Til dæmis gætu öll forrit í fyrirtæki notað Ubuntu grunnlagið. Þegar ílát eru keyrð er engin þörf á að geyma mörg eintök af einu grunnlagi á hýsilinn. Þetta gerir þér kleift að hámarka geymslu og afhendingu mynda.

Þegar við viljum keyra forrit úr gámi eru nauðsynleg lög lögð ofan á hvert annað og yfirlagsskráarkerfi myndast. Upptökulag er sett ofan á sem er fjarlægt þegar ílátið stoppar. Þetta tryggir að þegar gámurinn keyrir mun forritið alltaf hafa sama umhverfi, sem ekki er hægt að breyta. Þetta tryggir endurgerðanleika umhverfisins á mismunandi stýrikerfi. Hvort sem það er Ubuntu eða CentOS mun umhverfið alltaf vera það sama. Að auki er ílátið einangrað frá hýslinum með því að nota kerfi sem er innbyggt í Linux kjarnann. Forrit í gámi sjá ekki skrár, ferla hýsilsins og nærliggjandi gáma. Þessi einangrun forrita frá stýrikerfi gestgjafans veitir aukið öryggislag.

Það eru mörg verkfæri í boði til að stjórna gámum á gestgjafa. Vinsælastur þeirra er Docker. Það gerir þér kleift að veita allan líftíma gáma. Hins vegar virkar það aðeins á einum gestgjafa. Ef þú þarft að stjórna gámum yfir marga gestgjafa, getur Docker gert verkfræðinga að helvíti. Þess vegna var Kubernetes búið til.

Eftirspurnin eftir Kubernetes er einmitt vegna getu til að stjórna hópum af gámum á mörgum vélum sem sameinuð einingar. Vinsældir kerfisins gefa tækifæri til að byggja upp DevOps eða þróunaraðgerðir, þar sem Kubernetes er notað til að keyra ferla þessa DevOps.

Mynd 1. Skýringarmynd af því hvernig Kubernetes virkar

Full sjálfvirkni

DevOps er í grundvallaratriðum sjálfvirkni þróunarferlisins. Í grófum dráttum skrifa verktaki kóða sem er hlaðið upp í geymsluna. Síðan er hægt að safna þessum kóða sjálfkrafa strax í gám með öllum bókasöfnum, prófa hann og „rúlla“ út á næsta stig - Staging, og síðan strax í framleiðslu.

Ásamt Kubernetes gerir DevOps þér kleift að gera þetta ferli sjálfvirkt þannig að það gerist með nánast enga þátttöku frá hönnuðunum sjálfum. Vegna þessa er smíðin umtalsvert hraðari, þar sem verktaki þarf ekki að gera þetta í tölvunni sinni - hann skrifar einfaldlega kóða, ýtir kóðanum í geymsluna, eftir það er leiðslan ræst, sem getur falið í sér ferlið að smíða, prófa og koma út. Og þetta gerist við hverja skuldbindingu, svo prófanir eiga sér stað stöðugt.

Á sama tíma, með því að nota ílát gerir þér kleift að vera viss um að allt umhverfi þessa forrits verði gefið út í framleiðslu nákvæmlega í því formi sem það var prófað. Það er, það verða engin vandamál eins og „það voru sumar útgáfur í prófinu, aðrar í framleiðslu, en þegar við settum þær upp féll allt.“ Og þar sem í dag erum við með þróun í átt að örþjónustuarkitektúr, þegar í stað eins risastórs forrits eru hundruðir lítilla, til að stjórna þeim handvirkt, þarf mikið starfsfólk af starfsmönnum. Þess vegna notum við Kubernetes.

Kostir, kostir, kostir

Ef við tölum um kosti Kubernetes sem vettvangs, þá hefur það verulega kosti frá sjónarhóli stjórnun örþjónustuarkitektúrs.

• Umsjón með mörgum eftirlíkingum. Það mikilvægasta er að stjórna gámum yfir marga gestgjafa. Meira um vert, stjórna mörgum eftirlíkingum af forritum í gámum sem ein heild. Þökk sé þessu þurfa verkfræðingar ekki að hafa áhyggjur af hverjum einstökum gámum. Ef einn af gámunum hrynur mun Kubernetes sjá þetta og endurræsa það aftur.
• Klasanet. Kubernetes er einnig með svokallað klasanet með eigin heimilisfangarými. Þökk sé þessu hefur hver belg sitt eigið heimilisfang. Lágmarksbyggingareining þyrpings þar sem gámum er beint í loftið. Að auki hefur Kubernetes virkni sem sameinar álagsjafnvægi og þjónustuuppgötvun. Þetta gerir þér kleift að losna við handvirka IP-tölustjórnun og úthluta þessu verkefni til Kubernetes. Og sjálfvirkt heilsufarseftirlit mun hjálpa til við að greina vandamál og beina umferð á virka belg.
• Stillingarstjórnun. Þegar stjórnað er miklum fjölda forrita verður erfitt að stjórna uppsetningu forrita. Í þessu skyni hefur Kubernetes sérstök ConfigMap auðlindir. Þeir gera þér kleift að geyma stillingar miðlægt og afhjúpa þær fyrir belg þegar þú keyrir forrit. Þetta fyrirkomulag gerir okkur kleift að tryggja samkvæmni stillingarinnar í að minnsta kosti tíu eða hundrað eftirlíkingar af forritum.
• Viðvarandi bindi. Gámar eru í eðli sínu óbreytanlegir og þegar gámurinn er stöðvaður verður öllum gögnum sem eru skrifuð í skráarkerfið eytt. En sum forrit geyma gögn beint á disknum. Til að leysa þetta vandamál hefur Kubernetes diskgeymslustjórnunarvirkni - Viðvarandi bindi. Þessi vélbúnaður notar ytri geymslu fyrir gögn og getur flutt viðvarandi geymslu, blokk eða skrá, í gáma. Þessi lausn gerir þér kleift að geyma gögn aðskilið frá starfsmönnum, sem vistar þau ef þessir sömu starfsmenn bila.
• Hleðslujafnari. Jafnvel þó að í Kubernetes stýrum við óhlutbundnum einingum eins og Deployment, StatefulSet, osfrv., keyra gámar á endanum á venjulegum sýndarvélum eða vélbúnaðarþjónum. Þeir eru ekki fullkomnir og geta fallið hvenær sem er. Kubernetes mun sjá þetta og beina innri umferð til annarra eftirmynda. En hvað á að gera við umferð sem kemur að utan? Ef þú beinir einfaldlega umferð til einhvers starfsmanna, ef hún hrynur, verður þjónustan ófáanleg. Til að leysa þetta vandamál hefur Kubernetes þjónustu eins og Load Balancer. Þau eru hönnuð til að stilla sjálfkrafa ytri skýjajafnvægi fyrir alla starfsmenn í klasanum. Þessi ytri jafnvægismaður beinir utanaðkomandi umferð til starfsmanna og fylgist sjálfur með stöðu þeirra. Ef einn eða fleiri starfsmenn verða ótiltækir er umferð beint til annarra. Þetta gerir þér kleift að búa til mjög tiltæka þjónustu með Kubernetes.

Kubernetes virkar best þegar keyrt er örþjónustuarkitektúr. Það er hægt að innleiða kerfið í klassískan arkitektúr en það er tilgangslaust. Ef forrit getur ekki keyrt á mörgum eftirlíkingum, hvaða máli skiptir það þá - í Kubernetes eða ekki?

Opinn uppspretta Kubernetes

Opinn uppspretta Kubernetes er frábær hlutur: ég setti það upp og það virkar. Þú getur sett það á eigin vélbúnaðarþjóna, á eigin innviði, sett upp meistara og starfsmenn sem öll forrit munu keyra á. Og síðast en ekki síst, allt þetta er ókeypis. Hins vegar eru blæbrigði.

• Í fyrsta lagi er krafan um þekkingu og reynslu stjórnenda og verkfræðinga sem munu dreifa og styðja allt þetta. Þar sem viðskiptavinurinn fær algjört athafnafrelsi í klasanum ber hann sjálfur ábyrgð á frammistöðu klasans. Og það er mjög auðvelt að brjóta allt hér.
• Annað er skortur á samþættingum. Ef þú keyrir Kubernetes án vinsæls sýndarvæðingarvettvangs færðu ekki allan ávinninginn af forritinu. Svo sem eins og að nota stöðugt magn og álagsjafnvægisþjónustu.

Mynd 2. k8s arkitektúr

Kubernetes frá seljanda

Samþætting við skýjaþjónustu veitir tvo valkosti:

• Í fyrsta lagi getur einstaklingur einfaldlega smellt á „búa til klasa“ hnappinn og fengið klasa þegar stilltan og tilbúinn til notkunar.
• Í öðru lagi setur söluaðilinn sjálfur upp klasann og setur upp samþættingu við skýið.

Hvernig það gerist hér. Verkfræðingurinn sem ræsir klasann tilgreinir hversu marga starfsmenn hann þarf og með hvaða breytum (til dæmis 5 starfsmenn, hver með 10 örgjörva, 16 GB af vinnsluminni og til dæmis 100 GB af diski). Eftir það fær það aðgang að þegar myndaðri þyrpingunni. Í þessu tilviki eru starfsmenn sem hleðslan er sett af stað alfarið fluttir til viðskiptavinarins, en allt stjórnunarplanið er áfram á ábyrgð seljanda (ef þjónustan er veitt í samræmi við stýrða þjónustulíkanið).

Hins vegar hefur þetta kerfi sína galla. Vegna þess að stjórnunarplanið er áfram hjá seljanda veitir lánardrottinn ekki fullan aðgang að viðskiptavininum og það dregur úr sveigjanleika í að vinna með Kubernetes. Stundum gerist það að viðskiptavinur vill bæta einhverjum ákveðinni virkni við Kubernetes, til dæmis auðkenningu í gegnum LDAP, en uppsetning stjórnunarplans leyfir það ekki.

Mynd 3. Dæmi um Kubernetes þyrping frá skýjaveitu

Hvað á að velja: opinn uppspretta eða söluaðili

Svo, er Kubernetes opinn uppspretta eða söluaðili sérstakur? Ef við tökum opinn Kubernetes, þá gerir notandinn það sem hann vill með það. En það eru miklar líkur á að skjóta sig í fótinn. Hjá seljanda er þetta erfiðara, því allt er úthugsað og stillt fyrir fyrirtækið. Stærsti ókosturinn við opinn uppspretta Kubernetes er krafan um sérfræðinga. Með valkosti seljanda losnar fyrirtækið við þennan höfuðverk, en það verður að ákveða hvort það eigi að borga sérfræðingum sínum eða seljanda.

Jæja, kostir eru augljósir, gallarnir eru líka þekktir. Eitt er stöðugt: Kubernetes leysir mörg vandamál með því að gera sjálfvirka stjórnun margra gáma. Og hvern á að velja, opinn uppspretta eða söluaðila - hver og einn tekur sína eigin ákvörðun.

Greinin var unnin af Dmitry Krasnov, leiðandi arkitekt Containerum þjónustunnar #CloudMTS veitunnar

Heimild: www.habr.com