Shën. përkth.: ky ky ky ky — përgjigje për një pyetje të njohur në projektimin e infrastrukturës mbi bazën e Kubernetes. Shpresojmë që përshkrimet e detajuara të përparësive dhe disavantazheve të çdo opsioni do të ndihmojnë të bëni një zgjedhje optimale për projektin tuaj.
TL;DR: e njëjta grup i ngarkesave pune mund të nisë në disa klasterë të mëdhenj (me çdo klaster që përmban një numër të madh workload'esh) ose në shumë të vegjël (me një numër të vogël ngarkesash në çdo klaster).
Në vijim është një tabelë që vlerëson përparësitë dhe disavantazhet e çdo qasjeje:
Kur përdorni Kubernetes si një platformë për eksploatimin e aplikacioneve, shpesh lindin disa pyetje themelore rreth hollësive të konfigurimit të klasterëve:
- Sa klasterë duhet përdorur?
- Sa të mëdhenj duhet të jenë?
- Çfarë duhet të përmbajë çdo klaster?
Në këtë artikull do të përpiqem të përgjigjem për gjithë këto pyetje, duke analizuar përparësitë dhe disavantazhet e çdo qasjeje.
Formulimi i pyetjes
Si krijues i softuerit, ju ndoshta jeni duke zhvilluar dhe eksploatuar shumë aplikacione në të njëjtën kohë.
Për më tepër, shumë instance të këtyre aplikacioneve sigurisht që ekzekutohen në mjedise të ndryshme — për shembull, këto mund të jenë dev, test dhe prod.
Si rezultat, krijohet një matricë e tërë e aplikacioneve dhe mjediseve:
Aplikacione dhe mjedise
Në shembullin e mësipërm janë paraqitur 3 aplikacione dhe 3 mjedise, që në fund ofrojnë 9 variante të mundshme.
Çdo instance aplikacioni përbën një njësi deploy-i të vetë-mjaftueshme, me të cilën mund të punoni në mënyrë të pavarur nga të tjerat.
Vini re se instance aplikacioni mund të përbëhet nga shumë e komponentëve, si për shembull frontend, backend, baza e të dhënave etj. Në rastin e një aplikacioni mikrosërëvis, instance do të përfshijë të gjitha mikrosërviset.
Si pasojë, përdoruesit e Kubernetes kanë disa pyetje:
- A është e duhshme të vendosen të gjitha instance-t e aplikacionit në një klaster?
- A duhet të krijohet një klaster i veçantë për çdo instance aplikacioni?
- Ose, ndoshta, duhet të përdoret një kombinim i qasjeve të sipërpërmendura?
Të gjitha këto variante janë plotësisht të mundshme, pasi Kubernetes është një sistem fleksibël që nuk e kufizon përdoruesin në mundësi.
Ja disa nga mundësitë e mundshme:
- një klaster i madh i përbashkët;
- një numër i madh klasteresh të specializuara;
- një klaster për çdo aplikacion;
- një klaster për çdo ambient.
Siç tregohet më poshtë, dy qasjet e para janë në pole të kundërta të spektrit të mundësive:
Nga disa klastere të mëdha (majtas) deri në shumë të vogla (djathtas)
Në përgjithësi, konsiderohet se një klaster është "më i madh" se një tjetër nëse ka më shumë node dhe pod-e. Për shembull, një klaster me 10 node dhe 100 pod është më i madh se një klaster me 1 nod dhe 10 pod-e.
Mirë, le të fillojmë!
1. Një klaster i madh i përbashkët
Opsioni i parë është të vendosni të gjitha ngarkesat e punës në një klaster:
Një klaster i madh
Në këtë qasje, klasteri përdoret si një platformë infrastrukturore — gjithçka që ju nevojitet thjesht e zhvilloni në klasterin ekzistues Kubernetes.
Kubernetes lejon ndarjen logjike të pjesëve të klasterit nga njëra-tjetra, kështu që për çdo instancë të aplikacionit mund të përdorni hapësirën tuaj të emrave.
Le të shqyrtojmë përparësitë dhe disavantazhet e këtij qasjes.
+ Përdorimi efikas i burimeve
Në rastin e një klasteri të vetëm, do të kërkohet vetëm një kopje e të gjitha burimeve të nevojshme për të filluar dhe menaxhuar klasterin Kubernetes.
Për shembull, kjo është e vërtetë për nodet e masterit. Zakonisht, për çdo klaster Kubernetes ka 3 nodë master, kështu që për një klaster të vetëm, numri i tyre do të mbetet i tillë (për krahasim, 10 klastere do të kërkojnë 30 nodë master).
Kjo hollësi e mësipërme i referohet edhe shërbimeve të tjera që funksionojnë në shkallën e klasterit të gjithëpërfshirës, siç janë balancuesit e ngarkesës, kontrollorët Ingress, sistemet e autentikimit, regjistrimit dhe monitorimit.
Në një klaster të vetme, të gjitha këto shërbime mund të përdoren menjëherë për të gjitha ngarkesat e punës (nuk është e nevojshme të krijoni kopje të tyre, si në rastin e disa klastereve).
+ Kosto më e ulët
Si pasojë e asaj që u tha më sipër, numri më i vogël i klastereve zakonisht është më i lirë, pasi nuk ka shpenzime për burime të panevojshme.
Kjo është veçanërisht e vërtetë për nodet e masterit, të cilat mund të kushtojnë shumë pavarësisht nga mënyra e vendosjes (on-premises ose në cloud).
Disa shërbime të menaxhuara të Kubernetes, siç janë ose , ofrojnë një shtresë menaxhuese falas. Në këtë rast, çështja e kostove është më pak e rëndësishme.
Gjithashtu ekzistojnë shërbime të menaxhuara, që ngarkojnë një tarifë fikse për funksionimin e çdo klasteri Kubernetes (për shembull, ).
+ Menaxhim efikas
Të menaxhosh një klaster është më e lehtë se të menaxhosh disa.
Menaxhimi mund të përfshijë detyra të tilla si:
- përditësimi i versionit të Kubernetes;
- konfigurimi i pipeline-it CI/CD;
- instalimi i plugin-it CNI;
- konfigurimi i sistemit të autentikimit të përdoruesve;
- instalimi i kontrolluesit të aksesit;
dhe shumë të tjera…
Në rastin e një klasteri, do të merret me të gjitha këto vetëm një herë.
Për shumë klastere, operacionet do të duhet të përsëriten shpesh, që ndoshta do të kërkojë automatizimin e proceseve dhe mjetet, për të siguruar sistematikën dhe uniformitetin e procesit.
Tani disa fjalë mbi disavantazhet.
− Pikë e vetme dështimi
Në rast dështimi të klasterit të vetëm ngarkesat e punës do të ndalojnë menjëherë të gjithë të funksionojnë!
Ekzistojnë shumë variante kur diçka mund të shkojë keq:
- përditësimi i Kubernetesit shkakton efekte anësore të papritura;
- komponenti i përbashkët të klasterit (për shembull, plugin-i CNI) fillon të funksionojë ndryshe nga sa pritej;
- një nga komponentët e klasterit është konfigurimi jo korrekt;
- dështimi në infrastrukturën nëntokësore.
Një incident i tillë mund të shkaktojë dëme serioze për të gjitha ngarkesat e punës të vendosura në klasterin e përbashkët.
− Mungesa e izolimit të fortë
Puna në një klaster të përbashkët do të thotë se aplikacionet ndajnë burimet harduerike, mundësitë rrjet dhe sistemin operativ në nyjat e klasterit.
Në një sens, dy kontejnerë me dy aplikacione të ndryshme që punojnë në të njëjtën nyje janë si dy procese që punojnë në të njëjtën makinë nën një bërthamë të njëjtë të OS-së.
Kontejnerët Linux ofrojnë një formë të caktuar izolimi, por ajo nuk është ashtu si ajo që ofrojnë, për shembull, makinat virtuale. Në esencë, një proces në një kontejner është i njëjti proces i ekzekutuar në sistemin operativ të hostit.
Kjo mund të bëhet problem nga pikëpamja e sigurisë: një organizim i tillë teorikisht lejon aplikacionet e papërlyera të ndjehen midis tyre (në mënyrë të qëllimshme ose rastësore).
Përveç kësaj, gjithë ngarkesat e punës në klasterin Kubernetes ndajnë disa shërbime të përbashkëta klasteri, siç janë — kjo i lejon aplikacionet të gjeni Shërbimet e aplikacioneve të tjera në klaster.
Të gjitha pikët e lartpërmendura mund të kenë kuptime të ndryshme në varësi të kërkesave që i nënshtrohen sigurisë së aplikacioneve.
Kubernetes ofron mjete të ndryshme për të parandaluar problemet në sistemin e sigurisë, siç janë dhe . Megjithatë, për t'i konfiguruar ato siç duhet kërkohet një përvojë e caktuar, përveç kësaj, ato nuk janë në gjendje të mbyllin të gjitha dobësitë në siguri.
Është e rëndësishme të kujtojmë gjithmonë se Kubernetes fillimisht është dizajnuar për ndarjen, dhe jo për izolimin dhe sigurinë.
− Mungesa e multi-tenancy të ashpër
Duke marrë parasysh shumicën e burimeve të përbashkëta në klasterin Kubernetes, ekzistojnë shumë mënyra në të cilat aplikacionet e ndryshme mund të "ngacmojnë" njëra-tjetrën.
Për shembull, një aplikacion mund të monopolizojë një burim të përbashkët (siç është procesori ose memoria) dhe t'i heqë qasje burimeve të tjera që punojnë në të njëjtin nod.
Kubernetes siguron mekanizma të ndryshëm të kontrollit për këtë lloj sjelljeje, siç janë (shih gjithashtu artikullin “” — shën. përkth.), dhe . Megjithatë, ashtu si në rastin e sigurisë, konfigurimi i tyre është në të vërtetë kompleks dhe ato nuk janë në gjendje të parandalojnë të gjitha efektet anësore të papritura.
− Numri i madh i përdoruesve
Në rastin e një klasteri të vetëm, duhet të hapet akses për shumë njerëz. Dhe sa më i madh të jetë numri i tyre, aq më i lartë është rreziku që ata të "thyejnë" diçka.
Brenda klasterit mund të kontrolloni se kush dhe çfarë mund të bëjë përmes (shih artikullin “” — shën. përkth.). Megjithatë, kjo nuk do ta parandalojë përdoruesit të "thyejnë" diçka brenda zonës së tyre të përgjegjësisë.
− Klasteret nuk mund të rriten deri në pafundësi
Një klaster që përdoret për të gjitha ngarkesat e punës do të jetë, ndoshta, shumë i madh (në numrin e nodëve dhe pod-ve).
Por këtu lind një problem tjetër: klasteret në Kubernetes nuk mund të rriten deri në pafundësi.
Ka një kufi teorik mbi madhësinë e klasterit. Në Kubernetes, ai është rreth .
Megjithatë, në jetë reale problemet mund të fillojnë shumë më herët — për shembull, vetëm me .
Çështja është se klasterat e mëdhenj ushtrojnë një ngarkesë të lartë në shtresën menaxhuese të Kubernetes. Me fjalë të tjera, për të mbajtur klasterin në gjendje pune dhe për të përdorur burimet efektivisht, nevojitet konfigurim i kujdesshëm.
Kjo çështje shqyrtohet në artikullin përkatës në blogun origjinal me titullin "».
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, përdorni një klaster të veçantë për çdo element që është në zhvillim:
Shumë klastera të vegjël
Për qëllimet e këtij artikulli, elementin që është në zhvillim e kuptojmë si një instancë aplikacioni — për shembull, versionin dev të një aplikacioni të veçantë. Në këtë strategji, Kubernetes përdoret si një
mjedis ekzekutimi për instancat e veçanta të aplikacionit. + Rreziku i kufizuar
Le të shqyrtojmë përparësitë dhe disavantazhet e këtij qasjes.
Kur ndodh një "defekt" në klaster, pasojat negative kufizohen vetëm në ato ngarkesa pune që ishin të zhvilluara në këtë klaster. Të gjitha ngarkesat e tjera mbeten të paprekura.
+ Izolimi
Ngarkesat e punës të vendosura në klastera individuale nuk ndajnë burime të përbashkëta, siç janë procesori, memoria, sistemi operativ, rrjeti ose shërbime të tjera.
Si rezultat, ne marrim një izolim të fortë midis aplikacioneve të pa lidhura, që mund të ketë një ndikim pozitiv në sigurinë e tyre.
+ Numri i vogël i përdoruesve
Duke marrë parasysh se në çdo klaster ka vetëm një grup të kufizuar ngarkesash pune, numri i përdoruesve me qasje në të reduktohet.
Sa më pak njerëz të kenë qasje në klaster, aq më i ulët është rreziku që diçka të "prishet".
Tani le të shohim disavantazhet.
− Përdorimi jo efikas i burimeve
Siç u përmend më parë, çdo klaster Kubernetes kërkon një grup të caktuar burimesh menaxhimi: node master, komponentë të shtresës kontrolluese, zgjidhje për monitorim dhe regjistrim.
Në rastin e një numri të madh klasterash të vegjël, duhet të alokoni një përqindje më të madhe të burimeve për menaxhim.
− Kostoja
Përdorimi jo efikas i burimeve automatikisht sjell kosto të larta.
Përdorimi joefektiv i burimeve automatikisht sjell kostot të larta.
Për shembull, prania e 30 master node-ëve në vend të tre për të njëjtën kapaciteti përpunimi do të ndikojë patjetër në shpenzime.
− Vështirësitë e administratës
Të menaxhosh shumë klasterë Kubernetes është shumë më e vështirë se sa të punosh me një të vetëm.
Për shembull, do të duhet të konfigurosh autentikimin dhe autorizimin për secilin klaster. Përditësimi i versionit të Kubernetes gjithashtu do të duhet të kryhet disa herë.
Ndoshta do të duhet të aplikosh automatizimin për të rritur efikasitetin e të gjitha këtyre detyrave.
Tani le të shqyrtojmë skenarët më pak ekstremë.
3. Një klaster për secilën aplikacion
Brenda këtij qasjeje, krijoni një klaster të veçantë për të gjitha instancat e aplikacionit konkret:
Klaster për aplikacion
Ky rrugë mund të merret si një përmbledhje e parimit "klaster i veçantë për ekipin", pasi zakonisht një ekip inxhinierësh merret me zhvillimin e një ose më shumë aplikacioneve.
Le të shqyrtojmë përparësitë dhe disavantazhet e këtij qasjes.
+ Klasteri mund të përshtatet për aplikacionin
Nëse aplikacioni ka nevoja të veçanta, ato mund të realizohen në klaster, pa prekur klasterët e tjerë.
Këto nevoja mund të përfshijnë punëtorë me GPU, disa plugina CNI, service mesh ose ndonjë shërbim tjetër.
Çdo klaster mund të përshtatet për aplikacionin që punon në të, në mënyrë që të përmbajë vetëm atë që është e nevojshme.
− Mjedise të ndryshme në një klaster
Një disavantazh i këtij qasjeje është se instancat e aplikacioneve nga mjedise të ndryshme bashkëjetojnë në një klaster.
Për shembull, versioni prodhues i aplikacionit funksionon në të njëjtin klaster si versioni dev. Kjo do të thotë gjithashtu se zhvilluesit kryejnë aktivitetin e tyre në të njëjtin klaster ku eksploatohet versioni prodhues i aplikacionit.
Nëse për shkak të veprimeve të zhvilluesve ose gabimeve të versionit dev ndodh një çrregullim në klaster, potencialisht mund të dëmtosh edhe versionin prodhues — një disavantazh të madh të këtij qasjeje.
Dhe, përfundimisht, skenari i fundit në listën tonë.
4. Një klaster për çdo mjedis
Ky skenar parashikon ndarjen e një klasteri të veçantë për çdo mjedis:
Një klaster për mjedis
Për shembull, mund të keni klasterë dev, test dhe prod, ku do të запускohet të gjitha instancat e aplikacionit të destinuara për një mjedis të caktuar.
Ja përfitimet dhe disavantazhet e këtij qasjeje.
+ Izolimi i mjedisit prodhues
Në kuadër të këtij 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 ambientin prodhues.
Versionet e prodhimit të aplikacionit tani nuk varen nga ajo që ndodh në grupe dhe mjedise të tjera.
Kështu, nëse ndonjëherë ndodhin probleme në grupin e zhvillimit, versionet e prodhimit të aplikacioneve do të vazhdojnë të funksionojnë siç duhet.
+ Grupi mund të përshtatet sipas mjedisit
Çdo grup mund të përshtatet sipas mjedisit të tij. Për shembull, mund të:
- instaloni në grupin e zhvillimit mjete për zhvillim dhe debug;
- instaloni kornizat dhe mjetet testuese në grupin test;
- përdorni pajisje dhe kanale rrjeti më të fuqishme në grupin prod.
Kjo lejon rritjen e efikasitetit si në zhvillimin ashtu edhe në operimin e aplikacioneve.
+ Kufizimi i aksesit në grupin e prodhimit
Nevoja për të punuar drejtpërdrejt me grupin e prodhimit ndodh rrallë, kështu që mund të kufizoni ndjeshëm grupin e personave që kanë akses në të.
Mund të shkojmë edhe më tej dhe t’i heqim njerëzit aksesin në këtë grup, dhe të gjitha shpërndarjet të realizohen përmes një strumenti automatizimi CI/CD. Ky qasje do të ndihmojë në minimizimin e rrezikut të gabimeve njerëzore pikërisht aty ku është më e rëndësishme.
Tani disa fjalë mbi disavantazhet.
− Mungesa e izolimit mes aplikacioneve
Dobësia kryesore e qasjes është mungesa e izolimit harduerik dhe të burimeve mes aplikacioneve.
Aplikacionet e pa lidhura ndajnë burimet e grupit: bërthamën sistemore, procesorin, kujtesën dhe disa shërbime të tjera.
Siç është përmendur më parë, 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, ato duhet të përmbushen në të gjitha grupet.
Për shembull, nëse një aplikacion kërkon GPU, atëherë çdo grup duhet të ketë të paktën një punëtor me GPU (edhe nëse ai përdoret vetëm nga ky aplikacion).
Si rezultat, rrezikojmë të kemi kostot më të larta dhe përdorim jo efikas të burimeve.
Përfundim
Me një grup të caktuar aplikacionesh, ato mund të vendosen në disa grupe të mëdha ose në shumë të vogla.
Në këtë artikull shqyrtohen përfitimet dhe disavantazhet e qasjeve të ndryshme, duke filluar nga një grup global dhe duke përfunduar me disa grupe të vogla dhe të specializuara:
- një grumbull i madh dhe i përbashkët;
- një numër i madh klasteresh të specializuara;
- një klaster për çdo aplikacion;
- një klaster për çdo ambient.
Pra, cili qasje të zgjidhni?
Si zakonisht, përgjigjja varet nga skenari i përdorimit: duhet të vlerësoni përfitimet dhe disavantazhet e qasjeve të ndryshme dhe të zgjidhni opsionin më optimal.
Megjithatë, zgjedhja nuk kufizohet në shembujt e përmendur më sipër — mund të përdoren çdo kombinim i tyre!
Për shembull, mund të organizoni dy grumbuj për çdo ekip: një grumbull për zhvillimin (ku do të jenë mjediset dev dhe test) dhe një grumbull për production (ku do të ndodhet mjedisi production).
Duke mbështetur informacionin nga ky artikull, do të jeni në gjendje të optimizoni përfitimet dhe disavantazhet në përputhje me skenarin specifik. Fat të mirë!
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
