Dum kreado de Kubernetes-areo, povas ekesti demandoj: kiom da labornodoj agordu kaj kian tipon? Kio estas pli bona por surloka areto: aĉetu plurajn potencajn servilojn aŭ uzu dekduon da malnovaj maŝinoj en via datumcentro? Ĉu estas pli bone preni ok unu-kernajn aŭ du kvar-kernajn okazojn en la nubo?
La respondoj al ĉi tiuj demandoj estas en la artikolo. en la traduko de la ordono .
Kapacito de areto
Ĝenerale, Kubernetes-areto povas esti opiniita kiel granda "supernodo". Ĝia totala komputa potenco estas la sumo de la potencoj de ĉiuj ĝiaj konsistigaj nodoj.
Estas pluraj manieroj atingi vian deziratan grapolkapacitan celon. Ekzemple, ni bezonas areton kun totala kapacito de 8 procesoraj kernoj kaj 32 GB da RAM ĉar aro da aplikoj postulas tiom da rimedoj. Tiam vi povas instali du nodojn kun 16 GB da memoro aŭ kvar nodojn kun 8 GB da memoro, du kvar-kernaj procesoroj aŭ kvar dukernaj.
Jen nur du eblaj manieroj krei areton:
Ambaŭ opcioj produktas areton kun la sama kapacito, sed la malsupra agordo havas kvar pli malgrandajn nodojn kaj la supra agordo havas du pli grandajn nodojn.
Kiu opcio estas pli bona?
Por respondi ĉi tiun demandon, ni rigardu la avantaĝojn de ambaŭ opcioj. Ni resumis ilin en tabelo.
Pluraj grandaj nodoj
Multaj malgrandaj nodoj
Pli facila administrado de clusteroj (se ĝi estas surloke)
Glata aŭtoskalado
Pli malmultekosta (se surloke)
La prezo estas iomete malsama (en la nubo)
Povas ruli rimedojn-intensajn aplikojn
Plena reproduktado
Rimedoj estas uzataj pli efike (malpli supre sur sistemaj demonoj
Pli alta grupa faŭltoleremo
Bonvolu noti, ke ni parolas nur pri labornodoj. Elekti la nombron kaj grandecon de ĉefaj nodoj estas tute alia temo.
Do, ni diskutu ĉiun punkton de la tabelo pli detale.
Unua opcio: pluraj grandaj nodoj
La plej ekstrema opcio estas unu labornodo por la tuta grapolkapacito. En la supra ekzemplo, ĉi tio estus ununura laborista nodo kun 16 CPU-kernoj kaj 16 GB da RAM.
Puloj
Plus n-ro 1. Pli facila administrado
Estas pli facile administri kelkajn maŝinojn ol tutan floton. Estas pli rapide eldoni ĝisdatigojn kaj korektojn, kaj estas pli facile sinkronigi. La nombro da fiaskoj en absolutaj nombroj ankaŭ estas malpli granda.
Bonvolu noti, ke ĉio ĉi-supra validas por via aparataro, viaj serviloj, kaj ne por nubaj petskriboj.
La situacio estas malsama en la nubo. Tie, la administrado estas pritraktata de la provizanto de nuba servo. Tiel, administri dek nodojn en la nubo ne multe diferencas de administri unu nodon.
Trafikvojigo kaj ŝarĝo-distribuo inter podoj en la nubo : trafiko venanta de la Interreto estas sendita al la ĉefa ŝarĝbalancilo, kiu plusendas trafikon al la haveno de unu el la nodoj (la NodePort-servo fiksas la havenon en la intervalo 30000-32767 en ĉiu clusternodo). La reguloj starigitaj de kube-proxy alidirektas trafikon de la nodo al la pod. Jen kiel ĝi aspektas por dek balgoj sur du nodoj:
Profesiulo #2: Malpli kosto por nodo
Potenca aŭto estas pli multekosta, sed la prezaltiĝo ne nepre estas lineara. Alivorte, unu dek-kerna servilo kun 10 GB da memoro estas kutime pli malmultekosta ol dek unukernaj serviloj kun la sama kvanto de memoro.
Sed notu, ke ĉi tiu regulo kutime ne funkcias en nubaj servoj. En la nunaj prezaj skemoj de ĉiuj ĉefaj nubaj provizantoj, prezoj pliiĝas linie kun kapablo.
Tiel, en la nubo oni kutime ne povas ŝpari sur pli potencaj serviloj.
Profesiulo #3: Vi povas ruli rimedojn-intensajn aplikojn
Iuj aplikoj postulas potencajn servilojn en areto. Ekzemple, se maŝinlernada sistemo postulas 8 GB da memoro, vi ne povos ruli ĝin sur 1 GB-nodoj, sed nur per almenaŭ unu granda laborista nodo.
Miksoj
Malavantaĝo n-ro 1. Multaj balgoj po nodo
Se la sama tasko estas farita sur malpli da nodoj, tiam ĉiu el ili nature havos pli da podoj.
Ĉi tio povus esti problemo.
La kialo estas, ke ĉiu modulo enkondukas iom da ŝarĝo al la ujo rultempo (ekz. Docker), same kiel la kubelet kaj cAdvisor.
Ekzemple, kubelet regule sondas ĉiujn ujojn sur nodo por pluviveco—ju pli da ujoj, des pli da laboro devas fari la kubelet.
CAdvisor kolektas statistikojn pri uzado de rimedoj por ĉiuj ujoj sur nodo, kaj kubelet regule demandas ĉi tiujn informojn kaj provizas ĝin per API. Denove, pli da ujoj signifas pli da laboro por kaj cAdvisor kaj kubelet.
Se la nombro da moduloj pliiĝas, ĝi povas malrapidigi la sistemon kaj eĉ subfosi ĝian fidindecon.
En la deponejo de Kubernetes iuj ke nodoj saltas inter Preta/NePreta statusoj ĉar regulaj kubeletkontroloj de ĉiuj ujoj sur nodo daŭras tro longe.
Tial Kubernetes . Depende de la agado de la nodo, vi povas ruli pli da podoj per nodo, sed estas malfacile antaŭdiri ĉu estos problemoj aŭ ĉio funkcios bone. Indas testi la laboron anticipe.
Malavantaĝo n-ro 2. Limigo pri reproduktado
Tro malmultaj nodoj limigas la efikan amplekson de aplika reproduktado. Ekzemple, se vi havas altan haveblecan aplikaĵon kun kvin kopioj sed nur du nodoj, tiam la efika grado de reproduktado de la aplikaĵo estas reduktita al du.
Kvin kopioj povas nur esti distribuitaj tra du nodoj, kaj se unu el ili malsukcesos, ĝi demetos plurajn kopiojn samtempe.
Se vi havas kvin nodojn aŭ pli, ĉiu kopio funkcios sur aparta nodo, kaj malsukceso de unu nodo forigos maksimume unu kopion.
Tiel, altaj haveblecaj postuloj povas postuli certan minimuman nombron da nodoj en la areto.
Malavantaĝo n-ro 3. Pli malbonaj konsekvencoj de malsukceso
Kun malgranda nombro da nodoj, ĉiu fiasko havas pli gravajn konsekvencojn. Ekzemple, se vi havas nur du nodojn kaj unu el ili malsukcesas, duono de viaj moduloj tuj malaperas.
Kompreneble, Kubernetes migros la laborŝarĝon de la malsukcesa nodo al aliaj. Sed se estas malmultaj el ili, tiam eble ne estas sufiĉe da libera kapablo. Kiel rezulto, kelkaj el viaj aplikoj estos neatingeblaj ĝis vi aperigos la malsukcesan nodon.
Tiel, ju pli da nodoj, des malpli la efiko de aparataj misfunkciadoj.
Malavantaĝo #4: Pli da aŭtoskalaj paŝoj
Kubernetes havas grapolaŭtomatan sistemon por nuba infrastrukturo, kiu permesas vin aŭtomate aldoni aŭ forigi nodojn depende de viaj nunaj bezonoj. Kun pli grandaj nodoj, aŭtoskalado fariĝas pli abrupta kaj mallerta. Ekzemple, sur du nodoj, aldoni plian nodon tuj pliigos la grapolkapaciton je 50%. Kaj vi devos pagi por tiuj rimedoj, eĉ se vi ne bezonas ilin.
Tiel, se vi planas uzi aŭtomatan grapolskalon, ju pli malgrandaj la nodoj, des pli fleksebla kaj kostefika skalado vi ricevos.
Nun ni rigardu la avantaĝojn kaj malavantaĝojn de granda nombro da malgrandaj nodoj.
Dua opcio: multaj malgrandaj nodoj
La avantaĝoj de ĉi tiu aliro esence devenas de la malavantaĝoj de la kontraŭa opcio kun pluraj grandaj nodoj.
Puloj
Profesiulo #1: Malpli efiko de fiasko
Ju pli da nodoj, des malpli da podoj sur ĉiu nodo. Ekzemple, se vi havas cent modulojn po dek nodoj, tiam ĉiu nodo havos mezumon de dek moduloj.
Tiel, se unu el la nodoj malsukcesas, vi nur perdas 10% de la laborŝarĝo. Ŝancoj estas, ke nur malgranda nombro da kopioj estos trafita kaj la ĝenerala aplikaĵo restos funkcianta.
Aldone, la ceteraj nodoj verŝajne havos sufiĉe da senpagaj rimedoj por trakti la laborkvanton de la malsukcesa nodo, do Kubernetes povas libere replanigi la podojn kaj viaj aplikoj revenos al funkcia stato relative rapide.
Profesiulo #2: Bona reproduktado
Se estas sufiĉe da nodoj, la planilo de Kubernetes povas asigni malsamajn nodojn al ĉiuj kopioj. Tiel, se nodo malsukcesas, nur unu kopio estos tuŝita kaj la aplikaĵo restos disponebla.
Miksoj
Malavantaĝo n-ro 1. Malfacile regi
Grandaj nombroj da nodoj estas pli malfacile administreblaj. Ekzemple, ĉiu Kubernetes-nodo devas komuniki kun ĉiuj aliaj, tio estas, la nombro da konektoj kreskas kvadrate, kaj ĉiuj ĉi tiuj ligoj devas esti spuritaj.
La noda regilo en Kubernetes Controller Manager regule trairas ĉiujn nodojn en la areto por kontroli sanon - ju pli da nodoj, des pli da ŝarĝo sur la regilo.
La ŝarĝo sur la datumbazo etcd ankaŭ kreskas - ĉiu kubelet kaj kube-proxy vokoj por etcd (per la API), al kiu etcd devus dissendi objektoĝisdatigojn.
Ĝenerale, ĉiu laborista nodo trudas kroman ŝarĝon al la sistemkomponentoj de la majstraj nodoj.
Kubernetes oficiale subtenas aretojn kun . Tamen praktike jam estas 500 nodoj .
Por administri grandan nombron da labornodoj, vi devus elekti pli potencajn majstrajn nodojn. Ekzemple, kube-up la ĝusta VM-grandeco por la majstra nodo depende de la nombro da labornodoj. Tio estas, ju pli da laboristaj nodoj, des pli produktivaj estu la majstraj nodoj.
Por solvi ĉi tiujn specifajn problemojn ekzistas specialaj evoluoj, kiel ekz . Ĉi tiu sistemo ebligas al vi preteriri limigojn kaj konstrui aretojn kun grandega nombro da laboristaj nodoj.
Malavantaĝo #2: Pli da superkostoj.
Sur ĉiu labornodo, Kubernetes funkciigas aron da sistemaj demonoj - ĉi tiuj inkluzivas la ujan rultempon (kiel Docker), kube-proxy kaj kubelet, inkluzive de cAdvisor. Kune ili konsumas certan fiksan kvanton da rimedoj.
Se vi havas multajn malgrandajn nodojn, la proporcio de ĉi tiu supre sur ĉiu nodo estas pli granda. Ekzemple, imagu, ke ĉiuj sistemaj demonoj sur ununura nodo kune uzas 0,1 CPU-kernojn kaj 0,1 GB da memoro. Se vi havas unu dek-kernan nodon kun 10 GB da memoro, tiam demonoj konsumas 1% de la grapolkapacito. Aliflanke, sur dek unu-kernaj nodoj kun 1 GB da memoro, la demonoj prenos 10% de la grapolkapacito.
Tiel, ju pli malmultaj nodoj, des pli efike la infrastrukturo estas uzata.
Malavantaĝo n-ro 3. Malefika uzo de rimedoj
Sur malgrandaj nodoj, povas esti, ke la ceteraj rimedpecoj estas tro malgrandaj por asigni ajnan laborŝarĝon, do ili restas neuzataj.
Ekzemple, ĉiu pod postulas 0,75 GB da memoro. Se vi havas dek nodojn, ĉiu kun 1GB da memoro, vi povas ruli dek podojn, lasante ĉiun nodon kun 0,25GB da neuzata memoro.
Ĉi tio signifas, ke 25% de la memoro de la tuta areto estas malŝparitaj.
Sur granda nodo kun 10 GB da memoro, vi povas ruli 13 el ĉi tiuj moduloj - kaj estos nur unu neuzata fragmento de 0,25 GB.
En ĉi tiu kazo, nur 2,5% de la memoro estas malŝparita.
Tiel, resursoj estas uzitaj pli optimume sur pli grandaj nodoj.
Pluraj grandaj nodoj aŭ multaj malgrandaj?
Do, kio estas pli bona: kelkaj grandaj nodoj en areto aŭ multaj malgrandaj? Kiel ĉiam, ne estas klara respondo. Multe dependas de la tipo de apliko.
Ekzemple, se aplikaĵo postulas 10 GB da memoro, pli grandaj nodoj estas evidenta elekto. Kaj se aplikaĵo postulas dekoblan reproduktadon por alta havebleco, ĝi apenaŭ valoras la riskon meti kopiojn sur nur du nodoj - devas esti minimume dek nodoj en la areto.
En mezaj situacioj, faru elekton bazitan sur la avantaĝoj kaj malavantaĝoj de ĉiu opcio. Eble iuj argumentoj pli rilatas al via situacio ol aliaj.
Kaj tute ne necesas fari ĉiujn nodojn samgrandaj. Nenio malhelpas vin eksperimenti unue kun nodoj de la sama grandeco, poste aldoni nodojn de malsama grandeco al ili, kombinante ilin en areto. Labornodoj en Kubernetes-areto povas esti tute heterogenaj. Do vi povas provi kombini la avantaĝojn de ambaŭ aliroj.
Ne ekzistas ununura recepto, kaj ĉiu situacio havas siajn proprajn nuancojn, kaj nur produktado montros la veron.
Traduko preparita de la teamo de nuba platformo .
Pli pri Kubernetes: .
fonto: www.habr.com