Shën. përk.: ky ky material nga projekti arsimor — përgjigje për një pyetje të njohur gjatë projektimit të infrastrukturës mbi Kubernetes. Shpresojmë që përshkrimet e detajuara të përfitimeve dhe disavantazheve të secilit opsion të ndihmojnë në zgjedhjen më optimale për projektin tuaj.
TL;DR: i njëjti set ngarkesash mund të niset në disa klastera të mëdhenj (ku secili klaster do të ketë një numër të madh ngarkesash) ose në shumë të vogla (me një numër të vogël ngarkesash në secilin klaster).
Më poshtë është një tabelë që vlerëson përfitimet dhe disavantazhet e secilit qasje:
Kur përdoret Kubernetes si një platformë për funksionimin e aplikacioneve, shpesh lindin disa pyetje themelore në lidhje me nuancat e konfigurimit të klasterëve:
- Sa klastera të përdorim?
- Sa të mëdha duhet të jenë?
- Çfarë duhet të përmbajë secili klaster?
Në këtë artikull do të përpiqem të përgjigjem në të gjitha këto pyetje duke analizuar përfitimet dhe disavantazhet e çdo qasjeje.
Formulimi i pyetjes
Si krijues i softuerit, ju me siguri jeni duke zhvilluar dhe funksionuar paralelisht shumë aplikacione.
Për më tepër, shumë instanca të këtyre aplikacioneve do të lançohet me siguri në ambiente të ndryshme — për shembull, mund të jenë dev, test dhe prod.
Si rezultat, krijohet një matrice e tërë e aplikacioneve dhe ambienteve:
Aplikacione dhe ambiente
Në shembullin e mësipërm paraqiten 3 aplikacione dhe 3 ambiente, që në fund japin 9 variante të mundshme.
Çdo instancë e aplikacionit paraqet një njësinë të plotë të kërkesës, me të cilën mund të punoni e pavarur nga të tjerat.
Merrni parasysh se instancë e aplikacionit mund të përbëhet nga shumë komponentë, si frontend, backend, baza e të dhënave etj. Në rastin e një aplikacioni mikrosherivor, instanca do të përfshijë të gjitha mikrosherivoro.
Si rezultat, përdoruesit e Kubernetes kanë disa pyetje:
- A duhet të vendosim të gjitha instancat e aplikacionit në një klaster?
- A duhet të krijojmë një klaster të veçantë për secilën instancë aplikacioni?
- Ose, ndoshta, duhet të përdorim një kombinim të qasjeve të lartpërmendura?
Të gjitha këto variante janë të mundshme, pasi Kubernetes është një sistem fleksibël që nuk e kufizon përdoruesin në mundësi.
Ja disa nga rrugët e mundshme:
- një klaster të madh të përbashkët;
- mijëra klastera të vegjël me specializim të ngushtë;
- një klaster për secilin aplikacion;
- një klaster për çdo ambient.
Siç tregohet më poshtë, dy qasjet e para janë në poles të kundërta të shkallës së opsioneve:
Nga disa klastera të mëdha (majtas) deri në shumë të vogla (djathtas)
Në përgjithësi, besohet se një klaster është 'më i madh' se tjetri nëse ka më shumë somë nyjash dhe podesh. Për shembull, një klaster me 10 nyja dhe 100 podë është më i madh se një klaster me 1 nyje dhe 10 podë.
Mirë, le të fillojmë!
1. Një klaster i madh të përbashkët
Opsioni i parë është të vendosni të gjitha ngarkesat në një klaster:
Një klaster i madh
Brenda këtij qasje, klasteri përdoret si një platformë infrastrukturore universale — gjithçka që ju nevojitet është thjesht të hapni në klasterin ekzistues Kubernetes.
Kubernetes lejon që pjesët e klasterit të ndahen logjikisht nga njëra-tjetra, në mënyrë që për çdo instancë aplikacioni mund të përdoret hapësira e saj emërore.
Le të shqyrtojmë përfitimet dhe disavantazhet e kësaj qasje.
+ Përdorim efektiv të burimeve
Në rastin e një klasteri të vetëm, kërkohet vetëm një kopje e të gjitha burimeve të nevojshme për të funksionuar dhe menaxhuar klasterin Kubernetes.
Për shembull, kjo është e vërtetë për nyjat kryesore. Në përgjithësi, për çdo klaster Kubernetes ka 3 nyja kryesore, kështu që për një klaster të vetëm, numri mbetet i tillë (për krahasim, 10 klastera do të kërkonin 30 nyja kryesore).
Kjo nuancë vlen edhe për shërbimet e tjera që funksionojnë në nivel klasteri, si balancuesit e ngarkesës, kontrollorët Ingress, sistemet e autentikimit, regjistrimit dhe monitorimit.
Në një klaster të vetëm, të gjitha këto shërbime mund të përdoren të gjitha për ngarkesat e punës (nuk është e nevojshme të krijoni kopje të tyre, si në rastin e disa klasterëve).
+ Shkalla
Si pasojë e lartpërmendur, numri më i vogël i klasterëve zakonisht kostocon më pak, pasi shkurtimet e burimeve të tepërta.
Kjo është sidomos e vërtetë për nyjat kryesore, të cilat mund të kenë kosto të konsiderueshme pavarësisht nga ndarja (on-premises ose në cloud).
Disa shërbime të menaxhuara të Kubernetes, si ose , ofrojnë një shtresë menaxhuese falas. Në këtë rast, çështja e kostove është më pak e rëndësishme.
Ekzistojnë gjithashtu shërbime të menaxhuara, të cilat ndihmojnë me një tarifë fikse për çdo klasër Kubernetes (p.sh., ).
+ Administrim efektiv
Të menaxhosh një klasër është më e lehtë se sa disa.
Administrimi mund të përfshijë detyra të tilla si:
- përditësimi i versionit të Kubernetes;
- konfigurimi i kanalit CI/CD;
- instalimi i plugin-it CNI;
- konfigurimi i sistemit të autentifikimit të përdoruesve;
- instalimi i kontrolluesit të qasjes;
dhe shumë të tjera…
Në rastin e një klasri, do të duhet të merresh me të gjitha këto vetëm një herë.
Për shumë klastra, operacionet do të duhet të përsëriten shumë herë, gjë që ndoshta do të kërkojë një farë automatizimi të proceseve dhe mjeteve për të siguruar sistematik të procesit.
Tani le të flasim për disa disavantazhe.
− Pikë e vetme dështimi
Në rastin e dështimit të vetëm klastri, do të ndalojnë menjëherë të gjitha ngarkesat e punës!
Ekzistojnë shumë mundësi kur diçka mund të shkojë keq:
- përditësimi i Kubernetes sjell efekte anësore të papritura;
- një komponent i përgjithshëm (p.sh., plugin CNI) fillon të funksionojë ndryshe nga sa pritej;
- një nga komponentët e klastrit është konfiguruar gabimisht;
- dështimi në infrastrukturën e poshtme.
Një incident i tillë mund të shkaktojë dëme serioze për të gjitha ngarkesat e punës të vendosura në klastrin e përbashkët.
− Mungesë e izolimit të fortë
Të punosh në një klasër të përbashkët do të thotë që aplikacionet ndajnë gjithashtu burimet e harduerit, mundësitë në rrjet dhe sistemin operativ në nyjat e klasrit.
Në një farë mënyre, dy kontejnerë me dy aplikacione të ndryshme, që funksionojnë në të njëjtën nyjë, janë të ngjashëm me dy procese që funksionojnë në të njëjtën makinë nën një bërthamë të sistemit operativ të njëjtë.
Kontejnerët e Linux ofrojnë një formë izolimi, por ajo nuk është ashtu siç ofrojnë, për shembull, makinat virtuale. Në thelb, procesi në një kontejner është i njëjti proces që funksionon në sistemin operativ të hostit.
Kjo mund të bëhet një problem nga një perspektivë sigurie: një organizim i tillë teorikisht lejon aplikacione të palidhura të ndërveprojnë me njëri-tjetrin (qëllimisht ose rastësisht).
Për më tepër, të gjitha ngarkesat e punës në klastrin Kubernetes ndajnë disa shërbime të përbashkëta të klastrit, të tilla si — kjo i lejon aplikacionet të gjejnë Shërbimet e aplikacioneve të tjera në klasër.
Të gjitha pikat e përmendura më sipër mund të kenë një rëndësi të ndryshme varësisht nga kërkesat për sigurinë e aplikacioneve.
Kubernetes ofron mjete të ndryshme për të parandaluar probleme në sistemin e sigurisë, të tilla si dhe . Megjithatë, për t'i konfiguruar ato siç duhet kërkohet një përvojë e caktuar; për më tepër, ato nuk janë në gjendje të mbyllin plotësisht të gjitha vrimat e sigurisë.
Është e rëndësishme të mbash gjithmonë mend se Kubernetes është zhvilluar fillimisht për ndarjen, e jo për izolimin dhe sigurinë.
− Mungesë e multi-tenancës të fortë
Duke marrë parasysh përmbushjen e burimeve të përbashkëta në klastrin Kubernetes, ekzistojnë shumë mënyra me të cilat aplikacione të ndryshme mund të "përdorin" njëra-tjetrën.
Për shembull, një aplikacion mund të monopolizojë një burim të përbashkët (si CPU ose memorie) dhe t'i heqë qasje aplikacioneve të tjera që punojnë në të njëjtën nyjë.
Kubernetes ofron mekanizma të ndryshëm për të kontrolluar këtë tip të sjelljeje, të tilla si (shih gjithashtu artikullin "" – shënim i përkthyesit), dhe . Megjithatë, ashtu si në rastin e sigurisë, konfiguroja e tyre është mjaft e ndërlikuar dhe ato nuk janë në gjendje të parandalojnë plotësisht të gjitha efekte anësore të papritura.
− Numër i madh përdoruesish
Në rastin e një klastri të vetëm, duhet të hapësh qasje për shumë njerëz. Dhe sa më i madh të jetë numri i tyre, aq më i lartë është rreziku që ata mund të "thyhen" diçka.
Brenda klasrit mund të kontrollosh se kush dhe çfarë mund të bëjë përmes (shih artikullin "" – shënim i përkthyesit). Megjithatë, kjo nuk do t'i pengojë përdoruesit të "thyejnë" diçka brenda zonës së tyre të përgjegjësisë.
− Klastrat nuk mund të rriten pafundësisht
Një klasër që përdoret për të gjithë ngarkesat e punës, do të jetë ndoshta shumë i madh (për numrin e nyjeve dhe pod-ëve).
Por këtu lind një tjetër problem: klasrat në Kubernetes nuk mund të rriten pafundësisht.
Ekziston një kufi teorik për madhësinë e klasrit. Në Kubernetes, ai është kështu rreth .
Megjithatë, në jetën e përditshme, problemet mund të fillojnë shumë më herët — për shembull, vetëm në .
Fakti është se klasterat e mëdhenj shkaktojnë një ngarkesë të lartë në nivelin e menaxhimit të Kubernetes. Me fjalë të tjera, për të mbajtur një klaster në gjendje funksionale dhe për të përdorur në mënyrë efektive burimet, kërkohet një konfigurim i kujdesshëm.
Ky problem shqyrtohet në artikullin përkatës në blogun origjinal të titulluar "».
Por le të shqyrtojmë qasjen e kundërt: shumë klastera të vegjël.
2. Shumë klastera të vegjël dhe të specializuar
Me këtë qasje, ju përdorni një klaster të veçantë për çdo element që vendosni:
Shumë klastera të vegjël
Për qëllimet e këtij artikulli, elementi i vendosjes referohet në një ekzemplar aplikacioni - për shembull, versioni dev i një aplikacioni të veçantë.
Me këtë strategji, Kubernetes përdoret si një mjedis i specializuar për ekzemplarët e veçantë të aplikacioneve. + Rreziku i kufizuar i "shembjes"
Le të shqyrtojmë përfitimet dhe disavantazhet e kësaj qasje.
Në rast "shembjeje" të klasterit, pasojat negative kufizohen vetëm në ato ngarkesa që ishin vendosur në këtë klaster. Të gjithë workload-t e tjera mbeten të paprekura.
+ Izolimi
Ngarkesat që vendosen në klastera individualë nuk ndajnë burime të përbashkëta, si CPU, memorie, sistem operativ, rrjet ose shërbime të tjera.
Si rezultat, arrijmë një izolim të fortë midis aplikacioneve të pa lidhura, gjë që mund të ketë një ndikim pozitiv në sigurinë e tyre.
+ Numër i vogël përdoruesish
Duke pasur parasysh se çdo klaster përmban vetëm një grup të kufizuar ngarkesash, reduktohet numri i përdoruesve me qasje në të.
Sa më pak njerëz të kenë qasje në klaster, aq më i ulët është rreziku që diçka të "shembet".
Le të shikojmë disavantazhet.
- Përdorim jo eficient të burimeve
Siç u përmend më parë, çdo klaster Kubernetes ka nevojë për një set të caktuar burimesh menaxhuese: nodet master, komponentët e nivelit të kontrollit, zgjidhje për monitorim dhe regjistrim.
Në rastin e një numri të madh klasterash të vegjël, duhet të alokohesh një pjesë më e madhe e burimeve për menaxhim.
- Kosto e lartë
Përdorimi jo eficient i burimeve automatikisht sjell kosto të larta.
Për shembull, mbajtja e 30 nodave master në vend të tre në të njëjtën fuqi përpunuese do të ndikonte pasi në shpenzime.
- Vështirësi në administrim
Të menaxhosh shumë klastera Kubernetes është shumë më e komplikuar se sa të punosh me një.
Për shembull, do të duhet të konfiguroni autentifikimin dhe autorizimin për çdo klaster. Po ashtu, përditësimi i versionit të Kubernetes do të duhet të bëhet disa herë.
Me siguri do të duhet të aplikoni automatizimin për të rritur efikasitetin e të gjitha këtyre detyrave.
Tani le të shqyrtojmë skenarë më pak ekstreme.
3. Një klaster për çdo aplikacion
Në kuadër të kësaj qasje, krijoni një klaster të veçantë për të gjithë ekzemplarët e një aplikacioni të caktuar:
Klaster për aplikacion
Ky rrugë mund të shqyrtohet si një përgjithësim i parimit "
një klaster për ekipin", pasi zakonisht një ekip inxhinierësh merret me zhvillimin e një ose disa aplikacioneve.+ Klasteri mund të përshtatet për aplikacionin
Le të shqyrtojmë përfitimet dhe disavantazhet e kësaj qasje.
Nëse aplikacioni ka nevoja të veçanta, ato mund të realizohen në klaster, pa prekur klasterat e tjerë.
Këto nevoja mund të përfshijnë worker me GPU, komponent të caktuar CNI, service mesh ose ndonjë shërbim tjetër.
Çdo klaster mund të përshtatet për aplikacionin që po aktivizon brenda tij, në mënyrë që të përmbajë vetëm atë që nevojitet.
- Mjedise të ndryshme në një klaster
Disavantazhi i kësaj qasje është se ekzemplarët e aplikacioneve nga mjedise të ndryshme koegzistojnë brenda një klasteri.
Për shembull, versioni prodhues i një aplikacioni punon në të njëjtin klaster si versioni dev. Kjo gjithashtu do të thotë se zhvilluesit kryejnë aktivitetet e tyre në të njëjtin klaster ku operohet versioni prodhues i aplikacionit.
Nëse shkaktohet një dështim nga veprimet e zhvilluesve ose nga një gabim i versionit dev në klaster, potencialisht mund të dëmtohet edhe versioni prodhues - një disavantazh i madh i këtyre qasjeve.
Dhe së fundmi, skenari i fundit në listën tonë.
4. Një klaster për çdo mjedis
Ky skenar përfshin alokimin e një klasteri të veçantë për çdo mjedis:
Një klaster për mjedisin
Për shembull, mund të keni klastera
, ku do të aktivizoni të gjithë ekzemplarët e aplikacioneve të destinuara për një mjedis të caktuar. dev, test dhe prodJa përfitimet dhe disavantazhet e kësaj qasje.
+ Izolimi i mjedisit prodhues
Në këtë qasje, të gjitha mjediset janë të izoluar nga njëra-tjetra. Megjithatë, në praktikë, kjo është veçanërisht e rëndësishme për mjedisin prodhues.
Në kuadër të këtij qasje, të gjitha ambientet janë të izoluar nga njëra-tjetra. Megjithatë, në praktikë, kjo është veçanërisht e rëndësishme për mjedisin prodhues.
Versionet e prodhimit të aplikacionit tani nuk varen nga ajo që ndodh në klasterët dhe mjediset e tjera.
Prandaj, nëse ndodhin probleme papritur në klasterin dev, versionet prodhuese të aplikacioneve do të vazhdojnë të funksionojnë siç ishte parashikuar.
+ Klasteri mund të rregullohet për mjedisin
Çdo klaster mund të përshtatet sipas mjedisit të tij. Për shembull, mund të:
- instaloni mjete për zhvillim dhe debug në klasterin dev;
- instaloni korniza dhe mjete testimi në klaster test;
- përdorni pajisje më të fuqishme dhe kanale rrjeti në klaster prod.
Kjo lejon të rritet efikasiteti si në zhvillim ashtu edhe në operimin e aplikacioneve.
+ Kufizimi i aksesit në klasterin prodhues
Nevoja për të punuar me klasterin prodhues ndodh rrallë, kështu që mund të kufizoni ndjeshëm numrin e njerëzve që kanë akses atje.
Mund të shkoni edhe më tej dhe të privoni plotësisht njerëzit nga ky klaster, duke kryer të gjitha shpërndarjet përmes një mjeti automatizimi CI/CD. Ky qasje do të minimizojë rrezikun e gabimeve njerëzore, veçanërisht aty ku është më kritik.
Tani le të flasim për disa disavantazhe.
- Mungesa e izolimit midis aplikacioneve
Disavantazhi kryesor i këtij qasje është mungesa e izolimit harduerik dhe burimor midis aplikacioneve.
Aplikacionet e pakënaqura ndajnë burimet e klasterit: bërthamën sistemore, procesorin, memorien dhe disa shërbime të tjera.
Siç është përmendur tashmë, kjo mund të jetë potencialisht e rrezikshme.
- Pamundësia për të lokalizuar varësitë e aplikacioneve
Nëse një aplikacion ka kërkesa të veçanta, duhet t'i përmbahen në të gjithë klasterët.
Për shembull, nëse aplikacionit i nevojitet GPU, atëherë çdo klaster duhet të ketë të paktën një punëtor me GPU (edhe nëse përdoret vetëm nga ky aplikacion).
Si rezultat, rrezikojmë të kemi kosto më të larta dhe përdorim joefikas të burimeve.
Përfundimi
Nëse ka një grup të caktuar aplikacionesh, ato mund të vendosen në disa klasterë të mëdhenj ose në shumë të vegjël.
Ky artikull shqyrton përparësitë dhe disavantazhet e qasjeve të ndryshme, duke filluar nga një klaster global deri te disa të vegjël dhe të specializuar:
- një klaster të madh të përbashkët;
- mijëra klastera të vegjël me specializim të ngushtë;
- një klaster për secilin aplikacion;
- një klaster për çdo ambient.
Pra, cili është qasja e duhur për t'u zgjedhur?
Si zakonisht, përgjigjja varet nga skenari i përdorimit: është e nevojshme të vlerësohen përparësitë dhe disavantazhet e qasjeve të ndryshme dhe të zgjidhet opsioni më optimal.
Megjithatë, zgjedhja nuk është e kufizuar vetëm në shembujt e përmendur më lart — mund të angazhohen çdo kombinim të tyre!
Për shembull, mund të organizoni nga një çift klasterësh për çdo ekip: një klaster për zhvillimin (ku do të jenë mjediset dev dhe test) dhe një klaster për production (ku do të jetë mjedisi prodhues).
Duke u mbështetur në informacionin nga ky artikull, ju mund të optimizoni përparësitë dhe disavantazhet sipas skenarit konkret. Fat të mbarë!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
