Wrth greu clwstwr Kubernetes, gall cwestiynau godi: faint o nodau gweithiwr i'w ffurfweddu a pha fath? Beth sy'n well ar gyfer clwstwr ar y safle: prynu sawl gweinydd pwerus neu ddefnyddio dwsin o hen beiriannau yn eich canolfan ddata? A yw'n well cymryd wyth enghraifft craidd sengl neu ddau graidd cwad yn y cwmwl?
Mae'r atebion i'r cwestiynau hyn yn yr erthygl. yn nghyfieithiad y gorchymyn .
Capasiti clwstwr
Yn gyffredinol, gellir meddwl am glwstwr Kubernetes fel "supernode" mawr. Cyfanswm ei bŵer cyfrifiadurol yw cyfanswm pwerau ei holl nodau cyfansoddol.
Mae sawl ffordd o gyrraedd eich targed cynhwysedd clwstwr dymunol. Er enghraifft, mae angen clwstwr arnom gyda chyfanswm capasiti o 8 craidd prosesydd a 32 GB o RAM oherwydd bod angen cymaint o adnoddau ar set o gymwysiadau. Yna gallwch chi osod dau nod gyda 16 GB o gof neu bedwar nod gyda 8 GB o gof, dau brosesydd cwad-craidd neu bedwar un craidd deuol.
Dyma ddwy ffordd bosibl o greu clwstwr:
Mae'r ddau opsiwn yn cynhyrchu clwstwr gyda'r un gallu, ond mae gan y cyfluniad gwaelod bedwar nod llai ac mae gan y cyfluniad uchaf ddau nod mwy.
Pa opsiwn sy'n well?
I ateb y cwestiwn hwn, gadewch i ni edrych ar fanteision y ddau opsiwn. Rydym wedi eu crynhoi mewn tabl.
Sawl nod mawr
Llawer o nodau bach
Rheoli clwstwr yn haws (os yw ar y safle)
Graddio awtomatig llyfn
Rhatach (os ar y safle)
Nid yw'r pris ychydig yn wahanol (yn y cwmwl)
Yn gallu rhedeg cymwysiadau sy'n defnyddio llawer o adnoddau
Dyblygiad llawn
Defnyddir adnoddau'n fwy effeithlon (llai o orbenion ar ddaemonau system
Goddefgarwch fai clwstwr uwch
Sylwch mai dim ond am nodau gweithwyr yr ydym yn siarad. Mae dewis nifer a maint y prif nodau yn bwnc hollol wahanol.
Felly, gadewch i ni drafod pob pwynt o'r tabl yn fwy manwl.
Yr opsiwn cyntaf: sawl nod mawr
Yr opsiwn mwyaf eithafol yw un nod gweithiwr ar gyfer gallu cyfan y clwstwr. Yn yr enghraifft uchod, byddai hwn yn nod gweithiwr sengl gyda chraidd 16 CPU a 16 GB o RAM.
Manteision
Byd Gwaith Rhif 1. Rheolaeth haws
Mae'n haws rheoli ychydig o beiriannau na fflyd gyfan. Mae'n gyflymach i gyflwyno diweddariadau ac atgyweiriadau, ac mae'n haws cydamseru. Mae nifer y methiannau mewn niferoedd absoliwt hefyd yn llai.
Sylwch fod pob un o'r uchod yn berthnasol i'ch caledwedd, eich gweinyddwyr, ac nid i achosion cwmwl.
Mae'r sefyllfa yn wahanol yn y cwmwl. Yno, mae'r rheolaeth yn cael ei drin gan y darparwr gwasanaeth cwmwl. Felly, nid yw rheoli deg nod yn y cwmwl yn llawer gwahanol i reoli un nod.
Llwybro traffig a dosbarthiad llwyth rhwng codennau yn y cwmwl : mae traffig sy'n dod o'r Rhyngrwyd yn cael ei anfon at y prif gydbwysydd llwyth, sy'n anfon traffig ymlaen i borthladd un o'r nodau (mae gwasanaeth NodePort yn gosod y porthladd yn yr ystod 30000-32767 ym mhob nod clwstwr). Mae'r rheolau a osodir gan kube-proxy yn ailgyfeirio traffig o'r nod i'r pod. Dyma sut mae'n edrych ar gyfer deg pod ar ddau nod:
Pro #2: Llai o gost fesul nod
Mae car pwerus yn ddrutach, ond nid yw'r cynnydd pris o reidrwydd yn llinol. Mewn geiriau eraill, mae un gweinydd deg craidd gyda 10 GB o gof fel arfer yn rhatach na deg gweinydd un craidd gyda'r un faint o gof.
Ond nodwch nad yw'r rheol hon fel arfer yn gweithio mewn gwasanaethau cwmwl. Yng nghynlluniau prisio cyfredol pob darparwr cwmwl mawr, mae prisiau'n cynyddu'n llinol gyda chapasiti.
Felly, yn y cwmwl fel arfer ni allwch arbed ar weinyddion mwy pwerus.
Pro #3: Gallwch redeg cymwysiadau sy'n defnyddio llawer o adnoddau
Mae angen gweinyddwyr pwerus mewn clwstwr ar rai cymwysiadau. Er enghraifft, os oes angen 8 GB o gof ar system ddysgu peiriant, ni fyddwch yn gallu ei redeg ar nodau 1 GB, ond dim ond gydag o leiaf un nod gweithiwr mawr.
Cons
Anfantais Rhif 1. Llawer o godau fesul nod
Os cyflawnir yr un dasg ar lai o nodau, yna yn naturiol bydd gan bob un ohonynt fwy o godennau.
Gallai hyn fod yn broblem.
Y rheswm yw bod pob modiwl yn cyflwyno rhywfaint o orbenion i amser rhedeg y cynhwysydd (e.e. Docker), yn ogystal â'r kubelet a'r cAdvisor.
Er enghraifft, mae kubelet yn archwilio'r holl gynwysyddion yn rheolaidd ar nod i weld a yw'n goroesi - po fwyaf o gynwysyddion, y mwyaf o waith y mae'n rhaid i'r kubelet ei wneud.
Mae CAdvisor yn casglu ystadegau defnydd adnoddau ar gyfer pob cynhwysydd ar nod, ac mae kubelet yn holi'r wybodaeth hon yn rheolaidd ac yn ei darparu trwy API. Unwaith eto, mae mwy o gynwysyddion yn golygu mwy o waith i cAdvisor a kubelet.
Os bydd nifer y modiwlau yn cynyddu, gall arafu'r system a hyd yn oed danseilio ei ddibynadwyedd.
Yn ystorfa Kubernetes rhai bod nodau'n neidio rhwng statws Parod/An Barod oherwydd bod gwiriadau ciwbedi rheolaidd o'r holl gynwysyddion ar nod yn cymryd gormod o amser.
Am y rheswm hwn Kubernetes . Yn dibynnu ar berfformiad y nod, gallwch chi redeg mwy o godiau fesul nod, ond mae'n anodd rhagweld a fydd problemau neu a fydd popeth yn gweithio'n iawn. Mae'n werth profi'r gwaith ymlaen llaw.
Anfantais Rhif 2. Cyfyngiad ar ddyblygu
Nid oes digon o nodau'n cyfyngu ar raddau effeithiol y defnydd o ddyblygu. Er enghraifft, os oes gennych chi gais argaeledd uchel gyda phum atgynhyrchiad ond dim ond dau nod, yna mae gradd effeithiol y cais o atgynhyrchu yn cael ei ostwng i ddau.
Dim ond ar draws dau nod y gellir dosbarthu pum copi, ac os bydd un ohonynt yn methu, bydd yn tynnu nifer o gopïau i lawr ar unwaith.
Os oes gennych bum nod neu fwy, bydd pob replica yn rhedeg ar nod ar wahân, a bydd methiant un nod yn dileu un atgynhyrchiad ar y mwyaf.
Felly, efallai y bydd gofynion argaeledd uchel yn gofyn am isafswm penodol o nodau yn y clwstwr.
Anfantais Rhif 3. Canlyniadau gwaeth methiant
Gyda nifer fach o nodau, mae gan bob methiant ganlyniadau mwy difrifol. Er enghraifft, os mai dim ond dau nod sydd gennych a bod un ohonynt yn methu, mae hanner eich modiwlau'n diflannu ar unwaith.
Wrth gwrs, bydd Kubernetes yn mudo'r llwyth gwaith o'r nod a fethwyd i eraill. Ond os nad oes llawer ohonynt, yna efallai na fydd digon o gapasiti rhydd. O ganlyniad, ni fydd rhai o'ch ceisiadau ar gael nes i chi ddod â'r nod a fethwyd i fyny.
Felly, po fwyaf o nodau, y lleiaf yw effaith methiannau caledwedd.
Anfantais #4: Mwy o gamau graddoli awtomatig
Mae gan Kubernetes system graddio auto clwstwr ar gyfer seilwaith cwmwl, sy'n eich galluogi i ychwanegu neu dynnu nodau yn awtomatig yn dibynnu ar eich anghenion cyfredol. Gyda nodau mwy, mae graddoli awtomatig yn dod yn fwy sydyn a lletchwith. Er enghraifft, ar ddau nod, bydd ychwanegu nod ychwanegol yn cynyddu cynhwysedd y clwstwr 50% ar unwaith. A bydd yn rhaid i chi dalu am yr adnoddau hynny, hyd yn oed os nad oes eu hangen arnoch.
Felly, os ydych chi'n bwriadu defnyddio graddio clwstwr awtomatig, y lleiaf yw'r nodau, y mwyaf hyblyg a chost-effeithiol o raddio a gewch.
Nawr, gadewch i ni edrych ar fanteision ac anfanteision nifer fawr o nodau bach.
Ail opsiwn: llawer o nodau bach
Mae manteision y dull hwn yn ei hanfod yn deillio o anfanteision yr opsiwn arall gyda sawl nod mawr.
Manteision
Pro #1: Llai o effaith methiant
Po fwyaf o nodau, y lleiaf o godennau ar bob nod. Er enghraifft, os oes gennych gant o fodiwlau fesul deg nod, yna bydd gan bob nod ddeg modiwl ar gyfartaledd.
Fel hyn, os bydd un o'r nodau'n methu, dim ond 10% o'r llwyth gwaith y byddwch chi'n ei golli. Mae'n debygol mai dim ond nifer fach o atgynyrchiadau fydd yn cael eu heffeithio a bydd y cymhwysiad cyffredinol yn parhau i fod yn weithredol.
Yn ogystal, mae'n debygol y bydd gan y nodau sy'n weddill ddigon o adnoddau am ddim i drin llwyth gwaith y nod a fethwyd, felly gall Kubernetes aildrefnu'r codennau yn rhydd a bydd eich cymwysiadau'n dychwelyd i gyflwr swyddogaethol yn gymharol gyflym.
Pro #2: Dyblygiad da
Os oes digon o nodau, gall trefnydd Kubernetes aseinio nodau gwahanol i bob atgynhyrchiad. Fel hyn, os bydd nod yn methu, dim ond un copi a effeithir a bydd y cais yn parhau i fod ar gael.
Cons
Anfantais Rhif 1. Anodd ei reoli
Mae'n anoddach rheoli nifer fawr o nodau. Er enghraifft, rhaid i bob nod Kubernetes gyfathrebu â'r lleill i gyd, hynny yw, mae nifer y cysylltiadau'n tyfu'n gwadratig, ac mae angen olrhain yr holl gysylltiadau hyn.
Mae'r rheolydd nodau yn Kubernetes Controller Manager yn cerdded trwy'r holl nodau yn y clwstwr yn rheolaidd i wirio iechyd - po fwyaf o nodau, y mwyaf o lwyth ar y rheolydd.
Mae'r llwyth ar y gronfa ddata ac ati hefyd yn tyfu - mae pob kubelet a kube-proxy yn galw ar gyfer ac ati (drwy'r API), y dylai ac ati ddarlledu diweddariadau gwrthrych iddo.
Yn gyffredinol, mae nod pob gweithiwr yn gosod llwyth ychwanegol ar gydrannau system y prif nodau.
Mae Kubernetes yn cefnogi clystyrau yn swyddogol gyda . Fodd bynnag, yn ymarferol mae yna 500 o nodau eisoes .
Er mwyn rheoli nifer fawr o nodau gweithwyr, dylech ddewis prif nodau mwy pwerus. Er enghraifft, ciwb i fyny y maint VM cywir ar gyfer y prif nod yn dibynnu ar nifer y nodau gweithiwr. Hynny yw, po fwyaf o nodau gweithiwr, y mwyaf cynhyrchiol y dylai'r prif nodau fod.
I ddatrys y problemau penodol hyn mae yna ddatblygiadau arbennig, megis . Mae'r system hon yn caniatáu ichi osgoi cyfyngiadau ac adeiladu clystyrau gyda nifer enfawr o nodau gweithwyr.
Anfantais #2: Mwy o gostau cyffredinol.
Ar bob nod gweithiwr, mae Kubernetes yn rhedeg set o daemonau system - mae'r rhain yn cynnwys amser rhedeg y cynhwysydd (fel Docker), kube-proxy a kubelet, gan gynnwys cAdvisor. Gyda'i gilydd maent yn defnyddio swm penodol o adnoddau.
Os oes gennych lawer o nodau bach, mae cyfran y gorben hwn ar bob nod yn fwy. Er enghraifft, dychmygwch fod pob daemon system ar un nod gyda'i gilydd yn defnyddio creiddiau 0,1 CPU a 0,1 GB o gof. Os oes gennych un nod deg craidd gyda 10 GB o gof, yna mae daemoniaid yn defnyddio 1% o gapasiti'r clwstwr. Ar y llaw arall, ar ddeg nod craidd sengl gyda 1 GB o gof, bydd yr daemons yn cymryd 10% o gapasiti'r clwstwr.
Felly, po leiaf o nodau, mwyaf effeithlon y defnyddir y seilwaith.
Anfantais Rhif 3. Defnydd aneffeithlon o adnoddau
Ar nodau bach, mae'n bosibl bod y darnau adnoddau sy'n weddill yn rhy fach i neilltuo unrhyw lwyth gwaith iddynt, fel nad ydynt yn cael eu defnyddio o hyd.
Er enghraifft, mae angen 0,75 GB o gof ar bob pod. Os oes gennych ddeg nod, pob un â 1GB o gof, gallwch redeg deg cod, gan adael pob nod gyda 0,25GB o gof heb ei ddefnyddio.
Mae hyn yn golygu bod 25% o gof y clwstwr cyfan yn cael ei wastraffu.
Ar nod mawr gyda 10 GB o gof, gallwch redeg 13 o'r modiwlau hyn - a dim ond un darn nas defnyddiwyd o 0,25 GB fydd.
Yn yr achos hwn, dim ond 2,5% o'r cof sy'n cael ei wastraffu.
Felly, defnyddir adnoddau yn y ffordd orau bosibl ar nodau mwy.
Sawl nod mawr neu lawer o rai bach?
Felly, pa un sy'n well: ychydig o nodau mawr mewn clwstwr neu lawer o rai bach? Fel bob amser, nid oes ateb clir. Mae llawer yn dibynnu ar y math o gais.
Er enghraifft, os oes angen 10 GB o gof ar raglen, mae nodau mwy yn ddewis amlwg. Ac os yw'r cais yn gofyn am ddyblygiad deg gwaith ar gyfer argaeledd uchel, go brin ei bod yn werth y risg o osod atgynyrchiadau ar ddau nod yn unig - rhaid bod o leiaf ddeg nod yn y clwstwr.
Mewn sefyllfaoedd canolradd, gwnewch ddewis yn seiliedig ar fanteision ac anfanteision pob opsiwn. Efallai bod rhai dadleuon yn fwy perthnasol i'ch sefyllfa chi nag eraill.
Ac nid oes angen gwneud yr holl nodau yr un maint o gwbl. Nid oes dim yn eich atal rhag arbrofi yn gyntaf gyda nodau o'r un maint, yna ychwanegu nodau o faint gwahanol iddynt, gan eu cyfuno mewn clwstwr. Gall nodau gweithwyr mewn clwstwr Kubernetes fod yn gwbl heterogenaidd. Felly gallwch geisio cyfuno manteision y ddau ddull.
Nid oes un rysáit sengl, ac mae gan bob sefyllfa ei naws ei hun, a dim ond cynhyrchiad fydd yn dangos y gwir.
Cyfieithiad wedi'i baratoi gan dîm platfform y cwmwl .
Mwy am Kubernetes: .
Ffynhonnell: hab.com