Kur krijoni një klaster Kubernetes, mund të lindin pyetje: sa node pune të konfiguroni dhe çfarë lloji? Cila është më e mira për një klaster on-premise: të blini disa serverë të fuqishëm ose të angazhoni një duzinë makinerish të vjetra në qendrën tuaj të të dhënave? Dhe në cloud, është më mirë të merrni tetë instance me një bërthamë ose dy me katër bërthama?
Përgjigjet për këto pyetje janë në artikullin në përkthimin e ekipit .
Kapaciteti i klasterit
Në përgjithësi, një klaster Kubernetes mund të konsiderohet si një "super-node" i madh. Kapaciteti i tij i përgjithshëm të llogaritur është shuma e kapacitetit të të gjithë node-ve 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 total prej 8 bërthamash procesorike dhe 32 GB memorie RAM, sepse grupi i aplikacioneve kërkon një sasi të tillë burimesh. Atëherë mund të instaloni dy node me 16 GB memorie ose katër node me 8 GB memorie, dy procesorë katër bërthamorë ose katër procesorë me dy bërthama.
Ja vetëm dy mënyra të mundshme për të krijuar një klaster:
Të dy opsionet ofrojnë një klaster me të njëjtin kapacitet, por në konfigurimin më poshtë janë vendosur katër node më të vogla, ndryshe nga konfigurimi më sipër me dy node më të mëdhenj.
Cila është alternativa më e mirë?
Për t'iu përgjigjur këtij pyetje, le të shqyrtojmë avantazhet e të dy opsioneve. I kemi paraqitur ato në një tabelë.
Disa node të mëdhenj
Shumë node të vogla
Menaxhimi i klasterit është më i thjeshtë (nëse është on-premise)
Autoskalarimi funksionon më mirë
Më lirë (nëse është on-premise)
Ămimi ndonjĂ«herĂ« Ă«shtĂ« i ngjashĂ«m (nĂ« cloud)
Mund të ekzekutoni aplikacione me burime të rënda
Replikimi i plotë
Burimet përdoren më efikasishëm (me më pak overhead për demonët e sistemit)
Qëndrueshmëria e klasterit është më e lartë
Vini re se po flasim vetëm për node punuese. Zgjedhja e numrit dhe madhësisë së node-ve kryesor është një temë krejtësisht tjetër.
Pra, le të diskutojmë më në detaje për secilën pikë nga tabela.
Opsioni i parë: disa node të mëdhenj
Opsioni më ekstrem është një node pune për të gjithë kapacitetin e klasterit. Në shembullin lart, kjo do të ishte një node pune me 16 bërthama CPU dhe 16 GB memorie RAM.
Pikat pozitive
Avantazhi # 1. Menaxhimi është më i thjeshtë
ĂshtĂ« mĂ« e lehtĂ« tĂ« menaxhosh disa makina sesa tĂ« menaxhosh njĂ« park tĂ« tĂ«rĂ«. Aktualizimet dhe rregullimet realizohen mĂ« shpejt, dhe sinkronizimi Ă«shtĂ« mĂ« i thjeshtĂ«. Numri i ndĂ«rprerjeve nĂ« shifra absolute Ă«shtĂ« gjithashtu mĂ« i vogĂ«l.
Kujdes, gjithë kjo e thënë është për harduerin tuaj, për serverët tuaj, dhe jo për instancat cloud.
Situata në cloud është ndryshe. Atje menaxhimi bëhet nga ofruesi i shërbimeve cloud. Pra, menaxhimi i dhjetë nyjave në cloud nuk ndryshon shumë nga menaxhimi i një nyje.
Routimi i trafikut dhe shpërndarja e ngarkesës midis pod-ëve në cloud : trafiku që vjen nga interneti drejtohet në balancuesin kryesor të ngarkesës, i cili e drejton trafikun në portin e një nga nyjave (shërbimi NodePort vendos një port në intervalin 30000-32767 në çdo nyje të klasterit). Rregullat e themeluara nga kube-proxy e ridrejtojnë trafikun nga nyja në pod. Kështu duket për dhjetë pod në dy nyje:
Pika e dytë. Më pak shpenzime për nyje
Një makinë e fuqishme është më e shtrenjtë, por rritja e çmimit nuk është domosdoshmërisht lineare. Në fjalë të tjera, një server me dhjetë të bërthamave me 10 GB RAM zakonisht është më i lirë se dhjetë një-bërthamash me të njëjtin sasi RAM.
Por kujdes, kjo rregull është zakonisht e pavlefshme në shërbimet cloud. Në skemat aktuale të çmimit, te të gjithë ofruesit kryesorë të shërbimeve cloud, çmimet rriten linearisht me rritjen e kapacitetit.
Pra, në cloud zakonisht nuk mund të kursesh për serverë më të fuqishëm.
Pika e tretë. Mund të nisni aplikacione kërkuese të resurseve
Disa aplikacione kërkojnë serverë të fuqishëm në klaster. Për shembull, nëse një sistem mësimi të makinerisë kërkon 8 GB RAM, nuk mund ta nisin atë në nyja me 1 GB, por vetëm nëse ka të paktën një nyje të madhe pune.
Disavantazhet
Minus i parë. Shumë pod në nyje
Nëse e njëjta detyrë ekzekutohet në një numër më të vogël nyjash, atëherë natyrisht që në secilën prej tyre do të ketë më shumë pod.
Kjo mund të bëhet një problem.
Arsyeja është se çdo modul sjell disa të dhëna mbi overhead-in në ambientin e ekzekutimit të kontejnerëve (p.sh., Docker), si dhe në kubelet dhe cAdvisor.
Për shembull, kubelet rregullisht vërteton qëndrueshmërinë e të gjithë kontejnerëve në nyjë - sa më shumë kontejnerë, aq më shumë punë për kubelet.
CAdvisor mbledh statistika për përdorimin e resurseve të të gjitha kontejnerëve në nod, ndërsa kubelet kërkon rregullisht këtë informacion dhe e ofron atë përmes API. Sërish, sa më shumë kontejnerë, aq më shumë punë për cAdvisor dhe kubelet.
Nëse numri i moduleve rritet, kjo mund të ngadalësojë sistemin dhe madje ta dëmtojë besueshmërinë e tij.
Në depoja Kubernetes disa , që nodet lëvizin ndërmjet statusit Ready/NotReady, pasi kontrollet e rregullta të kubelet për të gjithë kontejnerët në nod kërkojnë shumë kohë.
PĂ«r kĂ«tĂ« arsye, Kubernetes . NĂ« varĂ«si tĂ« performancĂ«s sĂ« nodit, mund tĂ« ekzekutoni mĂ« shumĂ« pod-e nĂ« nod, por Ă«shtĂ« e vĂ«shtirĂ« tĂ« parashikohet nĂ«se do tĂ« ketĂ« probleme apo do tĂ« funksionojĂ« mirĂ«. ĂshtĂ« mirĂ« ta testoni paraprakisht.
Minus Nr. 2. Kufizimi i replikimit
Numri shumë i vogël i nodve kufizon shkallën efektive të replikimit të aplikacioneve. Për shembull, nëse keni një aplikacion me disponueshmëri të lartë me pesë replika, por vetëm dy nod, atëherë shkalla efektive e replikimit të aplikacionit zvogëlohet në dy.
Pesë replika mund të shpërndahen vetëm në dy nod, dhe nëse një nga ato dështon, menjëherë dëmton disa replika.
Nëse keni pesë nod ose më shumë, çdo replikë do të ekzekutohet në një nod të veçantë, dhe dështimi i një nodi do të eliminojë maksimum një replikë.
Kështu, kërkesat për disponueshmëri të lartë mund të kërkojnë një numër minimal nodesh në klaster.
Minus Nr. 3. Pasojat më të këqija të dështimit
Me një numër të vogël nodesh, çdo dështim sjell pasoja më të rënda. Për shembull, nëse keni vetëm dy nod, dhe një prej tyre dështon, menjëherë humbet gjysmën e moduleve tuaja.
Natyrisht, Kubernetes do ta transferojë ngarkesën e punës nga nodi i dështuar në të tjerët. Por nëse ato janë të pakta, mund të mos ketë kapacitet të mjaftueshëm të lirë. Si rezultat, disa nga aplikacionet tuaja do të jenë të paqasshme derisa të ngrihet nodi i dështuar.
Pra, aq më shumë nodet, aq më pak ndikimi i dështimeve harduese.
Minus Nr. 4. Më shumë hapa të automatikës
Në Kubernetes funksionon një sistem i automatikës për shkallëzimin e klastereve për infrastrukturën cloud, i cili lejon shtimin ose heqjen automatikisht të nyjave në varësi të nevojave aktuale. Me nyje të mëdha, shkallëzimi bëhet më abrupt dhe i ngathët. Për shembull, nëse keni dy nyje, shtimi i një nyje të re do të rrisë kapacitetin e klasterit menjëherë me 50%. Dhe do t'ju duhet të paguani për këto burime, edhe nëse nuk i nevojiten.
Prandaj, nĂ«se planifikoni tĂ« pĂ«rdorni automatikĂ«n pĂ«r shkallĂ«zimin e klasterit, aq mĂ« tĂ« vogla tĂ« jenĂ« nyjat â aq mĂ« fleksibĂ«l dhe ekonomik do tĂ« jetĂ« shkallĂ«zimi.
Tani le të shqyrtojmë avantazhet dhe disavantazhet e një numri të madh nyjash të vogla.
Varianti i dytë: shumë nyje të vogla
Përfitimet e këtij qasjeje, në thelb, rrjedhin nga disavantazhet e variantit të kundërt me disa nyje të mëdha.
Pikat pozitive
PĂ«rfitimi â 1. MĂ« pak pasojat e dĂ«shtimit
Sa më shumë nyje, aq më pak podë 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.
Prandaj, nëse një nga nyjat dështon, humbni vetëm 10% të ngarkesës së punës. Ekziston mundësia që të ndikohen vetëm disa kopje, ndërsa aplikacionet si një e tërë të mbeten në gjendje funksionimi.
Për më tepër, në nyjat e mbetura, me siguri do të ketë resurse të mjaftueshme për ngarkesën e punës së nyjës në dështim, kështu që Kubernetes mund ta riplanojë lehtësisht podët tuaj, dhe aplikacionet tuaja do të rikthehen në gjendje funksionimi relativisht shpejt.
PĂ«rfitimi â 2. Replikim i mirĂ«
Nëse ka mjaft nyje, planifikuesi i Kubernetes-it mund të caktojë të gjitha kopjet në nyje të ndryshme. Kështu, në rastin e dështimit të nyjës, do të preket vetëm një kopje, ndërsa aplikacioni do të mbetet i aksesueshëm.
Disavantazhet
Disavantazhi â 1. MĂ« e vĂ«shtirĂ« pĂ«r menaxhim
Me një numër të madh nyjash është më e vështirë të menaxhosh. Për shembull, çdo nyje e Kubernetes-it duhet të ndërveprojë me të gjitha nyjat e tjera, dmth numri i lidhjeve rritet katror dhe të gjitha këto lidhje duhet të monitorohen.
Kontrolluesi i nyjave nĂ« menaxherin e kontrolluesve tĂ« Kubernetes-it inspekton rregullisht tĂ« gjitha nyjat nĂ« klaster pĂ«r tĂ« kontrolluar shĂ«ndetin â sa mĂ« shumĂ« nyje, aq mĂ« e madhe ngarkesa mbi kontrolluesin.
Ngarkohet gjithashtu edhe database etctd â çdo kubelet dhe kube-proxy thĂ«rret pĂ«r etcd (nĂ«pĂ«rmjet API), tĂ« cilit etcd duhet tĂ« transmetojĂ« azhurnimet e objektit.
Në përgjithësi, çdo nyje punuese ngarkon më shumë komponentët sistemorë të nyjave kryesore.
Zyrtarisht, Kubernetes mbështet klastere me . Megjithatë, në praktikë, tashmë 500 nyje .
Për të menaxhuar një numër të madh nyjesh punuese, duhet të zgjidhni nyje kryesore më të fuqishme. Për shembull, kube-up madhësinë e duhur të VM për nyjën kryesore në varësi të numrit të nyjeve punuese. Kështu, sa më shumë nyje punuese, aq më të fuqishme duhet të jenë nyjet kryesore.
Për të zgjidhur këto probleme specifike, ekzistojnë zhvillime speciale, si . Ky sistem lejon shmangien e kufizimeve dhe ndërtimin e klastereve me një numër të madh nyjesh punuese.
Disavantazhi Nr. 2. Më shumë overhead
NĂ« çdo nyje punuese, Kubernetes ekzekuton njĂ« grup demonĂ«sh sistemorĂ« â kĂ«tu pĂ«rfshihet mjedisi i ekzekutimit tĂ« kontejnerĂ«ve (p.sh., Docker), kube-proxy dhe kubelet, duke pĂ«rfshirĂ« cAdvisor. TĂ« gjitha sĂ« bashku konsumojnĂ« njĂ« sasi tĂ« caktuar tĂ« burimeve.
Nëse keni shumë nyje të vogla, përqindja e këtij overheadi në çdo nyje është më e madhe. Për shembull, imagjinoni se të gjithë demonët sistemorë të një nyje së bashku përdorin 0,1 bërthamë CPU dhe 0,1 GB memorie. Nëse keni një nyje me dhjetë bërthama dhe 10 GB memorie, demons do të konsumojnë 1% të kapacitetit të klasterit. Nga ana tjetër, në dhjetë nyje me një bërthamë dhe 1 GB memorie, demons do të marrin 10% të kapacitetit të klasterit.
Prandaj, sa më pak nyje të keni, aq më efikasisht shfrytëzohet infrastruktura.
Disavantazhi Nr. 3. Shfrytëzim joefikas i burimeve
Në nyje të vogla mund të ndodhë që fragmente të mbetura të burimeve të jenë shumë të vogla për t'u caktuar një ngarkesë pune, kështu që ato mbeten të paqartuara.
PĂ«r shembull, çdo pod kĂ«rkon 0,75 GB memorie. NĂ«se keni dhjetĂ« nyje dhe nĂ« secilĂ«n 1 GB memorie, mund tĂ« ekzekutoni dhjetĂ« podâe â kĂ«shtu, nĂ« secilĂ«n nyje do tĂ« mbetet 0,25 GB memorie tĂ« pashfrytĂ«zuar.
Kjo do të thotë se 25% e memories së gjithë klasterit shkon kot.
NĂ« njĂ« nyje tĂ« madhe me 10 GB memorie, mund tĂ« ekzekutoni 13 tĂ« tilla module â dhe do tĂ« mbetet vetĂ«m njĂ« fragment i pashfrytĂ«zuar 0,25 GB.
Në këtë rast, vetëm 2,5% e memories po shpenzohet kot.
Prandaj, në nyjat e mëdha shfrytëzohen më optimalisht burimet.
Disa nyje të mëdha apo shumë të vogla?
Pra, çfarë është më mirë: disa nyje të mëdha në klaster apo shumë të vogla? Si gjithmonë, nuk ka një përgjigje të qartë. Shumë varet nga lloji i aplikacionit.
PĂ«r shembull, nĂ«se aplikacioni kĂ«rkon 10 GB memorie, zgjedhja Ă«shtĂ« e qartĂ« nĂ« favor tĂ« nyjeve tĂ« mĂ«dha. Por nĂ«se aplikacioni kĂ«rkon njĂ« riprodhim dhjetĂ«fish pĂ«r disponueshmĂ«ri tĂ« lartĂ«, ndoshta nuk ia vlen tĂ« rrezikoni duke vendosur replikat nĂ« vetĂ«m dy nyje â nĂ« klaster duhet tĂ« ketĂ« tĂ« paktĂ«n dhjetĂ« nyje.
Në situata ndërmjetëse, bëni zgjedhjen tuaj duke u bazuar në avantazhet dhe disavantazhet e secilës mundësi. Ndoshta disa argumente janë më relevante për situatën tuaj se të tjerat.
Dhe nuk është e nevojshme të keni të gjitha nyjet të njëjtës madhësi. Asgjë nuk ju pengon të eksperimentoni fillimisht me nyje të një madhësie, pastaj t'i shtoni ato nyje të një madhësie tjetër, duke i kombinuar në klaster. Nyjet e punës në klasterin Kubernetes mund të jenë plotësisht heterogjene. Kështu që mund ta provoni kombinimin e avantazheve të të dy qasjeve.
Nuk ekziston një recetë e vetme, dhe çdo situatë ka nuancat e saj, dhe vetëm prodhimi do të tregojë të vërtetën.
Përkthimi është përgatitur nga ekipi i platformës cloud .
Më shumë për Kubernetes: .
Burimi: habr.com
