Kubernetes kluster bat sortzean, galderak sor daitezke: zenbat langile-nodo konfiguratu eta zer mota? Zer da hobea kluster lokal batentzat: erosi hainbat zerbitzari indartsu edo erabili dozena bat makina zahar zure datu-zentroan? Hobea al da nukleo bakarreko zortzi instantzia edo bi nukleo laukoa hodeian hartzea?
Galdera hauen erantzunak artikuluan daude. komandoaren itzulpenean .
Kluster-ahalmena
Oro har, Kubernetes kluster bat "supernodo" handi bat dela pentsa daiteke. Bere konputazio-potentzia osoa bere nodo guztien potentziaren batura da.
Nahi duzun kluster-ahalmenaren helburua lortzeko hainbat modu daude. Esaterako, 8 prozesadore nukleo eta 32 GB RAM edukiera osoa duen cluster bat behar dugu, aplikazio multzo batek baliabide asko behar dituelako. Ondoren, 16 GB-ko memoria duten bi nodo edo 8 GB-ko lau nodo instala ditzakezu, quad-core prozesadore bi edo lau dual-core.
Hona hemen kluster bat sortzeko bi modu posible:
Bi aukerak edukiera bereko kluster bat sortzen dute, baina beheko konfigurazioak lau nodo txikiago ditu eta goiko konfigurazioak bi nodo handiagoak ditu.
Zein aukera da hobea?
Galdera honi erantzuteko, ikus ditzagun bi aukeren abantailak. Taula batean laburbildu ditugu.
Hainbat nodo handi
Nodo txiki asko
Kluster kudeaketa errazagoa (lokalean badago)
Autoeskalatze leuna
Merkeagoa (lokalean badago)
Prezioa apur bat desberdina da (hodeian)
Baliabide intentsiboko aplikazioak exekutatu ditzake
Erreplika osoa
Baliabideak eraginkorrago erabiltzen dira (gastu gutxiago sistemaren daemonetan
Klusterren akatsen tolerantzia handiagoa
Kontuan izan langile-nodoez soilik ari garela. Nodo nagusien kopurua eta tamaina aukeratzea guztiz bestelako gaia da.
Beraz, eztabaida ditzagun mahaiko puntu bakoitza zehatzago.
Lehen aukera: hainbat nodo handi
Muturreko aukera klusterren gaitasun osorako langile-nodo bat da. Goiko adibidean, 16 CPU nukleo eta 16 GB RAM dituen langile-nodo bakarra izango litzateke.
Pros
Plus 1. zenbakia. Kudeaketa errazagoa
Errazagoa da makina batzuk kudeatzea flota osoa baino. Azkarragoa da eguneratzeak eta konponketak zabaltzea, eta errazagoa da sinkronizatzea. Zenbaki absolutuetan hutsegiteen kopurua ere txikiagoa da.
Kontuan izan aurreko guztia zure hardwareari, zerbitzariei eta ez hodeiko instantziei aplikatzen zaiela.
Egoera bestelakoa da hodeian. Bertan, hodeiko zerbitzu hornitzaileak kudeatzen du kudeaketa. Beraz, hodeian hamar nodo kudeatzea ez da oso desberdina nodo bat kudeatzearekin.
Trafikoaren bideratzea eta karga banatzea hodeian dauden poden artean : Internetetik datorren trafikoa karga-orekatzaile nagusira bidaltzen da, eta horrek nodoetako baten atakara birbidaltzen du trafikoa (NodePort zerbitzuak 30000-32767 tartean ezartzen du kluster nodo bakoitzean). Kube-proxy-k ezarritako arauek nodotik podra birbideratzen dute trafikoa. Hona hemen bi nodotan dauden hamar lekaren itxura:
Pro # 2: Nodo bakoitzeko kostu gutxiago
Auto indartsua garestiagoa da, baina prezioaren igoera ez da zertan lineala izan. Beste era batera esanda, 10 GB-ko memoria duen hamar nukleoko zerbitzari bat memoria kopuru bera duten nukleo bakarreko hamar zerbitzari baino merkeagoa izan ohi da.
Baina kontuan izan arau honek ez duela normalean hodeiko zerbitzuetan funtzionatzen. Hodei-hornitzaile nagusi guztien egungo prezioen eskemetan, prezioak modu linealki igotzen dira ahalmenarekin.
Horrela, hodeian normalean ezin duzu zerbitzari indartsuagoetan gorde.
Pro #3: Baliabide askoko aplikazioak exekutatu ditzakezu
Aplikazio batzuek zerbitzari indartsuak behar dituzte kluster batean. Adibidez, ikaskuntza automatikoko sistema batek 8 GB memoria behar badu, ezin izango duzu exekutatu 1 GBko nodoetan, baina gutxienez langile nodo handi batekin bakarrik.
Cons
Desabantaila 1. zenbakia. Nodo bakoitzeko lekak asko
Zeregin bera nodo gutxiagotan egiten bada, orduan horietako bakoitzak berez izango ditu leka gehiago.
Hau arazo bat izan daiteke.
Arrazoia da modulu bakoitzak gainkostu batzuk sartzen dituela edukiontzien exekuzioan (adibidez, Docker), baita kubelet eta cAdvisor ere.
Adibidez, kubelet batek aldizka nodo bateko edukiontzi guztiak zundatzen ditu bizirauteko, zenbat eta edukiontzi gehiago, orduan eta lan gehiago egin behar du kubeletak.
CAdvisor-ek nodo bateko edukiontzi guztien baliabideen erabilera-estatistikak biltzen ditu, eta kubelet-ek aldizka informazio hori kontsultatzen du eta API baten bidez ematen du. Berriz ere, edukiontzi gehiagok lan gehiago esan nahi du bai cAdvisor eta bai kubeletentzat.
Modulu kopurua handitzen bada, sistema moteldu eta fidagarritasuna ere ahuldu dezake.
Kubernetes biltegian batzuk Nodoek Prest/Ez Prest egoeren artean salto egiten dutela, nodo bateko edukiontzi guztien kubelet-en ohiko egiaztapenek luzeegia hartzen baitute.
Horregatik Kubernetes . Nodoaren errendimenduaren arabera, nodo bakoitzeko pod gehiago exekutatu ditzakezu, baina zaila da aurreikustea arazoak egongo diren edo dena ondo funtzionatuko duen. Merezi du lana aldez aurretik probatzea.
Desabantaila zk. 2. Erreplikazioaren muga
Nodo gutxiegik mugatzen dute aplikazioaren erreplikazioaren hedadura eraginkorra. Esate baterako, erabilgarritasun handiko aplikazioa bost erreplika baina bi nodo baino ez badituzu, orduan aplikazioaren erreplikazio-maila eraginkorra bitara murriztuko da.
Bost erreplika bi nodotan bakarrik banatu daitezke, eta horietako batek huts egiten badu, hainbat erreplika kenduko ditu aldi berean.
Bost nodo edo gehiago badituzu, erreplika bakoitza nodo bereizi batean exekutatuko da, eta nodo baten hutsegiteak gehienez erreplika bat kenduko du.
Beraz, erabilgarritasun handiko eskakizunek klusterreko gutxieneko nodo kopuru jakin bat eska dezakete.
Desabantaila 3. zenbakia. Porrotaren ondorio okerragoak
Nodo kopuru txiki batekin, hutsegite bakoitzak ondorio larriagoak ditu. Adibidez, bi nodo baino ez badituzu eta horietako batek huts egiten badu, zure moduluen erdiak berehala desagertuko dira.
Jakina, Kubernetes-ek lan-karga huts egin duen nodotik beste batzuetara migratuko du. Baina horietako gutxi badira, baliteke doako edukiera nahikoa ez egotea. Ondorioz, zure aplikazioetako batzuk ez dira erabilgarri egongo huts egin duen nodoa agertu arte.
Horrela, zenbat eta nodo gehiago, orduan eta eragin txikiagoa izango dute hardware-akatsek.
4. desabantaila: eskalatze automatikoko urrats gehiago
Kubernetes-ek hodeiko azpiegiturarako kluster eskalatze automatikoko sistema bat du, eta horrek automatikoki gehitzeko edo kentzeko aukera ematen dizu nodoak uneko beharren arabera. Nodo handiagoekin, eskalatze automatikoa bapatagoa eta traketsagoa bihurtzen da. Adibidez, bi nodotan, nodo gehigarri bat gehitzeak klusterren ahalmena % 50 handituko du berehala. Eta baliabide horiek ordaindu beharko dituzu, behar ez badituzu ere.
Horrela, kluster eskalatze automatikoa erabiltzeko asmoa baduzu, zenbat eta nodo txikiagoak izan, orduan eta eskalatze malguagoa eta errentagarriagoa lortuko duzu.
Orain ikus ditzagun nodo txiki kopuru handi baten abantailak eta desabantailak.
Bigarren aukera: nodo txiki asko
Ikuspegi honen abantailak, funtsean, hainbat nodo handi dituen kontrako aukeraren desabantailetatik datoz.
Pros
Pro # 1: Porrotaren eragin txikiagoa
Zenbat eta nodo gehiago, orduan eta lek gutxiago nodo bakoitzean. Adibidez, hamar nodo bakoitzeko ehun modulu badituzu, orduan nodo bakoitzak hamar modulu izango ditu batez beste.
Horrela, nodoren batek huts egiten badu, lan-kargaren % 10 baino ez duzu galtzen. Litekeena da erreplika kopuru txiki bat baino ez izatea eta aplikazio orokorra funtzionatzen jarraitzea.
Gainera, gainerako nodoek doako baliabide nahikoa izango dute huts egin duen nodoaren lan-karga kudeatzeko, beraz Kubernetes-ek libreki berrantola ditzake podak eta zure aplikazioak nahiko azkar itzuliko dira egoera funtzional batera.
Pro # 2: Erreplikazio ona
Nodo nahikoa badago, Kubernetes programatzaileak nodo desberdinak eslei ditzake erreplika guztiei. Horrela, nodo batek huts egiten badu, erreplika bakarra eragingo du eta aplikazioa erabilgarri egongo da.
Cons
Desabantaila 1. zenbakia. Kontrolatzeko zaila
Nodo kopuru handiak kudeatzeko zailagoa da. Esaterako, Kubernetes nodo bakoitzak beste guztiekin komunikatu behar du, hau da, konexio kopurua koadratikoki hazten da, eta konexio horiei guztiei jarraipena egin behar zaie.
Kubernetes Controller Manager-eko nodo-kontrolatzaileak aldizka klusterreko nodo guztiak zeharkatzen ditu osasuna egiaztatzeko: zenbat eta nodo gehiago, orduan eta karga gehiago kontrolagailuak.
Etcd datu-basearen karga ere hazten ari da - kubelet eta kube-proxy dei bakoitza etcd-rako (APIaren bidez), etcd-k nori bidali behar dizkion objektuen eguneraketak.
Oro har, langile-nodo bakoitzak karga gehigarria ezartzen die nodo nagusien sistemaren osagaiei.
Kubernetes-ek klusterrak onartzen ditu ofizialki . Hala ere, praktikan dagoeneko 500 nodo daude .
Langile-nodo ugari kudeatzeko, nodo nagusi indartsuagoak aukeratu behar dituzu. Adibidez, kube-up nodo nagusirako VM tamaina zuzena langile-nodo kopuruaren arabera. Hau da, zenbat eta langile-nodo gehiago, orduan eta produktiboagoak izan beharko lukete nodo nagusiek.
Arazo zehatz hauek konpontzeko garapen bereziak daude, esaterako . Sistema honek murrizketak saihestu eta langile-nodo ugari dituzten klusterrak eraikitzeko aukera ematen du.
2. desabantaila: gastu orokorrak gehiago.
Langile-nodo bakoitzean, Kubernetes-ek sistema-deabru multzo bat exekutatzen du; horien artean daude edukiontziaren exekuzio-denbora (adibidez, Docker), kube-proxy eta kubelet, cAdvisor barne. Elkarrekin baliabide finko jakin bat kontsumitzen dute.
Nodo txiki asko badituzu, nodo bakoitzean gainkostu horren proportzioa handiagoa da. Adibidez, imajinatu nodo bakarreko sistema-daemon guztiek batera 0,1 CPU nukleo eta 0,1 GB memoria erabiltzen dituztela. 10 GB-ko memoria duen hamar nukleoko nodo bat baduzu, deabruek klusterraren edukieraren %1 kontsumitzen dute. Bestalde, 1 GB-ko memoria duten nukleo bakarreko hamar nodotan, deabruek klusterraren edukieraren %10 hartuko dute.
Horrela, zenbat eta nodo gutxiago, orduan eta eraginkorrago erabiltzen da azpiegitura.
Desabantaila 3. zenbakia. Baliabideen erabilera ez eraginkorra
Nodo txikietan, baliteke gainerako baliabide-zatiak txikiegiak izatea edozein lan-karga esleitzeko, beraz, erabili gabe gelditzea.
Adibidez, pod bakoitzak 0,75 GB memoria behar du. Hamar nodo badituzu, bakoitza 1 GB memoriarekin, hamar pod exekutatu ditzakezu, nodo bakoitza 0,25 GB erabili gabeko memoriarekin utziz.
Horrek esan nahi du kluster osoaren memoriaren %25 alferrik galtzen dela.
10 GB-ko memoria duen nodo handi batean, modulu horietako 13 exekutatu ditzakezu, eta erabili gabeko 0,25 GBko zati bakarra egongo da.
Kasu honetan, memoriaren %2,5 baino ez da alferrik galtzen.
Horrela, baliabideak modu egokiagoan erabiltzen dira nodo handietan.
Hainbat nodo handi ala txiki asko?
Beraz, zein da hobea: nodo handi batzuk kluster batean edo txiki asko? Beti bezala, ez dago erantzun argirik. Asko dago aplikazio motaren arabera.
Adibidez, aplikazio batek 10 GB memoria behar badu, nodo handiagoak aukera bistakoa dira. Eta aplikazioak hamar aldiz erreplikatzea eskatzen badu erabilgarritasun handia lortzeko, ia ez du merezi erreplikak bi nodotan soilik jartzeko arriskuak; gutxienez hamar nodo egon behar dira klusterrean.
Tarteko egoeretan, egin aukera bakoitzaren abantailetan eta desabantailetan oinarrituta. Baliteke argudio batzuk zure egoerari beste batzuk baino garrantzitsuagoak izatea.
Eta ez da batere beharrezkoa nodo guztiak tamaina berekoak izatea. Ezerk ez dizu eragozten lehenik tamaina bereko nodoekin esperimentatzea, gero haiei tamaina ezberdineko nodoak gehitzea, kluster batean konbinatuz. Kubernetes kluster bateko langile-nodoak guztiz heterogeneoak izan daitezke. Beraz, bi ikuspegien abantailak konbinatzen saiatu zaitezke.
Ez dago errezeta bakarra, eta egoera bakoitzak bere Γ±abardurak ditu, eta ekoizpenak bakarrik erakutsiko du egia.
Hodeiko plataformako taldeak prestatutako itzulpena .
Kubernetes-i buruz gehiago: .
Iturria: www.habr.com