Kur krijoni njĂ« klaster Kubernetes, mund tĂ« shfaqen pyetje: sa nyje pune duhet tĂ« konfiguroni dhe çfarĂ« lloji? ĂfarĂ« Ă«shtĂ« mĂ« mirĂ« pĂ«r njĂ« klaster on-premise: tĂ« blini disa serverĂ« tĂ« fuqishĂ«m ose tĂ« angazhojeni njĂ« duzinĂ« makinash tĂ« vjetra nĂ« qendrĂ«n tuaj tĂ« tĂ« dhĂ«nave? Dhe nĂ« cloud, a Ă«shtĂ« mĂ« mirĂ« tĂ« merrni tetĂ« instanca me njĂ« bĂ«rthamĂ« apo dy me katĂ«r bĂ«rthama?
Përgjigjet për këto pyetje janë në artikull në përkthimin e ekipit .
Kapasiteti i klasterit
Në përgjithësi, një klaster Kubernetes mund të mendohet si një "super nyje" e madhe. Fuqia e tij e përgjithshme llogaritet si shuma e fuqive të të gjitha nyjeve përbërëse.
Ekzistojnë disa mënyra për të arritur kapacitetin e dëshiruar të klasterit. Për shembull, na nevojitet një klaster me një kapacitet të përgjithshëm prej 8 bërthamash procesori dhe 32 GB RAM, sepse grupi i aplikacioneve kërkon një mundësi të tillë. Atëherë mund të instaloni dy nyje me 16 GB memorie ose katër nyje me 8 GB memorie, dy procesorë katër bërthamash ose katër me dy bërthama.
Ja dy mundësi të mundshme për të krijuar një klaster:
Të dy opsionet ofrojnë një kluster me kapacitet të njëjtë, por në konfigurimin në fund janë vendosur katër njësitë më të vogla, ndërsa në konfigurimin lart janë dy njësitë më të mëdha.
Cili opsion është më i mirë?
Për të përgjigjur në këtë pyetje, le të shqyrtojmë përparësitë e të dy opsioneve. I kemi përmbledhur ato në një tabelë.
Disa njësitë të mëdha
Shumë njësitë të vogla
Menaxhimi i lehtë i klustrit (nëse është on-premise)
Automatik i shkallëzimit fluid
Më i lirë (nëse on-premise)
Ămimi Ă«shtĂ« paksa i njĂ«jtĂ« (nĂ« cloud)
Mund të ekzekutoni aplikacione me kërkesa të larta për burime
Replikim i plotë
Burimet përdoren më efektivisht (më pak overhead për demonët e sistemit)
Më shumë qëndrueshmëri e klustrit
Kujdes, ne flasim vetëm për njësitë operative. Zgjedhja e numrit dhe përmasave të njësive kryesore është një temë krejtësisht tjetër.
Tani, le të diskutojmë më në detaje çdo pikë nga tabela.
Opsioni i parë: disa njësitë të mëdha
Opsioni më ekstrem është një njësitë operative për gjithë kapacitetin e klustrit. Në shembullin më lart do të ishte një njësitë operative me 16 bërthama CPU dhe 16 GB memorie.
PĂ«rfitimet
PĂ«rfitimi â 1. Menaxhimi mĂ« i lehtĂ«
ĂshtĂ« mĂ« e lehtĂ« tĂ« menaxhosh disa makina sesa njĂ« park tĂ« tĂ«rĂ«. Aktualizimet dhe korrigjimet aplikohen mĂ« shpejt, dhe sinkronizimi Ă«shtĂ« mĂ« i lehtĂ«. Numri i dĂ«shtimeve nĂ« numra absolutĂ« gjithashtu Ă«shtĂ« mĂ« i ulĂ«t.
Kujdes, gjithçka e përmendur më sipër i referohet harduerit tuaj, serverëve tuaj, dhe jo instancave në re.
Në re, situata është ndryshe. Menaxhimi bëhet nga ofruesi i shërbimit të reve. Kështu, menaxhimi i dhjetë node-ve në re nuk është ndryshe nga menaxhimi i një node.
Routimi i trafikut dhe shpërndarja e ngarkesës midis pod-eve në re : trafiku i ardhshëm nga interneti dërgohet në balancuesin kryesor të ngarkesës, i cili drejton trafikun në portin e njërit prej node-ve (shërbimi NodePort vendos një port në intervalin 30000-32767 në çdo node të klasterit). Rregullat e vendosura nga kube-proxy riorientojnë trafikun nga node-ja në pod. Ky është pamja për dhjetë pod-e në dy node:
Pika nr. 2. Më pak shpenzime për node
Një server i fuqishëm është më i shtrenjtë, por rritja e çmimit nuk është domosdoshmërisht lineare. Me fjalë të tjera, një server me 10 bërthama dhe 10 GB RAM zakonisht është më i lirë se dhjetë serverë një-bërthamësh me të njëjtin sasi RAM.
Por kini parasysh se ky rregull zakonisht nuk funksionon në shërbimet cloud. Në skemat aktuale të çmimeve, të gjithë ofruesit kryesorë të shërbimeve cloud çmimet rriten linearisht me rritjen e kapacitetit.
Prandaj, zakonisht nuk është e mundur të kursehet në serverët më të fuqishëm në cloud.
Pika e tretë. Mund të executoni aplikacione të kërkueshme për burime.
Disa aplikacione kërkojnë servera të fuqishëm në klaster. Për shembull, nëse një sistem mësimi makinerik kërkon 8 GB RAM, nuk do të mund ta ekzekutoni atë në node me 1 GB, vetëm nëse keni të paktën një node të madh pune.
Kundrat
Kundri i parë. Shumë pod'i në një node.
Nëse të njëjtin detyrë e realizoni në numër më të vogël nodash, atëherë natyrisht do të ketë më shumë pod'e në secilin prej tyre.
Kjo mund të bëhet një problem.
Arsyeja është se çdo modul sjell disa kosto shtesë në ambientin e ekzekutimit të kontejnerit (p.sh., Docker), si dhe në kubelet dhe cAdvisor.
PĂ«r shembull, kubelet regulisht sondon pĂ«r jetĂ«sinĂ« e tĂ« gjitha konteinerĂ«ve nĂ« nyjĂ« â sa mĂ« shumĂ« konteinerĂ«, aq mĂ« shumĂ« punĂ« ka pĂ«r kubelet.
CAdvisor grumbullon statistikën e përdorimit të burimeve të të gjitha konteinerëve në nyjë, dhe kubelet regulisht kërkon këtë informacion dhe e ofron atë përmes API. Edhe njëherë, sa më shumë konteinerë, aq më shumë punë ka për cAdvisor dhe kubelet.
Nëse numri i moduleve rritet, kjo mund të ngadalësojë sistemin dhe madje ta dëmtojë atë.
Në depoziten e Kubernetes disa , që nyjat kalojnë mes statusit Ready/NotReady, pasi kontrollimet e rregullta të kubelet për të gjitha konteinerët në nyjë marrin shumë kohë.
PĂ«r kĂ«tĂ« arsye, Kubernetes . NĂ« varĂ«si tĂ« performancĂ«s sĂ« nyjĂ«s, mund tĂ« ekzekutoni mĂ« shumĂ« podĂ« nĂ« nyjĂ«, por Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikoni nĂ«se do tĂ« lindin probleme apo nĂ«se gjithçka do tĂ« funksionojĂ« mirĂ«. ĂshtĂ« e kĂ«shillueshme tĂ« testoni paraprakisht funksionimin.
Minusi Nr. 2. Kufizimi në replikim
Numri i vogël i nyjeve kufizon shkallën efektive të replikimit të aplikacioneve. Për shembull, nëse keni një aplikacion me disponueshmëri të lartë me pesë replikime, por vetëm dy nyje, atëherë shkalla efektive e replikimit zvogëlohet në dy.
Pesë replikime mund të shpërndahen vetëm në dy nyje, dhe nëse njëra prej tyre dështon, ajo menjëherë dërgon në prishje disa replikime.
Nëse keni pesë nyje ose më shumë, secila replikim do të ekzekutohet në një nyje të veçantë, dhe dështimi i një nyje do të eliminojë jo më shumë se një replikim.
Kështu, kërkesat për disponueshmëri të lartë mund të kërkojnë një numër minimal të nyjeve në klaster.
Minus â 3. Pasojat e njĂ« dĂ«shtimi janĂ« mĂ« tĂ« kĂ«qija
Me numër të vogël nyjesh, çdo dështim sjell pasoja më të rënda. Për shembull, nëse keni vetëm dy nyje dhe njëra prej tyre dështon, menjëherë humbni gjysmën e moduleve tuaj.
Sigurisht, Kubernetes do të transferojë ngarkesën e punës nga nyja që ka dështuar në nyjet e tjera. Por nëse ka pak, mund të mos ketë kapacitet të lirë të mjaftueshëm. Si rezultat, disa nga aplikacionet tuaja do të jenë të papërballueshme derisa të rivendosni nyjen që ka dështuar.
Pra ndaj, sa më shumë node të ketë, aq më pak ndikim kanë defektet harduerike.
Disavantazhi â 4. ShkallĂ«zimi automatik mĂ« i ngadalshĂ«m
Në Kubernetes, ekziston një sistem shkallëzimi automatik për infrastrukturën cloud, i cili lejon shtimin ose heqjen e nodave në varësi të nevojave aktuale. Me node më të mëdha, shkallëzimi bëhet më i papritur dhe i pakuptueshëm. Për shembull, në një konfigurim me dy node, shtimi i një node tjetër do ta rrisë kapacitetin e klasterit menjëherë me 50%. Dhe do t'ju duhet të paguani për këto burime, edhe nëse ato nuk ju nevojiten.
Pra, nëse planifikoni të përdorni shkallëzim automatik për klasterin, sa më të vogla të jenë nodet, aq më fleksibël dhe ekonomik do të jetë shkallëzimi që do të merrni.
Tani le tâi shqyrtojmĂ« avantazhet dhe disavantazhet e njĂ« numri tĂ« madh nodash tĂ« vogla.
Zgjedhja e dytë: shumë nodë të vogla
Avantazhet e këtij qasje, përfundimisht, rrjedhin nga disavantazhet e opsionit të kundërt me disa node të mëdha.
PĂ«rfitimet
Plusi â 1. Pasojat mĂ« tĂ« vogla tĂ« defekteve
Sa më shumë nyje, aq më pak pod-e ka në çdo nyje. Për shembull, nëse keni njëqind module në dhjetë nyje, atëherë në çdo nyje do të ketë mesatarisht dhjetë module.
Pra, nëse një nga nyjet dështon, do të humbni vetëm 10% të ngarkesës së punës. Ka mundësi që të preken vetëm disa replika dhe aplikacionet në përgjithësi të mbeten funksionale.
Përveç kësaj, në nyjet e mbetura, ka gjasa që të mjaftojnë burimet e lira për ngarkesën e punës së nyjës që ka dështuar, kështu që Kubernetes mund të riplanifikojë lirshëm pod-et dhe aplikacionet tuaja do të rikthehen relativisht shpejt në gjendje funksionale.
Përfitimi numër 2. Replikimi i mirë
Nëse ka mjaft nyje, planifikuesi i Kubernetes mund të caktojë të gjitha replikat në nyje të ndryshme. Kështu, në rast dështimi të një nyje do të prekët vetëm një replikë, ndërsa aplikacioni do të mbetet i aksesueshëm.
Kundrat
Minus numër 1. Më e vështirë menaxhimi
Më shumë nyje është më e vështirë të menaxhohen. Për shembull, çdo nyje Kubernetes duhet të ndërveprojë me të gjitha nyjet e tjera, që do të thotë se numri i lidhjeve rritet katrorisht, dhe të gjitha këto lidhje duhet të qëndrojnë nën mbikëqyrje.
Menaxheri i nyjeve nĂ« menaxherin e kontrolleve Kubernetes rregullisht kontrollon tĂ« gjitha nyjet nĂ« grup pĂ«r tĂ« verifikuar funksionimin â sa mĂ« shumĂ« nyje, aq mĂ« e madhe Ă«shtĂ« ngarkesa mbi kontrollin.
Ngarkesa rritet gjithashtu mbi bazĂ«n e tĂ« dhĂ«nave etcd â çdo kubelet dhe kube-proxy thĂ«rret pĂ«r etcd (pĂ«rmes API), tĂ« cilit etcd duhet t'i transmetojĂ« pĂ«rditĂ«simet e objektit.
Në përgjithësi, çdo nyjë punuese ngarkon shtesë mbi komponentët sistemorë të nyjave kryesore.
Zyrtarisht, Kubernetes mbështet grupe me . Megjithatë, në praktikë, edhe 500 nyje .
Për të menaxhuar një numër të madh nyjesh punuese, duhet zgjedhur nyje kryesore më të fuqishme. Për shembull, kube-up madhësinë e duhur të VM për nyjen kryesore në varësi të numrit të nyjeve punuese. Pra, sa më shumë nyje punuese, aq më efikas duhet të jenë nyjet kryesore.
Për të zgjidhur këto probleme specifike ka zhvillime të veçanta, të tilla si . Ky sistem lejon kalimin e kufizimeve dhe ndërtimin e grupeve me një numër të madh nyjesh punuese.
Minus Nr. 2. Më shumë shpenzime shtesë
NĂ« çdo nod tĂ« punĂ«s, Kubernetes ekzekuton njĂ« grup demonĂ«sh sistemorĂ« â pĂ«rfshirĂ« mjedisin e ekzekutimit tĂ« konteinerĂ«ve (p.sh., Docker), kube-proxy dhe kubelet, duke pĂ«rfshirĂ« cAdvisor. TĂ« gjitha sĂ« bashku konsumojnĂ« njĂ« sasi tĂ« caktuar resursesh.
Nëse keni shumë nodet të vogla, pesha e këtyre shpenzimeve shtesë është më e madhe në çdo nod. Për shembull, imagjinoni se të gjithë demonët sistemorë të një nodi së bashku përdorin 0,1 bërthama CPU dhe 0,1 GB memorje. Nëse keni një nod me dhjetë bërthama dhe 10 GB memorje, atëherë demonët konsumojnë 1% të kapacitetit të klasterit. Nga ana tjetër, në dhjetë nodet me një bërthamë me 1 GB memorje, demonët do të marrin 10% të kapacitetit të klasterit.
Kështu, sa më pak nodet të keni, aq më efektivisht përdoret infrastruktura.
Minus Nr. 3. Përdorim i paefektshëm i burimeve
Në nodet e vogla, mund të ndodhi që fragmentet e mbetura të burimeve të jenë shumë të vogla për t'u caktuar një ngarkesë pune, kështu që ato mbeten të pa përdorura.
PĂ«r shembull, çdo pod kĂ«rkon 0,75 GB memorie. NĂ«se keni dhjetĂ« node, dhe secili ka 1 GB memorie, mund tĂ« lanconi dhjetĂ« podâĂ« â kĂ«shtu qĂ« nĂ« secilin node do tĂ« mbetet 0,25 GB memorie e pa pĂ«rdorur.
Kjo do të thotë se 25% e memories së të gjithë klasterit shpenzohet kot.
NĂ« njĂ« node tĂ« madh me 10 GB memorie, mund tĂ« lanconi 13 prej kĂ«tyre moduleve â dhe do tĂ« mbetet vetĂ«m njĂ« fragment i pa pĂ«rdorur prej 0,25 GB.
Në këtë rast, vetëm 2,5% e memories shpenzohet kot.
Prandaj, në node të mëdhenj, resurset shpenzohen më optimalisht.
Disa node të mëdhenj apo shumë të vegjël?
Pra, çfarë është më mirë: disa node të mëdhenj në klaster apo shumë të vegjël? Si gjithmonë, nuk ka një përgjigje të qartë. Shumëçka varet nga lloji i aplikacionit.
PĂ«r shembull, nĂ«se aplikacioni ka nevojĂ« pĂ«r 10 GB memorie, zgjedhja pĂ«r node tĂ« mĂ«dhenj Ă«shtĂ« e qartĂ«. NdĂ«rsa nĂ«se aplikacioni kĂ«rkon riplikim dhjetĂ«fish pĂ«r akses tĂ« lartĂ«, nuk Ă«shtĂ« pĂ«r t'u rrezikuar duke vendosur replikat vetĂ«m nĂ« dy node â nĂ« klaster duhet tĂ« jenĂ« tĂ« paktĂ«n dhjetĂ« node.
Në situata të ndërmjetme, bëni zgjedhjen tuaj duke u bazuar në avantazhet dhe disavantazhet e çdo opsioni. Mund të ndodhë që disa argumente të jenë më të rëndësishme për situatën tuaj se të tjerët.
Nuk është aspak e nevojshme të keni node të njëjta në madhësi. Asgjë nuk ju ndalon të eksperimentoni fillimisht me node të së njëjtës madhësi dhe më pas të shtoni node me madhësi të ndryshme, duke i kombinuar ato në një klaster. Node të punës në klasterin Kubernetes mund të jenë plotësisht heterogjene. Pra, mund të provoni të kombinoni avantazhet e të dyja qasjeve.
Nuk ka një recetë universale, çdo situatë ka nuancat e veta, dhe vetëm prodhimi do të tregojë të vërtetën.
Përkthimi është përgatitur nga ekipi i platformës cloud .
Më shumë rreth Kubernetes: .
Burimi: habr.com
