Ebrill 27 yn y gynhadledd , fel rhan o'r adran “DevOps”, rhoddwyd yr adroddiad “Auto-scaling and resource management in Kubernetes”. Mae'n sôn am sut y gallwch ddefnyddio K8s i sicrhau argaeledd uchel eich ceisiadau a sicrhau perfformiad brig.
Yn ôl traddodiad, rydym yn falch o gyflwyno (44 munud, llawer mwy addysgiadol na'r erthygl) a'r prif grynodeb ar ffurf testun. Ewch!
Gadewch i ni ddadansoddi testun yr adroddiad fesul gair a dechrau o'r diwedd.
Kubernetes
Gadewch i ni ddweud bod gennym ni gynwysyddion Docker ar ein gwesteiwr. Am beth? Er mwyn sicrhau ailadroddadwyedd ac ynysu, sydd yn ei dro yn caniatáu ar gyfer defnydd syml a da, CI/CD. Mae gennym lawer o gerbydau o'r fath gyda chynwysyddion.
Beth mae Kubernetes yn ei ddarparu yn yr achos hwn?
- Rydyn ni'n rhoi'r gorau i feddwl am y peiriannau hyn ac yn dechrau gweithio gyda'r cwmwl, clwstwr o gynwysyddion neu godennau (grwpiau o gynwysyddion).
- Ar ben hynny, nid ydym hyd yn oed yn meddwl am godennau unigol, ond yn rheoli mwyоgrwpiau mwy. Cyfryw cyntefig lefel uchel caniatáu inni ddweud bod templed ar gyfer rhedeg llwyth gwaith penodol, a dyma'r nifer gofynnol o achosion i'w redeg. Os byddwn yn newid y templed wedyn, bydd pob achos yn newid.
- Gyda API datganiadol Yn lle gweithredu dilyniant o orchmynion penodol, rydym yn disgrifio “strwythur y byd” (yn YAML), sy'n cael ei greu gan Kubernetes. Ac eto: pan fydd y disgrifiad yn newid, bydd ei arddangosfa wirioneddol hefyd yn newid.
Rheoli adnoddau
CPU
Gadewch inni redeg nginx, php-fpm a mysql ar y gweinydd. Mewn gwirionedd bydd gan y gwasanaethau hyn hyd yn oed mwy o brosesau ar waith, ac mae angen adnoddau cyfrifiadurol ar bob un ohonynt:
(mae'r niferoedd ar y sleid yn “barotiaid”, angen haniaethol pob proses ar gyfer pŵer cyfrifiadura)
Er mwyn ei gwneud hi'n haws gweithio gyda hyn, mae'n rhesymegol cyfuno prosesau yn grwpiau (er enghraifft, holl brosesau nginx yn un grŵp "nginx"). Ffordd syml ac amlwg o wneud hyn yw rhoi pob grŵp mewn cynhwysydd:
I barhau, mae angen i chi gofio beth yw cynhwysydd (yn Linux). Gwnaethpwyd eu hymddangosiad yn bosibl diolch i dair nodwedd allweddol yn y cnewyllyn, a weithredwyd amser maith yn ôl: , и . A hwyluswyd datblygiad pellach gan dechnolegau eraill (gan gynnwys “cregyn” cyfleus fel Docker):
Yng nghyd-destun yr adroddiad, dim ond diddordeb sydd gennym ni cgroups, oherwydd bod grwpiau rheoli yn rhan o ymarferoldeb cynwysyddion (Docker, ac ati) sy'n gweithredu rheoli adnoddau. Mae prosesau wedi'u cyfuno'n grwpiau, fel y dymunwn, yn grwpiau rheoli.
Gadewch i ni ddychwelyd at y gofynion CPU ar gyfer y prosesau hyn, ac yn awr ar gyfer grwpiau o brosesau:
(Dw i'n ailadrodd bod pob rhif yn fynegiant haniaethol o'r angen am adnoddau)
Ar yr un pryd, mae gan y CPU ei hun adnodd cyfyngedig penodol (yn yr enghraifft dyma 1000), y gall fod diffyg gan bawb (swm anghenion pob grŵp yw 150+850+460=1460). Beth fydd yn digwydd yn yr achos hwn?
Mae’r cnewyllyn yn dechrau dosbarthu adnoddau ac yn ei wneud yn “weddol”, gan roi’r un faint o adnoddau i bob grŵp. Ond yn yr achos cyntaf, mae mwy ohonyn nhw nag sydd eu hangen (333> 150), felly mae'r gormodedd (333-150 = 183) yn aros wrth gefn, sydd hefyd wedi'i ddosbarthu'n gyfartal rhwng dau gynhwysydd arall:
O ganlyniad: roedd gan y cynhwysydd cyntaf ddigon o adnoddau, yr ail - nid oedd ganddo ddigon o adnoddau, y trydydd - nid oedd ganddo ddigon o adnoddau. Mae hyn yn ganlyniad gweithredoedd trefnydd "gonest" yn Linux - . Gellir addasu ei weithrediad gan ddefnyddio'r aseiniad pwysau pob un o'r cynwysyddion. Er enghraifft, fel hyn:
Gadewch i ni edrych ar achos diffyg adnoddau yn yr ail gynhwysydd (php-fpm). Mae'r holl adnoddau cynhwysydd yn cael eu dosbarthu'n gyfartal rhwng prosesau. O ganlyniad, mae'r brif broses yn gweithio'n dda, ond mae pob gweithiwr yn arafu, gan dderbyn llai na hanner yr hyn sydd ei angen arnynt:
Dyma sut mae'r trefnydd CFS yn gweithio. Byddwn yn galw ymhellach y pwysau yr ydym yn ei neilltuo i gynwysyddion ceisiadau. Pam fod hyn yn wir - gweler ymhellach.
Gadewch i ni edrych ar yr holl sefyllfa o'r ochr arall. Fel y gwyddoch, mae pob ffordd yn arwain at Rufain, ac yn achos cyfrifiadur, i'r CPU. Un CPU, llawer o dasgau - mae angen golau traffig arnoch chi. Y ffordd symlaf o reoli adnoddau yw “golau traffig”: fe wnaethant roi amser mynediad sefydlog i'r CPU i un broses, yna'r un nesaf, ac ati.
Gelwir y dull hwn yn gwotâu caled (cyfyngu caled). Gadewch i ni ei gofio yn syml fel terfynau. Fodd bynnag, os ydych chi'n dosbarthu terfynau i bob cynhwysydd, mae problem yn codi: roedd mysql yn gyrru ar hyd y ffordd ac ar ryw adeg daeth ei angen am CPU i ben, ond mae'r holl brosesau eraill yn cael eu gorfodi i aros tan y CPU diog.
Gadewch i ni ddychwelyd i'r cnewyllyn Linux a'i ryngweithio â'r CPU - mae'r darlun cyffredinol fel a ganlyn:
Mae gan cgroup ddau osodiad - yn y bôn mae'r rhain yn ddau “dro” syml sy'n eich galluogi i benderfynu:
- pwysau ar gyfer cynhwysydd (ceisiadau) yn cyfranddaliadau;
- canran o gyfanswm yr amser CPU ar gyfer gweithio ar dasgau cynhwysydd (terfynau) yw cwota.
Sut i fesur CPU?
Mae yna wahanol ffyrdd:
- Beth yw parotiaid, does neb yn gwybod - mae angen i chi drafod bob tro.
- Llog cliriach, ond cymharol: mae 50% o weinydd gyda 4 craidd a chyda 20 craidd yn bethau hollol wahanol.
- Gallwch ddefnyddio'r rhai a grybwyllwyd eisoes pwysau, y mae Linux yn ei wybod, ond maent hefyd yn gymharol.
- Yr opsiwn mwyaf digonol yw mesur adnoddau cyfrifiadurol yn eiliadau. Y rhai. mewn eiliadau o amser prosesydd o'i gymharu ag eiliadau o amser real: rhoddwyd 1 eiliad o amser prosesydd fesul 1 eiliad go iawn - dyma un craidd CPU cyfan.
Er mwyn ei gwneud hi'n haws siarad, dechreuon nhw fesur yn uniongyrchol cnewyllyn, sy'n golygu ganddynt yr un amser CPU o'i gymharu â'r un go iawn. Gan fod Linux yn deall pwysau, ond dim cymaint o amser / creiddiau CPU, roedd angen mecanwaith i gyfieithu o un i'r llall.
Gadewch i ni ystyried enghraifft syml gyda gweinydd gyda 3 craidd CPU, lle bydd tri chod yn cael pwysau (500, 1000 a 1500) sy'n hawdd eu trosi i'r rhannau cyfatebol o'r creiddiau a ddyrennir iddynt (0,5, 1 a 1,5).
Os cymerwch ail weinydd, lle bydd dwywaith cymaint o greiddiau (6), a gosod yr un codennau yno, gellir cyfrifo dosbarthiad creiddiau yn hawdd trwy luosi â 2 (1, 2 a 3, yn y drefn honno). Ond mae eiliad bwysig yn digwydd pan fydd pedwerydd pod yn ymddangos ar y gweinydd hwn, y bydd ei bwysau, er hwylustod, yn 3000. Mae'n cymryd rhan o'r adnoddau CPU (hanner y creiddiau), ac ar gyfer y codennau sy'n weddill maent yn cael eu hailgyfrifo (haneru):
Kubernetes ac adnoddau CPU
Yn Kubernetes, mae adnoddau CPU fel arfer yn cael eu mesur yn milliadrax, h.y. Cymerir 0,001 creiddiau fel y pwysau sylfaenol. (Gelwir yr un peth yn derminoleg Linux/cgroups yn gyfran CPU, er, yn fwy manwl gywir, 1000 milicro = 1024 CPU yn rhannu.) Mae K8s yn sicrhau nad yw'n gosod mwy o godennau ar y gweinydd nag sydd o adnoddau CPU ar gyfer cyfanswm pwysau pob codennau.
Sut mae hyn yn digwydd? Pan fyddwch chi'n ychwanegu gweinydd at glwstwr Kubernetes, adroddir faint o greiddiau CPU sydd ar gael. Ac wrth greu pod newydd, mae trefnydd Kubernetes yn gwybod faint o greiddiau y bydd eu hangen ar y pod hwn. Felly, bydd y pod yn cael ei neilltuo i weinydd lle mae digon o greiddiau.
Beth fydd yn digwydd os dim y cais yn cael ei nodi (h.y. nid oes gan y pod nifer diffiniedig o greiddiau sydd eu hangen arno)? Gadewch i ni ddarganfod sut mae Kubernetes yn gyffredinol yn cyfrif adnoddau.
Ar gyfer pod gallwch chi nodi'r ddau gais (rhestrwr CFS) a'r terfynau (cofio'r golau traffig?):
- Os cânt eu pennu'n gyfartal, yna rhoddir dosbarth QoS i'r pod gwarantedig. Mae'r nifer hwn o greiddiau bob amser ar gael iddo wedi'i warantu.
- Os yw'r cais yn llai na'r terfyn - dosbarth QoS byrstable. Y rhai. Disgwyliwn i god, er enghraifft, ddefnyddio 1 craidd bob amser, ond nid yw'r gwerth hwn yn gyfyngiad ar ei gyfer: weithiau gall pod ddefnyddio mwy (pan fydd gan y gweinydd adnoddau am ddim ar gyfer hyn).
- Mae yna hefyd ddosbarth QoS ymdrech orau — mae'n cynnwys yr union godau hynny nad yw cais wedi'i nodi ar eu cyfer. Rhoddir adnoddau iddynt yn olaf.
Память
Gyda'r cof, mae'r sefyllfa yn debyg, ond ychydig yn wahanol - wedi'r cyfan, mae natur yr adnoddau hyn yn wahanol. Yn gyffredinol, mae'r gyfatebiaeth fel a ganlyn:
Gawn ni weld sut mae ceisiadau'n cael eu gweithredu er cof. Gadewch i'r codennau fyw ar y gweinydd, gan newid y defnydd o gof, nes bod un ohonynt mor fawr fel ei fod yn rhedeg allan o gof. Yn yr achos hwn, mae'r llofrudd OOM yn ymddangos ac yn lladd y broses fwyaf:
Nid yw hyn bob amser yn addas i ni, felly mae'n bosibl rheoleiddio pa brosesau sy'n bwysig i ni ac na ddylid eu lladd. I wneud hyn, defnyddiwch y paramedr oom_sgor_adj.
Gadewch i ni ddychwelyd i ddosbarthiadau QoS y CPU a llunio cyfatebiaeth â'r gwerthoedd oom_score_adj sy'n pennu blaenoriaethau defnydd cof ar gyfer codennau:
- Mae'r gwerth oom_score_adj isaf ar gyfer pod - -998 - yn golygu y dylid lladd pod o'r fath yn olaf, dyma gwarantedig.
- Yr uchaf - 1000 - yw ymdrech orau, podiau o'r fath yn cael eu lladd yn gyntaf.
- I gyfrifo'r gwerthoedd sy'n weddill (byrstable) mae fformiwla, y mae ei hanfod yn deillio o'r ffaith mai po fwyaf o adnoddau y mae pod wedi gofyn amdanynt, y lleiaf tebygol yw hi o gael ei lladd.
Yr ail "twist" - terfyn_mewn_beit - am derfynau. Ag ef, mae popeth yn symlach: rydym yn syml yn aseinio'r uchafswm o gof a gyhoeddwyd, ac yma (yn wahanol i'r CPU) nid oes unrhyw gwestiwn o sut i'w fesur (cof).
Yn gyfan gwbl
Rhoddir pob pod yn Kubernetes requests и limits - y ddau baramedr ar gyfer CPU a chof:
- yn seiliedig ar geisiadau, mae'r amserlennydd Kubernetes yn gweithio, sy'n dosbarthu codennau ymhlith gweinyddwyr;
- yn seiliedig ar yr holl baramedrau, mae dosbarth QoS y pod yn cael ei bennu;
- Cyfrifir pwysau cymharol yn seiliedig ar geisiadau CPU;
- mae'r rhaglennydd CFS wedi'i ffurfweddu yn seiliedig ar geisiadau CPU;
- Mae lladdwr OOM wedi'i ffurfweddu yn seiliedig ar geisiadau cof;
- mae “golau traffig” wedi'i ffurfweddu yn seiliedig ar derfynau CPU;
- Yn seiliedig ar derfynau cof, mae terfyn wedi'i ffurfweddu ar gyfer y cgroup.
Yn gyffredinol, mae'r llun hwn yn ateb yr holl gwestiynau am sut mae'r rhan fwyaf o reoli adnoddau yn digwydd yn Kubernetes.
Graddio awtomatig
K8s clwstwr-autoscaler
Gadewch i ni ddychmygu bod y clwstwr cyfan eisoes wedi'i feddiannu a bod angen creu pod newydd. Er na all y pod ymddangos, mae'n hongian mewn statws Tra'n aros. Er mwyn iddo ymddangos, gallwn gysylltu gweinydd newydd â'r clwstwr neu... gosod clwstwr-autoscaler, a fydd yn gwneud hynny i ni: archebu peiriant rhithwir gan ddarparwr y cwmwl (gan ddefnyddio cais API) a'i gysylltu â'r clwstwr , ac ar ôl hynny bydd y pod yn cael ei ychwanegu .
Mae hyn yn awtoraddio clwstwr Kubernetes, sy'n gweithio'n wych (yn ein profiad ni). Fodd bynnag, fel mewn mannau eraill, mae rhai arlliwiau yma ...
Cyn belled â'n bod ni'n cynyddu maint y clwstwr, roedd popeth yn iawn, ond beth sy'n digwydd pan fydd y clwstwr dechreuodd ryddhau ei hun? Y broblem yw bod codennau mudo (i ryddhau gwesteiwyr) yn dechnegol anodd ac yn ddrud iawn o ran adnoddau. Mae Kubernetes yn defnyddio dull hollol wahanol.
Ystyriwch glwstwr o 3 gweinydd sydd â Defnydd. Mae ganddo 6 cod: nawr mae yna 2 ar gyfer pob gweinydd. Am ryw reswm roeddem am ddiffodd un o'r gweinyddion. I wneud hyn byddwn yn defnyddio'r gorchymyn kubectl drain, sydd:
- yn gwahardd anfon codennau newydd i'r gweinydd hwn;
- yn dileu codennau presennol ar y gweinydd.
Gan fod Kubernetes yn gyfrifol am gynnal nifer y codennau (6), yn syml iawn bydd yn ail-greu ar nodau eraill, ond nid ar yr un sy'n anabl, gan ei fod eisoes wedi'i nodi fel un nad yw ar gael ar gyfer cynnal codennau newydd. Mae hwn yn fecanig sylfaenol i Kubernetes.
Fodd bynnag, mae naws yma hefyd. Mewn sefyllfa debyg, ar gyfer StatefulSet (yn hytrach na Deployment), bydd y camau gweithredu yn wahanol. Nawr mae gennym ni gais gwladwriaethol eisoes - er enghraifft, tri pod gyda MongoDB, ac mae gan un ohonynt ryw fath o broblem (mae'r data wedi'i lygru neu wall arall sy'n atal y pod rhag cychwyn yn gywir). Ac rydym eto'n penderfynu analluogi un gweinydd. Beth fydd yn digwydd?
MongoDB gallai marw oherwydd bod angen cworwm: ar gyfer clwstwr o dri gosodiad, rhaid i ddau o leiaf weithredu. Fodd bynnag, mae hyn ddim yn digwydd - Diolch i Cyllideb PodAmhariad. Mae'r paramedr hwn yn pennu'r nifer gofynnol o godennau gweithio. Gwybod nad yw un o'r codennau MongoDB yn gweithio mwyach, a gweld bod PodDisruptionBudget wedi'i osod ar gyfer MongoDB minAvailable: 2, Ni fydd Kubernetes yn caniatáu ichi ddileu pod.
Gwaelod llinell: er mwyn i symudiad (ac mewn gwirionedd, ail-greu) codennau weithio'n gywir pan fydd y clwstwr yn cael ei ryddhau, mae angen i chi ffurfweddu PodDisruptionBudget.
Graddio llorweddol
Gadewch i ni ystyried sefyllfa arall. Mae yna gymhwysiad yn rhedeg fel Deployment yn Kubernetes. Mae traffig defnyddwyr yn dod i'w codennau (er enghraifft, mae tri ohonyn nhw), ac rydyn ni'n mesur dangosydd penodol ynddynt (dyweder, llwyth CPU). Pan fydd y llwyth yn cynyddu, rydym yn ei gofnodi ar amserlen ac yn cynyddu nifer y codennau i ddosbarthu ceisiadau.
Heddiw yn Kubernetes nid oes angen gwneud hyn â llaw: mae cynnydd / gostyngiad awtomatig yn nifer y codennau wedi'i ffurfweddu yn dibynnu ar werthoedd y dangosyddion llwyth mesuredig.
Y prif gwestiynau yma yw: beth yn union i'w fesur и sut i ddehongli gwerthoedd a gafwyd (ar gyfer gwneud penderfyniad ar newid nifer y codennau). Gallwch chi fesur llawer:
Sut i wneud hyn yn dechnegol - casglu metrigau, ac ati. —Siaradais yn fanwl yn yr adroddiad am . A'r prif gyngor ar gyfer dewis y paramedrau gorau posibl yw arbrawf!
Mae (Gorlawnder Defnydd a Gwallau), yr hwn yw ei ystyr fel y canlyn. Ar ba sail mae'n gwneud synnwyr i raddfa, er enghraifft, php-fpm? Yn seiliedig ar y ffaith bod gweithwyr yn rhedeg allan, mae hyn defnydd. Ac os yw'r gweithwyr drosodd ac nad yw cysylltiadau newydd yn cael eu derbyn, mae hyn eisoes yn digwydd dirlawnder. Rhaid mesur y ddau baramedr hyn, ac yn dibynnu ar y gwerthoedd, rhaid graddio.
Yn hytrach na i gasgliad
Mae gan yr adroddiad barhad: am raddio fertigol a sut i ddewis yr adnoddau cywir. Byddaf yn siarad am hyn mewn fideos yn y dyfodol ar - tanysgrifiwch fel nad ydych chi'n colli allan!
Fideos a sleidiau
Fideo o'r perfformiad (44 munud):
Cyflwyniad yr adroddiad:
PS
Adroddiadau eraill am Kubernetes ar ein blog:
- «» (Andrey Polovov; Ebrill 8, 2019 ar Saint HighLoad ++);
- «» (Dmitry Stolyarov; Tachwedd 8, 2018 ar HighLoad++);
- «» (Dmitry Stolyarov; Mai 28, 2018 yn RootConf);
- «» (Dmitry Stolyarov; Tachwedd 7, 2017 ar HighLoad++);
- «» (Dmitry Stolyarov; Mehefin 6, 2017 yn RootConf).
Ffynhonnell: hab.com