Pastaba. vert.: ši medžiaga yra iš edukacinio projekto yra atsakymas į populiarų klausimą kuriant Kubernetes paremtą infrastruktūrą. Tikimės, kad gana išsamus kiekvienos parinkties privalumų ir trūkumų aprašymas padės jums pasirinkti geriausią jūsų projekto pasirinkimą.
Lt; DR: tą patį darbo krūvių rinkinį galima paleisti keliuose dideliuose klasteriuose (kiekviename klasteryje bus daug darbo krūvių) arba daugelyje mažų (kiekviename klasteryje esant nedideliam krūvių skaičiui).
Žemiau yra lentelė, kurioje įvertinami kiekvieno požiūrio privalumai ir trūkumai:
Naudojant Kubernetes kaip platformą programoms paleisti, dažnai kyla keletas esminių klausimų apie klasterių nustatymo sudėtingumą:
- Kiek grupių turėčiau naudoti?
- Kokio dydžio turėčiau juos padaryti?
- Ką turėtų sudaryti kiekvienas klasteris?
Šiame straipsnyje pabandysiu atsakyti į visus šiuos klausimus, analizuodamas kiekvieno požiūrio privalumus ir trūkumus.
Klausimo pareiškimas
Kaip programinės įrangos kūrėjas greičiausiai kuriate ir naudojate daug programų vienu metu.
Be to, daugelis šių programų egzempliorių greičiausiai veiks skirtingose aplinkose – pavyzdžiui, tai gali būti dev, testas и prod.
Rezultatas yra visa programų ir aplinkų matrica:
Programos ir aplinkos
Aukščiau pateiktame pavyzdyje pateikiamos 3 programos ir 3 aplinkos, todėl iš viso yra 9 galimos parinktys.
Kiekvienas programos egzempliorius yra savarankiškas diegimo vienetas, su kuriuo galima dirbti nepriklausomai nuo kitų.
Atkreipkite dėmesį, kad programos pavyzdys gali susidėti iš daugelio komponentai, pvz., frontend, backend, duomenų bazė ir kt. Mikropaslaugų programos atveju egzempliorius apims visas mikropaslaugas.
Dėl to Kubernetes naudotojai turi keletą klausimų:
- Ar visi programos egzemplioriai turi būti sudėti į vieną grupę?
- Ar verta turėti atskirą klasterį kiekvienam programos egzemplioriui?
- O gal reikėtų naudoti pirmiau minėtų metodų derinį?
Visos šios parinktys yra gana perspektyvios, nes „Kubernetes“ yra lanksti sistema, neribojanti vartotojo galimybių.
Štai keletas galimų būdų:
- vienas didelis bendras klasteris;
- daug mažų labai specializuotų grupių;
- viena klasteris vienai programai;
- po vieną klasterį aplinkai.
Kaip parodyta toliau, pirmieji du metodai yra priešinguose variantų skalės galuose:
Nuo kelių didelių grupių (kairėje) iki daugybės mažų (dešinėje)
Apskritai vienas klasteris laikomas „didesniu“ už kitą, jei joje yra didesnė mazgų ir ankščių suma. Pavyzdžiui, klasteris su 10 mazgų ir 100 ankščių yra didesnis nei klasteris su 1 mazgu ir 10 ankščių.
Na, pradėkime!
1. Vienas didelis bendras klasteris
Pirmoji parinktis – visus darbo krūvius sudėti į vieną klasterį:
Vienas didelis klasteris
Taikant šį metodą, klasteris naudojamas kaip universalus infrastruktūros platforma - jūs tiesiog įdiegiate viską, ko jums reikia esamame „Kubernetes“ klasteryje.
„Kubernetes“ leidžia logiškai atskirti klasterio dalis viena nuo kitos, kad kiekvienas programos egzempliorius galėtų turėti savo vardų erdvę.
Pažvelkime į šio požiūrio privalumus ir trūkumus.
+ Efektyvus išteklių naudojimas
Naudojant vieną klasterį, jums reikia tik vienos visų išteklių, reikalingų Kubernetes klasteriui paleisti ir valdyti, kopijos.
Pavyzdžiui, tai pasakytina apie pagrindinius mazgus. Paprastai kiekviena Kubernetes klasteris turi 3 pagrindinius mazgus, todėl vienai klasteriui jų skaičius išliks toks (palyginimui, 10 grupių reikės 30 pagrindinių mazgų).
Aukščiau pateiktas subtilumas taip pat taikomas kitoms paslaugoms, veikiančioms visame klasteryje, pvz., apkrovos balansavimo įrenginius, įėjimo valdiklius, autentifikavimo, registravimo ir stebėjimo sistemas.
Viename klasteryje visos šios paslaugos gali būti naudojamos vienu metu visiems darbo krūviams (nereikia kurti jų kopijų, kaip tai daroma kelių grupių atveju).
+ Pigu
Dėl to, kas išdėstyta pirmiau, mažiau grupių paprastai yra pigesnės, nes nėra jokių pridėtinių išlaidų.
Tai ypač pasakytina apie pagrindinius mazgus, kurie gali kainuoti daug pinigų, neatsižvelgiant į tai, kaip jie yra priglobti (vietinėje ar debesyje).
Kai kurios valdomos Kubernetes paslaugos, pvz arba , nemokamai pateikite valdymo sluoksnį. Šiuo atveju išlaidų problema yra ne tokia opi.
Taip pat yra valdomų paslaugų, kurios ima fiksuotą mokestį už kiekvieno „Kubernetes“ klasterio veikimą (pvz., ).
+ Efektyvus administravimas
Vieną klasterį valdyti lengviau nei kelis.
Administravimas gali apimti šias užduotis:
- Kubernetes versijos atnaujinimas;
- CI/CD konvejerio nustatymas;
- įdiegti CNI papildinį;
- vartotojo autentifikavimo sistemos nustatymas;
- prieigos valdiklio įrengimas;
ir daugelis kitų…
Vieno klasterio atveju visa tai turėsite atlikti tik vieną kartą.
Daugelyje grupių operacijos turės būti kartojamos daug kartų, todėl greičiausiai reikės šiek tiek automatizuoti procesus ir įrankius, kad būtų užtikrintas proceso nuoseklumas ir nuoseklumas.
O dabar keli žodžiai apie minusus.
− Vienas gedimo taškas
Atsisakymo atveju vienintelė klasteris iš karto nustos veikti visi darbo krūviai!
Yra daug būdų, kaip viskas gali suklysti:
- Kubernetes atnaujinimas sukelia netikėtų šalutinių poveikių;
- Visos grupės komponentas (pavyzdžiui, CNI įskiepis) pradeda neveikti taip, kaip tikėtasi;
- vienas iš klasterio komponentų nėra tinkamai sukonfigūruotas;
- pagrindinės infrastruktūros gedimas.
Vienas iš tokių incidentų gali sukelti rimtą žalą visiems darbo krūviams, esantiems bendrame klasteryje.
− Nėra standžios izoliacijos
Veikimas bendrame klasteryje reiškia, kad programos dalijasi aparatūra, tinklo galimybėmis ir operacine sistema klasterio mazguose.
Tam tikra prasme du konteineriai su dviem skirtingomis programomis, veikiančiomis tame pačiame mazge, yra kaip du procesai, veikiantys tame pačiame kompiuteryje, kuriame veikia tas pats OS branduolys.
„Linux“ konteineriai suteikia tam tikros formos izoliaciją, tačiau ji nėra tokia stipri, kaip, tarkime, virtualios mašinos. Iš esmės procesas konteineryje yra tas pats procesas, vykdomas pagrindinio kompiuterio operacinėje sistemoje.
Tai gali būti saugumo problema: toks susitarimas teoriškai leidžia nesusijusioms programoms bendrauti tarpusavyje (tyčia ar netyčia).
Be to, visi „Kubernetes“ klasterio darbo krūviai dalijasi kai kuriomis klasterio paslaugomis, pvz., - tai leidžia programoms rasti kitų klasteryje esančių programų paslaugas.
Visi aukščiau pateikti punktai gali turėti skirtingą reikšmę, atsižvelgiant į programos saugos reikalavimus.
„Kubernetes“ teikia įvairius įrankius, padedančius išvengti saugumo problemų, tokių kaip и . Tačiau teisingai juos nustatyti reikia tam tikros patirties, be to, jie negali uždaryti absoliučiai visų saugumo spragų.
Svarbu visada atsiminti, kad „Kubernetes“ iš pradžių buvo sukurta dalijimasis, ne dėl izoliacija ir saugumas.
− Griežtos daugiabučio nuomos nebuvimas
Atsižvelgiant į tai, kad „Kubernetes“ klasteryje yra daug bendrinamų išteklių, yra daug būdų, kaip skirtingos programos gali užpulti viena kitai.
Pavyzdžiui, programa gali monopolizuoti bendrinamus išteklius (pvz., procesorių arba atmintį) ir neleisti prieiti prie jo kitoms programoms, veikiančioms tame pačiame mazge.
„Kubernetes“ pateikia įvairius šio elgesio kontrolės mechanizmus, pvz (taip pat žiūrėkite straipsnį "“ – apytiksliai. vertimas.), и . Tačiau, kaip ir saugumo atveju, jų konfigūracija yra gana nebanali ir jie nesugeba išvengti absoliučiai visų nenumatytų šalutinių poveikių.
− Didelis vartotojų skaičius
Vieno klasterio atveju turite atverti prieigą prie jo daugeliui žmonių. Ir kuo didesnis jų skaičius, tuo didesnė rizika, kad jie ką nors „sulaužys“.
Grupėje galite valdyti, kas ką gali daryti (žr. straipsnį "“ – apytiksliai. vertimas.). Tačiau tai netrukdys vartotojams kažko „sulaužyti“ savo atsakomybės ribose.
− Klasteriai negali augti neribotą laiką
Klasteris, kuris naudojamas visiems darbo krūviams, greičiausiai bus gana didelis (pagal mazgų ir podelių skaičių).
Tačiau čia iškyla kita problema: Kubernetes klasteriai negali augti neribotą laiką.
Yra teorinis klasterio dydžio apribojimas. Kubernetes yra maždaug .
Tačiau realiame gyvenime problemos gali prasidėti daug anksčiau – pavyzdžiui, tiesiog su .
Faktas yra tas, kad dideli klasteriai kelia didelę apkrovą Kubernetes valdymo sluoksniui. Kitaip tariant, norint, kad klasteris veiktų ir veiktų efektyviai, reikia kruopštaus derinimo.
Ši problema nagrinėjama susijusiame straipsnyje apie pradinį tinklaraštį pavadinimu "".
Tačiau apsvarstykime priešingą požiūrį: daug mažų grupių.
2. Daug mažų specializuotų grupių
Taikydami šį metodą, kiekvienam įdiegtam elementui naudojate atskirą klasterį:
Daug mažų grupių
Šio straipsnio tikslais pagal dislokuojamas elementas nurodo programos egzempliorių, pavyzdžiui, atskiros programos dev versiją.
Ši strategija naudoja Kubernetes kaip specializuotą vykdymo laikas individualiems taikymo atvejams.
Pažvelkime į šio požiūrio privalumus ir trūkumus.
+ Ribotas „sprogimo spindulys“
Kai klasteris sugenda, neigiamos pasekmės apsiriboja tik tais darbo krūviais, kurie buvo įdiegti tame klasteryje. Visi kiti darbo krūviai lieka nepakitę.
+ Izoliacija
Darbo krūviai, priglobti atskirose grupėse, nesidalija ištekliais, tokiais kaip procesorius, atmintis, operacinė sistema, tinklas ar kitos paslaugos.
Rezultatas yra griežta nesusijusių programų izoliacija, o tai gali būti naudinga jų saugumui.
+ Mažas vartotojų skaičius
Atsižvelgiant į tai, kad kiekviename klasteryje yra tik ribotas darbo krūvių rinkinys, vartotojų, turinčių prieigą prie jo, skaičius sumažėja.
Kuo mažiau žmonių turi prieigą prie klasterio, tuo mažesnė rizika, kad kažkas „suges“.
Pažvelkime į minusus.
− Neefektyvus išteklių naudojimas
Kaip minėta anksčiau, kiekvienam Kubernetes klasteriui reikalingas tam tikras valdymo išteklių rinkinys: pagrindiniai mazgai, valdymo sluoksnio komponentai, stebėjimo ir registravimo sprendimai.
Esant dideliam mažų klasterių skaičiui, valdymui turi būti skirta didesnė išteklių dalis.
− Brangus
Neefektyvus išteklių naudojimas automatiškai sukelia dideles išlaidas.
Pavyzdžiui, išlaikant 30 pagrindinių mazgų, o ne tris, turinčius tą pačią skaičiavimo galią, būtinai turės įtakos išlaidoms.
− administravimo sunkumai
Valdyti kelis „Kubernetes“ grupes yra daug sunkiau nei valdyti tik vieną.
Pavyzdžiui, turėsite sukonfigūruoti kiekvieno klasterio autentifikavimą ir įgaliojimą. Kelis kartus teks atnaujinti ir „Kubernetes“ versiją.
Tikriausiai turėsite naudoti automatizavimą, kad visos šios užduotys būtų efektyvesnės.
Dabar pažvelkime į ne tokius ekstremalius scenarijus.
3. Vienai programai viena grupė
Taikydami šį metodą, sukuriate atskirą klasterį visiems konkrečios programos egzemplioriams:
Klasteris vienai programai
Šis kelias gali būti laikomas principo „apibendrinimas“atskiras klasteris kiekvienai komandai“, nes paprastai inžinierių komanda kuria vieną ar kelias programas.
Pažvelkime į šio požiūrio privalumus ir trūkumus.
+ Klasterį galima pritaikyti prie programos
Jei programa turi specialių poreikių, juos galima įdiegti grupėje, nepažeidžiant kitų grupių.
Tokie poreikiai gali apimti GPU darbuotojus, tam tikrus CNI papildinius, paslaugų tinklą ar kitą paslaugą.
Kiekvieną klasterį galima pritaikyti joje veikiančiai programai, kad joje būtų tik tai, ko reikia.
− Skirtingos aplinkos viename klasteryje
Šio metodo trūkumas yra tas, kad programų egzemplioriai iš skirtingų aplinkų egzistuoja tame pačiame klasteryje.
Pavyzdžiui, programos prod versija veikia tame pačiame klasteryje kaip ir kūrėjo versija. Tai taip pat reiškia, kad kūrėjai veikia tame pačiame klasteryje, kuriame veikia gamybinė programos versija.
Jei dėl kūrėjų veiksmų ar dev versijos gedimų klasteryje įvyksta gedimas, gali nukentėti ir prod versija – didžiulis šio požiūrio trūkumas.
Ir galiausiai paskutinis scenarijus mūsų sąraše.
4. Vienas klasteris vienoje aplinkoje
Šis scenarijus apima atskiro klasterio paskyrimą kiekvienai aplinkai:
Vienas klasteris vienoje aplinkoje
Pavyzdžiui, galite turėti grupes dev, testas и prod, kuriame paleisite visus programos egzempliorius, skirtus konkrečiai aplinkai.
Štai šio požiūrio privalumai ir trūkumai.
+ Gamybos aplinkos izoliavimas
Taikant šį metodą, visos aplinkos yra izoliuotos viena nuo kitos. Tačiau praktiškai tai ypač svarbu gaminio aplinkoje.
Gamybinės programos versijos dabar nepriklauso nuo to, kas vyksta kitose grupėse ir aplinkose.
Tokiu būdu, jei kūrėjų klasteryje staiga iškyla problema, programų prod versijos ir toliau veiks taip, lyg nieko nebūtų nutikę.
+ Klasterį galima pritaikyti prie aplinkos
Kiekvieną klasterį galima pritaikyti prie aplinkos. Pavyzdžiui, galite:
- įdiegti kūrimo ir derinimo įrankius kūrėjų klasteryje;
- į klasterį įdiekite bandymo sistemas ir įrankius testas;
- klasteryje naudokite galingesnę aparatinę įrangą ir tinklo kanalus prod.
Tai leidžia padidinti programų kūrimo ir veikimo efektyvumą.
+ Prieigos prie gamybos klasterio ribojimas
Poreikis dirbti tiesiogiai su produktų grupe iškyla retai, todėl galite žymiai apriboti žmonių, turinčių prieigą prie jo, ratą.
Galite eiti dar toliau ir visiškai neleisti žmonėms pasiekti šios grupės ir atlikti visus diegimus naudodami automatinį CI / CD įrankį. Toks požiūris sumažins žmogiškųjų klaidų riziką būtent ten, kur tai yra aktualiausia.
O dabar keli žodžiai apie minusus.
− Nėra izoliacijos tarp programų
Pagrindinis metodo trūkumas yra aparatinės įrangos ir išteklių izoliacijos tarp programų trūkumas.
Nesusijusios programos dalijasi klasterio ištekliais: sistemos branduoliu, procesoriumi, atmintimi ir kai kuriomis kitomis paslaugomis.
Kaip minėta, tai gali būti potencialiai pavojinga.
− Nesugebėjimas lokalizuoti taikomųjų programų priklausomybių
Jei programai keliami specialūs reikalavimai, jie turi būti tenkinami visose grupėse.
Pavyzdžiui, jei programai reikalingas GPU, kiekviename klasteryje turi būti bent vienas darbuotojas su GPU (net jei jį naudoja tik ta programa).
Dėl to rizikuojame didesnėmis sąnaudomis ir neefektyviu išteklių naudojimu.
išvada
Jei turite tam tikrą programų rinkinį, jas galite sudėti į kelias dideles arba daug mažų grupių.
Straipsnyje aptariami įvairių metodų privalumai ir trūkumai – nuo vieno pasaulinio klasterio iki kelių mažų ir labai specializuotų:
- vienas didelis bendras klasteris;
- daug mažų labai specializuotų grupių;
- viena klasteris vienai programai;
- po vieną klasterį aplinkai.
Taigi kokio požiūrio turėtumėte pasirinkti?
Kaip visada, atsakymas priklauso nuo naudojimo atvejo: reikia pasverti skirtingų metodų privalumus ir trūkumus ir pasirinkti optimaliausią variantą.
Tačiau pasirinkimas neapsiriboja aukščiau pateiktais pavyzdžiais – galite naudoti bet kokį jų derinį!
Pavyzdžiui, kiekvienai komandai galite suorganizuoti keletą grupių: kūrimo klasterį (kuriame bus aplinkos dev и testas) ir klasterį, skirtą gamyba (kur bus gamybos aplinka).
Remdamiesi šiame straipsnyje pateikta informacija, galite atitinkamai optimizuoti konkretaus scenarijaus privalumus ir trūkumus. Sėkmės!
PS
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com
