Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?

PiezÄ«me. tulk.: Å”is materiāls ir no izglÄ«tojoÅ”a projekta mācÄ«ties8s ir atbilde uz populāru jautājumu, projektējot uz Kubernetes balstÄ«tu infrastruktÅ«ru. Mēs ceram, ka diezgan detalizēts katras iespējas plusu un mÄ«nusu apraksts palÄ«dzēs jums izdarÄ«t labāko izvēli jÅ«su projektam.

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?

TL; DR: vienu un to paŔu darba slodžu kopu var palaist vairākos lielos klasteros (katram klasterim būs liels slodžu skaits) vai daudzās mazās (ar nelielu slodžu skaitu katrā klasterī).

Tālāk ir sniegta tabula, kurā novērtēti katras pieejas plusi un mīnusi:

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?

Izmantojot Kubernetes kā platformu lietojumprogrammu palaiŔanai, bieži rodas vairāki būtiski jautājumi par klasteru iestatīŔanas sarežģītību:

  • Cik kopu man vajadzētu izmantot?
  • Cik lielas man tās padarÄ«t?
  • Kas jāiekļauj katrā klasterÄ«?

Å ajā rakstā es mēģināŔu atbildēt uz visiem Å”iem jautājumiem, analizējot katras pieejas plusus un mÄ«nusus.

Jautājuma paziņojums

Kā programmatūras izstrādātājs jūs, iespējams, izstrādājat un izmantojat daudzas lietojumprogrammas vienlaikus.

Turklāt daudzi Å”o lietojumprogrammu gadÄ«jumi, iespējams, darbosies dažādās vidēs, piemēram, tās var bÅ«t dev, pārbaude Šø prod.

Rezultāts ir vesela lietojumprogrammu un vidi matrica:

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
Lietojumprogrammas un vide

IepriekÅ” minētajā piemērā ir attēlotas 3 lietojumprogrammas un 3 vides, kā rezultātā kopā ir 9 iespējamās opcijas.

Katrs lietojumprogrammas gadījums ir autonoma izvietoŔanas vienība, ar kuru var strādāt neatkarīgi no citiem.

LÅ«dzu, ņemiet vērā, ka lietojumprogrammas gadÄ«jums var sastāvēt no daudziem komponenti, piemēram, priekÅ”gals, aizmugursistēma, datubāze utt. Mikropakalpojumu lietojumprogrammas gadÄ«jumā instancē tiks iekļauti visi mikropakalpojumi.

Tā rezultātā Kubernetes lietotājiem ir vairāki jautājumi:

  • Vai visas lietojumprogrammas ir jāievieto vienā klasterÄ«?
  • Vai ir vērts izveidot atseviŔķu klasteru katrai lietojumprogrammas instancei?
  • Vai varbÅ«t ir jāizmanto iepriekÅ” minēto pieeju kombinācija?

Visas Ŕīs iespējas ir diezgan dzÄ«votspējÄ«gas, jo Kubernetes ir elastÄ«ga sistēma, kas neierobežo lietotāja iespējas.

Šeit ir daži no iespējamiem veidiem:

  • viens liels kopÄ«gs klasteris;
  • daudzas mazas augsti specializētas kopas;
  • viena klastera uz vienu pieteikumu;
  • viens klasteris katrā vidē.

Kā parādīts zemāk, pirmās divas pieejas atrodas opciju skalas pretējos galos.

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
No dažām lielām kopām (pa kreisi) līdz daudzām mazām kopām (pa labi)

Kopumā viens klasteris tiek uzskatÄ«ts par ā€œlielākuā€ par citu, ja tajā ir lielāks mezglu un pākstu skaits. Piemēram, klasteris ar 10 mezgliem un 100 pākstiem ir lielāks nekā klasteris ar 1 mezglu un 10 pākstiem.

Nu ko, sāksim!

1. Viens liels kopīgs klasteris

Pirmā iespēja ir visas darba slodzes ievietot vienā klasterī:

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
Viens liels klasteris

Å Ä«s pieejas ietvaros klasteris tiek izmantots kā universāls infrastruktÅ«ras platforma ā€” jÅ«s vienkārÅ”i izvietojat visu nepiecieÅ”amo esoÅ”ajā Kubernetes klasterÄ«.

Vārdtelpas Kubernetes ļauj loģiski atdalīt klastera daļas vienu no otras, lai katrai lietojumprogrammas instancei varētu būt sava nosaukumvieta.

Apskatīsim Ŕīs pieejas plusus un mīnusus.

+ Efektīva resursu izmantoŔana

Izmantojot vienu klasteru, jums ir nepiecieŔama tikai viena visu Kubernetes klastera palaiŔanai un pārvaldībai nepiecieŔamo resursu kopija.

Piemēram, tas attiecas uz galvenajiem mezgliem. Parasti katrā Kubernetes klasterÄ« ir 3 galvenie mezgli, tāpēc vienai klasterim to skaits paliks tāds (salÄ«dzinājumam 10 klasteriem bÅ«s nepiecieÅ”ami 30 galvenie mezgli).

IepriekÅ” minētais smalkums attiecas arÄ« uz citiem pakalpojumiem, kas darbojas visā klasterÄ«, piemēram, slodzes lÄ«dzsvarotājiem, ieejas kontrolleriem, autentifikācijas, reÄ£istrÄ“Å”anas un uzraudzÄ«bas sistēmām.

Vienā klasterÄ« visus Å”os pakalpojumus var izmantot vienlaikus visām darba slodzēm (nav nepiecieÅ”ams veidot to kopijas, kā tas ir vairāku klasteru gadÄ«jumā).

+ Lēti

IepriekÅ”minētā rezultātā mazāk klasteru parasti ir lētāki, jo nav pieskaitāmu izmaksu.

Tas jo Ä«paÅ”i attiecas uz galvenajiem mezgliem, kas var maksāt ievērojamu naudas summu neatkarÄ«gi no tā, kā tie tiek mitināti (uz vietas vai mākonÄ«).

Daži pārvaldÄ«ti Kubernetes pakalpojumi, piemēram, Google Kubernetes Engine (GKE) vai Azure Kubernetes pakalpojums (AKS), nodroÅ”ina kontroles slāni bez maksas. Å ajā gadÄ«jumā izmaksu problēma nav tik aktuāla.

Ir arī pārvaldīti pakalpojumi, kas iekasē fiksētu maksu par katra Kubernetes klastera darbību (piemēram, Amazon Elastic Kubernetes Service, EKS).

+ Efektīva administrēŔana

Pārvaldīt vienu klasteru ir vieglāk nekā pārvaldīt vairākus.

Administrācija var ietvert Ŕādus uzdevumus:

  • Kubernetes versijas atjauninājums;
  • CI/CD konveijera izveide;
  • CNI spraudņa instalÄ“Å”ana;
  • lietotāja autentifikācijas sistēmas uzstādÄ«Å”ana;
  • piekļuves kontroliera uzstādÄ«Å”ana;

un daudzi citiā€¦

Viena klastera gadījumā tas viss būs jādara tikai vienu reizi.

Daudzām kopām darbÄ«bas bÅ«s jāatkārto daudzas reizes, kas, iespējams, prasÄ«s zināmu procesu un rÄ«ku automatizāciju, lai nodroÅ”inātu procesa konsekvenci un konsekvenci.

Un tagad daži vārdi par mīnusiem.

āˆ’ Viens neveiksmes punkts

Atteikuma gadījumā vienīgais klasteris nekavējoties pārtrauks darboties viss darba slodzes!

Ir daudz veidu, kā lietas var noiet greizi:

  • Kubernetes atjaunināŔana izraisa negaidÄ«tas blakusparādÄ«bas;
  • Klastera mēroga komponents (piemēram, CNI spraudnis) sāk nedarboties, kā paredzēts;
  • viens no klastera komponentiem nav pareizi konfigurēts;
  • kļūme pamata infrastruktÅ«rā.

Viens Ŕāds incidents var radÄ«t nopietnus bojājumus visām darba slodzēm, kas tiek mitinātas koplietotā klasterÄ«.

āˆ’ Nav stingras izolācijas

DarboÅ”anās koplietotā klasterÄ« nozÄ«mē, ka lietojumprogrammas koplieto aparatÅ«ru, tÄ«kla iespējas un operētājsistēmu klastera mezglos.

Savā ziņā divi konteineri ar divām dažādām lietojumprogrammām, kas darbojas vienā mezglā, ir kā divi procesi, kas darbojas vienā un tajā paŔā maŔīnā, kurā darbojas viens un tas pats OS kodols.

Linux konteineri nodroÅ”ina zināmu izolāciju, taču tā nav tik spēcÄ«ga kā, piemēram, virtuālās maŔīnas. BÅ«tÄ«bā process konteinerā ir tas pats process, kas darbojas resursdatora operētājsistēmā.

Tas var bÅ«t droŔības problēma: Ŕī vienoÅ”anās teorētiski ļauj nesaistÄ«tām lietojumprogrammām sazināties savā starpā (tÄ«Å”i vai nejauÅ”i).

Turklāt visas Kubernetes klastera darba slodzes koplieto dažus klastera mēroga pakalpojumus, piemēram, DNS - tas ļauj lietojumprogrammām atrast citu klastera lietojumprogrammu pakalpojumus.

Visiem iepriekÅ”minētajiem punktiem var bÅ«t atŔķirÄ«ga nozÄ«me atkarÄ«bā no lietojumprogrammas droŔības prasÄ«bām.

Kubernetes nodroÅ”ina dažādus rÄ«kus, lai novērstu droŔības problēmas, piemēram, PodSecurityPolicies Šø TÄ«kla politikas. Tomēr, lai tos pareizi uzstādÄ«tu, ir nepiecieÅ”ama zināma pieredze, turklāt tie nespēj aizvērt pilnÄ«gi visus droŔības caurumus.

Ir svarÄ«gi vienmēr atcerēties, ka Kubernetes sākotnēji bija paredzēts dalÄ«Å”anās, nevis priekÅ” izolācija un droŔība.

āˆ’ Stingras vairāku Ä«res lÄ«gumu trÅ«kums

Ņemot vērā koplietojamo resursu pārpilnību Kubernetes klasterī, ir daudz veidu, kā dažādas lietojumprogrammas var iedarboties uz viena otrai.

Piemēram, lietojumprogramma var monopolizēt koplietotu resursu (piemēram, centrālo procesoru vai atmiņu) un liegt citām lietojumprogrammām, kas darbojas tajā paŔā mezglā, piekļuvi tam.

Kubernetes nodroÅ”ina dažādus mehānismus Ŕīs uzvedÄ«bas kontrolei, piemēram, resursu pieprasÄ«jumi un ierobežojumi (skatÄ«t arÄ« rakstu " CPU ierobežojumi un agresÄ«va droseles Kubernetes "- apm. tulk.), Resursu kvotas Šø LimitRanges. Tomēr, tāpat kā droŔības gadÄ«jumā, to konfigurācija ir diezgan nenozÄ«mÄ«ga un tie nespēj novērst absolÅ«ti visas neparedzamās blakusparādÄ«bas.

āˆ’ Liels lietotāju skaits

Viena klastera gadÄ«jumā jums ir jāatver piekļuve tai daudziem cilvēkiem. Un jo lielāks to skaits, jo lielāks risks, ka viņi kaut ko ā€œsalauzÄ«sā€.

KlasterÄ« varat kontrolēt, kurÅ” var ko izmantot uz lomu balstÄ«ta piekļuves kontrole (RBAC) (skat. rakstu " Lietotāji un autorizācijas RBAC vietnē Kubernetes "- apm. tulk.). Tomēr tas netraucēs lietotājiem kaut ko ā€œsalauztā€ viņu atbildÄ«bas jomā.

āˆ’ Kopas nevar augt bezgalÄ«gi

Visām darba slodzēm izmantotais klasteris, iespējams, būs diezgan liels (mezglu un podziņu skaita ziņā).

Bet Å”eit rodas cita problēma: klasteri Kubernetes nevar augt bezgalÄ«gi.

Klasteru izmēram ir teorētisks ierobežojums. Kubernetes ir aptuveni 5000 mezglu, 150 tÅ«kstoÅ”i pākstu un 300 tÅ«kstoÅ”i konteineru.

Tomēr reālajā dzīvē problēmas var sākties daudz agrāk - piemēram, tikai ar 500 mezgli.

Fakts ir tāds, ka lielas kopas rada lielu slodzi Kubernetes vadÄ«bas slānim. Citiem vārdiem sakot, lai nodroÅ”inātu klastera efektÄ«vu darbÄ«bu, ir nepiecieÅ”ama rÅ«pÄ«ga regulÄ“Å”ana.

Å Ä« problēma ir apskatÄ«ta saistÄ«tā rakstā sākotnējā emuārā ar nosaukumu "Kubernetes klasteru arhitektÅ«ra ā€” darbinieka mezgla izmēra izvēle'.

Bet padomāsim par pretējo pieeju: daudz mazu kopu.

2. Daudzas mazas, specializētas kopas

Izmantojot Ŕo pieeju, katram izvietojamajam elementam izmantojat atseviŔķu kopu.

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
Daudz mazu kopu

Å Ä« panta vajadzÄ«bām, saskaņā ar izvietojams elements attiecas uz lietojumprogrammas gadÄ«jumu, piemēram, atseviŔķas lietojumprogrammas izstrādātāju versiju.

Å Ä« stratēģija izmanto Kubernetes kā specializētu izpildlaiks atseviŔķiem lietojumprogrammu gadÄ«jumiem.

Apskatīsim Ŕīs pieejas plusus un mīnusus.

+ Ierobežots ā€œsprādziena rādiussā€

Ja klasteris neizdodas, negatÄ«vās sekas attiecas tikai uz tām darba slodzēm, kas tika izvietotas Å”ajā klasterÄ«. Visas pārējās darba slodzes paliek neskartas.

+ Izolācija

AtseviŔķos klasteros mitinātās darba slodzes neizmanto tādus resursus kā procesors, atmiņa, operētājsistēma, tÄ«kls vai citi pakalpojumi.

Rezultāts ir cieŔa izolācija starp nesaistītām lietojumprogrammām, kas var būt noderīga to droŔībai.

+ Neliels lietotāju skaits

Ņemot vērā, ka katrā klasterī ir tikai ierobežots darba slodžu kopums, tiek samazināts to lietotāju skaits, kuriem ir piekļuve tai.

Jo mazākam cilvēku skaitam ir piekļuve klasterim, jo ā€‹ā€‹mazāks ir risks, ka kaut kas ā€œsaplÄ«sÄ«sā€.

Apskatīsim mīnusus.

āˆ’ NeefektÄ«va resursu izmantoÅ”ana

Kā minēts iepriekÅ”, katram Kubernetes klasterim ir nepiecieÅ”ams noteikts pārvaldÄ«bas resursu kopums: galvenie mezgli, vadÄ«bas slāņa komponenti, uzraudzÄ«bas un reÄ£istrÄ“Å”anas risinājumi.

Liela skaita mazu klasteru gadījumā vadībai ir jāatvēl lielāka resursu daļa.

āˆ’ Dārgi

Neefektīva resursu izmantoŔana automātiski rada lielas izmaksas.

Piemēram, 30 galveno mezglu uzturÄ“Å”ana trÄ«s vietā ar vienādu skaitļoÅ”anas jaudu noteikti ietekmēs izmaksas.

āˆ’ GrÅ«tÄ«bas administrÄ“Å”anā

Vairāku Kubernetes klasteru pārvaldība ir daudz grūtāka nekā tikai viena.

Piemēram, jums būs jākonfigurē katra klastera autentifikācija un autorizācija. Vairākas reizes būs jāatjaunina arī Kubernetes versija.

Visticamāk, jums būs jāizmanto automatizācija, lai padarītu visus Ŕos uzdevumus efektīvākus.

Tagad apskatīsim mazāk ekstrēmus scenārijus.

3. Viena klastera katrai lietojumprogrammai

Izmantojot Å”o pieeju, jÅ«s izveidojat atseviŔķu kopu visiem konkrētas lietojumprogrammas gadÄ«jumiem.

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
Klasteris katrai lietojumprogrammai

Å o ceļu var uzskatÄ«t par principa "vispārinājumu"atseviŔķs klasteris katrai komandaiā€, jo parasti inženieru komanda izstrādā vienu vai vairākas lietojumprogrammas.

Apskatīsim Ŕīs pieejas plusus un mīnusus.

+ Klasteru var pielāgot lietojumprogrammai

Ja lietojumprogrammai ir Ä«paÅ”as vajadzÄ«bas, tās var ieviest klasterÄ«, neietekmējot citas kopas.

Šādas vajadzības var ietvert GPU darbiniekus, noteiktus CNI spraudņus, pakalpojumu tīklu vai kādu citu pakalpojumu.

Katru klasteru var pielāgot tajā esoŔajai lietojumprogrammai, lai tajā būtu tikai tas, kas ir nepiecieŔams.

āˆ’ Dažādas vides vienā klasterÄ«

Šīs pieejas trūkums ir tāds, ka lietojumprogrammu gadījumi no dažādām vidēm līdzāspastāv vienā klasterī.

Piemēram, lietojumprogrammas prod versija darbojas tajā paŔā klasterÄ«, kur izstrādātāja versija. Tas nozÄ«mē arÄ« to, ka izstrādātāji darbojas tajā paŔā klasterÄ«, kurā tiek darbināta lietojumprogrammas ražoÅ”anas versija.

Ja izstrādātāju darbÄ«bas vai izstrādātāja versijas kļūmju dēļ klasterÄ« rodas kļūme, tad potenciāli var ciest arÄ« prod versija - milzÄ«gs Ŕīs pieejas trÅ«kums.

Un visbeidzot, pēdējais scenārijs mūsu sarakstā.

4. Viens klasteris katrā vidē

Šis scenārijs paredz atseviŔķas kopas pieŔķirŔanu katrai videi:

Kubernetes klasteru projektÄ“Å”ana: cik daudz to vajadzētu bÅ«t?
Viens klasteris katrā vidē

Piemēram, jums var bÅ«t kopas dev, pārbaude Šø prod, kurā jÅ«s darbināsit visus konkrētai videi veltÄ«tas lietojumprogrammas gadÄ«jumus.

Šeit ir Ŕīs pieejas plusi un mīnusi.

+ Prod vides izolācija

Izmantojot Å”o pieeju, visas vides ir izolētas viena no otras. Tomēr praksē tas ir Ä«paÅ”i svarÄ«gi ražoÅ”anas vidē.

Lietojumprogrammas ražoÅ”anas versijas tagad ir neatkarÄ«gas no tā, kas notiek citos klasteros un vidēs.

Tādā veidā, ja izstrādātāju klasterÄ« pēkŔņi rodas problēma, lietojumprogrammu prod versijas turpinās darboties tā, it kā nekas nebÅ«tu noticis.

+ Klasteru var pielāgot videi

Katru klasteru var pielāgot savai videi. Piemēram, varat:

  • instalējiet rÄ«kus izstrādei un atkļūdoÅ”anai izstrādātāju klasterÄ«;
  • instalējiet testu ietvarus un rÄ«kus klasterÄ« pārbaude;
  • klasterÄ« izmantojiet jaudÄ«gāku aparatÅ«ru un tÄ«kla kanālus prod.

Tas ļauj palielināt gan lietojumprogrammu izstrādes, gan darbības efektivitāti.

+ Piekļuves ierobežoŔana ražoŔanas klasterim

NepiecieÅ”amÄ«ba strādāt tieÅ”i ar produktu kopu rodas reti, tāpēc jÅ«s varat ievērojami ierobežot to cilvēku loku, kuriem tas ir pieejams.

Varat iet vēl tālāk un pilnÄ«bā liegt cilvēkiem piekļuvi Å”im klasterim un veikt visas izvietoÅ”anas, izmantojot automatizētu CI/CD rÄ«ku. Šāda pieeja samazinās cilvēku kļūdu risku tieÅ”i tur, kur tā ir visatbilstoŔākā.

Un tagad daži vārdi par mīnusiem.

āˆ’ Nav izolācijas starp lietojumiem

Galvenais pieejas trūkums ir aparatūras un resursu izolācijas trūkums starp lietojumprogrammām.

Nesaistītās lietojumprogrammas koplieto klastera resursus: sistēmas kodolu, procesoru, atmiņu un dažus citus pakalpojumus.

Kā minēts, tas var būt potenciāli bīstami.

āˆ’ Nespēja lokalizēt lietojumprogrammu atkarÄ«bas

Ja lietojumprogrammai ir īpaŔas prasības, tās ir jāizpilda visās kopās.

Piemēram, ja lietojumprogrammai ir nepiecieÅ”ams GPU, katrā klasterÄ« ir jābÅ«t vismaz vienam darbiniekam ar GPU (pat ja to izmanto tikai Ŕī lietojumprogramma).

Rezultātā mēs riskējam ar lielākām izmaksām un neefektÄ«vu resursu izmantoÅ”anu.

Secinājums

Ja jums ir noteikts lietojumprogrammu komplekts, tās var ievietot vairākos lielos klasteros vai daudzos mazos.

Rakstā aplūkoti dažādu pieeju plusi un mīnusi, sākot no viena globāla klastera līdz vairākiem maziem un ļoti specializētiem klasteriem:

  • viena liela vispārējā kopa;
  • daudzas mazas augsti specializētas kopas;
  • viena klastera uz vienu pieteikumu;
  • viens klasteris katrā vidē.

Tātad, kāda pieeja jums būtu jāizmanto?

Kā vienmēr, atbilde ir atkarÄ«ga no lietoÅ”anas gadÄ«juma: jums ir jāizsver dažādu pieeju plusi un mÄ«nusi un jāizvēlas optimālākais variants.

Tomēr izvēle neaprobežojas tikai ar iepriekÅ” minētajiem piemēriem ā€“ varat izmantot jebkuru to kombināciju!

Piemēram, katrai komandai varat organizēt pāris klasterus: izstrādes klasteri (kurā bÅ«s vides dev Šø pārbaude) un klasteris priekÅ” ražoÅ”ana (kur atradÄ«sies ražoÅ”anas vide).

Pamatojoties uz Å”ajā rakstā sniegto informāciju, varat atbilstoÅ”i optimizēt plusus un mÄ«nusus konkrētam scenārijam. Veiksmi!

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru