Kur krijoni një grup Kubernetes, mund të lindin pyetje: sa nyje punonjëse për të konfiguruar dhe çfarë lloji? Çfarë është më mirë për një grup të brendshëm: blini disa serverë të fuqishëm ose përdorni një duzinë makinash të vjetra në qendrën tuaj të të dhënave? A është më mirë të marrësh tetë shembuj me një bërthamë apo dy katër bërthama në re?
Përgjigjet për këto pyetje janë në artikull. në përkthimin e komandës .
Kapaciteti i grupit
Në përgjithësi, një grup Kubernetes mund të mendohet si një "supernyje" e madhe. Fuqia totale e tij llogaritëse është shuma e fuqive të të gjitha nyjeve përbërëse të saj.
Ka disa mënyra për të arritur objektivin e dëshiruar të kapacitetit të grupit. Për shembull, ne kemi nevojë për një grup me një kapacitet total prej 8 bërthamash procesori dhe 32 GB RAM, sepse një grup aplikacionesh kërkon kaq shumë burime. Më pas mund të instaloni dy nyje me 16 GB memorie ose katër nyje me 8 GB memorie, dy procesorë me katër bërthama ose katër me dy bërthama.
Këtu janë vetëm dy mënyra të mundshme për të krijuar një grup:
Të dy opsionet prodhojnë një grup me të njëjtin kapacitet, por konfigurimi i poshtëm ka katër nyje më të vogla dhe konfigurimi i sipërm ka dy nyje më të mëdha.
Cili opsion është më i mirë?
Për t'iu përgjigjur kësaj pyetjeje, le të shohim avantazhet e të dy opsioneve. Ne i kemi përmbledhur në një tabelë.
Disa nyje të mëdha
Shumë nyje të vogla
Menaxhim më i lehtë i grupimeve (nëse është në premisë)
Shkallëzimi automatik i qetë
Më e lirë (nëse në premisë)
Çmimi është pak i ndryshëm (në re)
Mund të ekzekutojë aplikacione me burime intensive
Përsëritje e plotë
Burimet përdoren në mënyrë më efikase (më pak shpenzime për demonët e sistemit
Tolerancë më e lartë ndaj gabimeve të grupimit
Ju lutemi vini re se ne po flasim vetëm për nyjet e punëtorëve. Zgjedhja e numrit dhe madhësisë së nyjeve kryesore është një temë krejtësisht e ndryshme.
Pra, le të diskutojmë çdo pikë nga tabela në më shumë detaje.
Opsioni i parë: disa nyje të mëdha
Opsioni më ekstrem është një nyje punëtore për të gjithë kapacitetin e grupit. Në shembullin e mësipërm, kjo do të ishte një nyje e vetme punëtore me 16 bërthama CPU dhe 16 GB RAM.
Rekuizitë
Plus nr. 1. Menaxhimi më i lehtë
Është më e lehtë të menaxhosh disa makina sesa një flotë të tërë. Është më e shpejtë për të nxjerrë përditësimet dhe rregullimet dhe është më e lehtë për t'u sinkronizuar. Numri i dështimeve në numra absolut është gjithashtu më i vogël.
Ju lutemi vini re se të gjitha sa më sipër zbatohen për harduerin tuaj, serverët tuaj dhe jo për rastet e resë kompjuterike.
Situata është e ndryshme në re. Atje, menaxhimi trajtohet nga ofruesi i shërbimit cloud. Kështu, menaxhimi i dhjetë nyjeve në re nuk është shumë i ndryshëm nga menaxhimi i një nyjeje.
Drejtimi i trafikut dhe shpërndarja e ngarkesës ndërmjet podeve në re : trafiku që vjen nga interneti dërgohet në balancuesin kryesor të ngarkesës, i cili përcjell trafikun në portin e njërit prej nyjeve (shërbimi NodePort e vendos portën në intervalin 30000-32767 në çdo nyje grupi). Rregullat e vendosura nga kube-proxy ridrejtojnë trafikun nga nyja në pod. Ja se si duket për dhjetë pods në dy nyje:
Pro #2: Më pak kosto për nyje
Një makinë e fuqishme është më e shtrenjtë, por rritja e çmimit nuk është domosdoshmërisht lineare. Me fjalë të tjera, një server me dhjetë bërthama me 10 GB memorie është zakonisht më i lirë se dhjetë serverë me një bërthamë me të njëjtën sasi memorie.
Por vini re se ky rregull zakonisht nuk funksionon në shërbimet cloud. Në skemat aktuale të çmimeve të të gjithë ofruesve kryesorë të cloud, çmimet rriten në mënyrë lineare me kapacitetin.
Kështu, në cloud zakonisht nuk mund të kurseni në serverë më të fuqishëm.
Pro #3: Mund të ekzekutoni aplikacione me burime intensive
Disa aplikacione kërkojnë serverë të fuqishëm në një grup. Për shembull, nëse një sistem i mësimit të makinerive kërkon 8 GB memorie, nuk do të mund ta përdorni në nyje 1 GB, por vetëm me të paktën një nyje të madhe punëtore.
Cons
Disavantazhi nr. 1. Shumë bishtaja për nyje
Nëse e njëjta detyrë kryhet në më pak nyje, atëherë secila prej tyre natyrisht do të ketë më shumë pods.
Ky mund të jetë një problem.
Arsyeja është se çdo modul prezanton disa shpenzime në kohën e ekzekutimit të kontejnerit (p.sh. Docker), si dhe kubelet dhe cAdvisor.
Për shembull, një kubelet kontrollon rregullisht të gjithë kontejnerët në një nyje për mbijetesë - sa më shumë kontejnerë, aq më shumë punë duhet të bëjë kubelet.
CAdvisor mbledh statistika të përdorimit të burimeve për të gjithë kontejnerët në një nyje, dhe kubelet rregullisht kërkon këtë informacion dhe e ofron atë nëpërmjet një API. Përsëri, më shumë kontejnerë do të thotë më shumë punë si për cAdvisor ashtu edhe për kubelet.
Nëse numri i moduleve rritet, mund të ngadalësojë sistemin dhe madje të dëmtojë besueshmërinë e tij.
Në depon e Kubernetes disa që nyjet kalojnë ndërmjet statuseve Ready/NotReady sepse kontrollet e rregullta kubelet të të gjithë kontejnerëve në një nyje zgjasin shumë.
Për këtë arsye Kubernetes . Në varësi të performancës së nyjes, ju mund të ekzekutoni më shumë pods për nyje, por është e vështirë të parashikohet nëse do të ketë probleme apo gjithçka do të funksionojë mirë. Vlen të provoni punën paraprakisht.
Disavantazhi Nr. 2. Kufizimi i përsëritjes
Shumë pak nyje kufizojnë shtrirjen efektive të përsëritjes së aplikacionit. Për shembull, nëse keni një aplikacion me disponueshmëri të lartë me pesë kopje, por vetëm dy nyje, atëherë shkalla efektive e përsëritjes së aplikacionit reduktohet në dy.
Pesë kopje mund të shpërndahen vetëm në dy nyje, dhe nëse njëra prej tyre dështon, ajo do të heqë disa kopje menjëherë.
Nëse keni pesë ose më shumë nyje, secila kopje do të funksionojë në një nyje të veçantë dhe dështimi i një nyjeje do të heqë maksimumi një kopje.
Kështu, kërkesat e disponueshmërisë së lartë mund të kërkojnë një numër minimal të caktuar nyjesh në grup.
Disavantazhi nr. 3. Pasojat më të këqija të dështimit
Me një numër të vogël nyjesh, çdo dështim ka pasoja më serioze. Për shembull, nëse keni vetëm dy nyje dhe njëra prej tyre dështon, gjysma e moduleve tuaja zhduken menjëherë.
Sigurisht, Kubernetes do të migrojë ngarkesën e punës nga nyja e dështuar te të tjerët. Por nëse ka pak prej tyre, atëherë mund të mos ketë kapacitet të mjaftueshëm të lirë. Si rezultat, disa nga aplikacionet tuaja nuk do të jenë të disponueshme derisa të shfaqni nyjen e dështuar.
Kështu, sa më shumë nyje, aq më pak ndikimi i dështimeve të harduerit.
Disavantazhi #4: Më shumë hapa të shkallëzimit automatik
Kubernetes ka një sistem të shkallëzimit automatik të grupimeve për infrastrukturën cloud, i cili ju lejon të shtoni ose hiqni automatikisht nyjet në varësi të nevojave tuaja aktuale. Me nyje më të mëdha, shkallëzimi automatik bëhet më i papritur dhe i ngathët. Për shembull, në dy nyje, shtimi i një nyje shtesë do të rrisë menjëherë kapacitetin e grupit me 50%. Dhe ju do të duhet të paguani për ato burime, edhe nëse nuk keni nevojë për to.
Kështu, nëse planifikoni të përdorni shkallëzimin automatik të grupimeve, sa më të vogla të jenë nyjet, aq më fleksibël dhe me kosto efektive do të keni shkallëzim.
Tani le të shohim avantazhet dhe disavantazhet e një numri të madh nyjesh të vogla.
Opsioni i dytë: shumë nyje të vogla
Përparësitë e kësaj qasjeje rrjedhin në thelb nga disavantazhet e opsionit të kundërt me disa nyje të mëdha.
Rekuizitë
Плюс № 1. Меньше последствия сбоя
Sa më shumë nyje, aq më pak pods në secilën nyje. Për shembull, nëse keni njëqind module për dhjetë nyje, atëherë çdo nyje do të ketë mesatarisht dhjetë module.
Në këtë mënyrë, nëse një nga nyjet dështon, ju humbni vetëm 10% të ngarkesës së punës. Shanset janë që vetëm një numër i vogël kopjesh do të preken dhe aplikacioni i përgjithshëm do të mbetet funksional.
Për më tepër, nyjet e mbetura ka të ngjarë të kenë burime të mjaftueshme të lira për të përballuar ngarkesën e punës së nyjes së dështuar, kështu që Kubernetes mund t'i riplanifikojë lirisht podet dhe aplikacionet tuaja do të kthehen në një gjendje funksionale relativisht shpejt.
Pro #2: Përsëritje e mirë
Nëse ka mjaft nyje, programuesi Kubernetes mund të caktojë nyje të ndryshme për të gjitha kopjet. Në këtë mënyrë, nëse një nyje dështon, vetëm një kopje do të ndikohet dhe aplikacioni do të mbetet i disponueshëm.
Cons
Disavantazhi nr. 1. Vështirë për t'u kontrolluar
Një numër i madh i nyjeve janë më të vështira për t'u menaxhuar. Për shembull, çdo nyje Kubernetes duhet të komunikojë me të gjitha të tjerat, domethënë, numri i lidhjeve rritet në mënyrë kuadratike dhe të gjitha këto lidhje duhet të gjurmohen.
Kontrolluesi i nyjeve në Kubernetes Controller Manager kalon rregullisht nëpër të gjitha nyjet në grup për të kontrolluar shëndetin - sa më shumë nyje, aq më shumë ngarkesë në kontrollues.
Ngarkesa në bazën e të dhënave etcd po rritet gjithashtu - çdo kubelet dhe kube-proxy thirrje për etcd (nëpërmjet API), në të cilën etcd duhet të transmetojë përditësime të objekteve.
Në përgjithësi, çdo nyje punëtore imponon ngarkesë shtesë në komponentët e sistemit të nyjeve kryesore.
Kubernetes zyrtarisht mbështet grupimet me . Sidoqoftë, në praktikë ka tashmë 500 nyje .
Për të menaxhuar një numër të madh nyjesh punëtore, duhet të zgjidhni nyje master më të fuqishme. Për shembull, kube-up madhësia e saktë e VM-së për nyjen kryesore në varësi të numrit të nyjeve punëtore. Kjo do të thotë, sa më shumë nyje punëtore, aq më produktive duhet të jenë nyjet kryesore.
Për zgjidhjen e këtyre problemeve specifike ka zhvillime të veçanta, si p.sh . Ky sistem ju lejon të anashkaloni kufizimet dhe të ndërtoni grupime me një numër të madh të nyjeve të punëtorëve.
Disavantazhi # 2: Më shumë kosto të përgjithshme.
Në çdo nyje të punës, Kubernetes ekzekuton një grup demonësh të sistemit - këto përfshijnë kohën e ekzekutimit të kontejnerit (siç është Docker), kube-proxy dhe kubelet, duke përfshirë cAdvisor. Së bashku ata konsumojnë një sasi të caktuar fikse burimesh.
Nëse keni shumë nyje të vogla, proporcioni i kësaj shpenzimi në secilën nyje është më i madh. Për shembull, imagjinoni që të gjithë demonët e sistemit në një nyje të vetme së bashku përdorin 0,1 bërthama CPU dhe 0,1 GB memorie. Nëse keni një nyje me dhjetë bërthama me 10 GB memorie, atëherë demonët konsumojnë 1% të kapacitetit të grupit. Nga ana tjetër, në dhjetë nyje me një bërthamë me 1 GB memorie, demonët do të marrin 10% të kapacitetit të grupit.
Kështu, sa më pak nyje, aq më efikase përdoret infrastruktura.
Disavantazhi nr. 3. Përdorimi joefikas i burimeve
Në nyjet e vogla, mund të ndodhë që pjesët e mbetura të burimeve janë shumë të vogla për t'u caktuar ndonjë ngarkesë pune, kështu që ato mbeten të papërdorura.
Për shembull, çdo pod kërkon 0,75 GB memorie. Nëse keni dhjetë nyje, secila me 1 GB memorie, mund të ekzekutoni dhjetë pods, duke e lënë çdo nyje me 0,25 GB memorie të papërdorur.
Kjo do të thotë se 25% e kujtesës së të gjithë grupit është e humbur.
Në një nyje të madhe me 10 GB memorie, mund të ekzekutoni 13 nga këto module - dhe do të ketë vetëm një fragment të papërdorur prej 0,25 GB.
Në këtë rast, vetëm 2,5% e memories humbet.
Kështu, burimet përdoren në mënyrë më optimale në nyjet më të mëdha.
Disa nyje të mëdha apo shumë të vogla?
Pra, cila është më mirë: disa nyje të mëdha në një grup apo shumë të vogla? Si gjithmonë, nuk ka një përgjigje të qartë. Shumë varet nga lloji i aplikimit.
Për shembull, nëse një aplikacion kërkon 10 GB memorie, nyjet më të mëdha janë një zgjedhje e qartë. Dhe nëse aplikacioni kërkon përsëritje të dhjetëfishtë për disponueshmëri të lartë, vështirë se ia vlen rreziku i vendosjes së kopjeve në vetëm dy nyje - duhet të ketë të paktën dhjetë nyje në grup.
Në situata të ndërmjetme, bëni një zgjedhje bazuar në avantazhet dhe disavantazhet e secilit opsion. Ndoshta disa argumente janë më të rëndësishme për situatën tuaj sesa të tjerat.
Dhe nuk është aspak e nevojshme që të gjitha nyjet të jenë në të njëjtën madhësi. Asgjë nuk ju pengon që së pari të eksperimentoni me nyje të së njëjtës madhësi, pastaj t'u shtoni nyje të një madhësie të ndryshme, duke i kombinuar ato në një grup. Nyjet e punëtorëve në një grup Kubernetes mund të jenë plotësisht heterogjene. Kështu që mund të përpiqeni të kombinoni avantazhet e të dyja qasjeve.
Nuk ka asnjë recetë të vetme, dhe secila situatë ka nuancat e veta, dhe vetëm prodhimi do të tregojë të vërtetën.
Përkthimi i përgatitur nga ekipi i platformës cloud .
Më shumë rreth Kubernetes: .
Burimi: www.habr.com