Yn ôl yn 2016 rydym yn Buffer , a nawr mae tua 60 o nodau (ar AWS) a 1500 o gynwysyddion yn gweithio ar ein clwstwr k8s a reolir gan . Fodd bynnag, symudwyd i ficrowasanaethau trwy brofi a methu, a hyd yn oed ar ôl sawl blwyddyn o weithio gyda k8s rydym yn dal i wynebu problemau newydd. Yn y swydd hon byddwn yn siarad am cyfyngiadau prosesydd: pam yr oeddem yn meddwl eu bod yn arfer da a pham nad oeddent cystal yn y diwedd.
Cyfyngiadau prosesydd a sbardun
Fel llawer o ddefnyddwyr Kubernetes eraill, . Heb osodiad o'r fath, gall cynwysyddion mewn nod gymryd holl bŵer y prosesydd, sydd yn ei dro yn achosi prosesau Kubernetes pwysig (er enghraifft kubelet) yn peidio ag ymateb i geisiadau. Felly, mae gosod terfynau CPU yn ffordd dda o amddiffyn eich nodau.
Mae terfynau prosesydd yn gosod cynhwysydd i'r uchafswm amser CPU y gall ei ddefnyddio am gyfnod penodol (diofyn yw 100ms), ac ni fydd y cynhwysydd byth yn fwy na'r terfyn hwn. Yn Kubernetes ar gyfer throtling cynhwysydd a'i atal rhag mynd y tu hwnt i'r terfyn, defnyddir offeryn arbennig , ond mae'r terfynau CPU artiffisial hyn yn brifo perfformiad a chynyddu amser ymateb eich cynwysyddion yn y pen draw.
Beth all ddigwydd os na fyddwn yn gosod terfynau prosesydd?
Yn anffodus, bu'n rhaid i ni ein hunain wynebu'r broblem hon. Mae gan bob nod broses sy'n gyfrifol am reoli cynwysyddion kubelet, a rhoddodd y gorau i ymateb i geisiadau. Bydd y nod, pan fydd hyn yn digwydd, yn mynd i mewn i'r wladwriaeth NotReady, a bydd cynwysyddion ohono yn cael eu hailgyfeirio i rywle arall ac yn creu'r un problemau ar nodau newydd. Ddim yn senario delfrydol, a dweud y lleiaf.
Amlygiad o broblem sbardun ac ymateb
Y metrig allweddol ar gyfer olrhain cynhwysydd yw trottling, mae'n dangos sawl gwaith y mae eich cynhwysydd wedi'i throttled. Gwelsom gyda diddordeb bresenoldeb sbardun mewn rhai cynwysyddion, ni waeth a oedd llwyth y prosesydd yn eithafol ai peidio. Er enghraifft, gadewch i ni edrych ar un o'n prif APIs:
Fel y gwelwch isod, rydym wedi gosod y terfyn i 800m (0.8 neu 80% craidd), a gwerthoedd brig ar y cyrhaeddiad gorau 200m (20% craidd). Mae'n ymddangos bod gennym ni ddigon o bŵer prosesydd o hyd cyn gwthio'r gwasanaeth, fodd bynnag...
Efallai eich bod wedi sylwi, hyd yn oed pan fo llwyth y prosesydd yn is na'r terfynau penodedig - yn sylweddol is - mae sbardun yn dal i ddigwydd.
Yn wyneb hyn, buan iawn y darganfuom nifer o adnoddau (, , ) am y gostyngiad mewn perfformiad ac amser ymateb gwasanaethau oherwydd sbardun.
Pam rydyn ni'n gweld sbardun ar lwyth CPU isel? Y fersiwn fer yw: “mae nam yn y cnewyllyn Linux sy'n achosi sbardun diangen i gynwysyddion gyda therfynau prosesydd penodedig.” Os oes gennych ddiddordeb yn natur y broblem, gallwch ddarllen y cyflwyniad ( и opsiynau) gan Dave Chiluk.
Dileu cyfyngiadau CPU (yn ofalus iawn)
Ar ôl trafodaethau hir, fe wnaethom benderfynu dileu cyfyngiadau prosesydd o'r holl wasanaethau a effeithiodd yn uniongyrchol neu'n anuniongyrchol ar ymarferoldeb hanfodol ein defnyddwyr.
Nid oedd y penderfyniad yn hawdd oherwydd rydym yn gwerthfawrogi sefydlogrwydd ein clwstwr yn fawr. Yn y gorffennol, rydym eisoes wedi arbrofi gydag ansefydlogrwydd ein clwstwr, ac yna fe ddefnyddiodd y gwasanaethau ormod o adnoddau ac arafu gwaith eu holl nod. Nawr roedd popeth ychydig yn wahanol: roedd gennym ddealltwriaeth glir o'r hyn yr oeddem yn ei ddisgwyl gan ein clystyrau, yn ogystal â strategaeth dda ar gyfer gweithredu'r newidiadau arfaethedig.
Gohebiaeth fusnes ar fater brys.
Sut i amddiffyn eich nodau pan godir cyfyngiadau?
Ynysu gwasanaethau “anghyfyngedig”:
Yn y gorffennol, rydym eisoes wedi gweld rhai nodau yn mynd i gyflwr notReady, yn bennaf oherwydd gwasanaethau a ddefnyddiodd ormod o adnoddau.
Penderfynasom osod gwasanaethau o’r fath mewn nodau ar wahân (“wedi’u labelu”) fel nad ydynt yn ymyrryd â gwasanaethau “cysylltiedig”. O ganlyniad, trwy farcio rhai nodau ac ychwanegu’r paramedr goddefgarwch at wasanaethau “anghysylltiedig”, cawsom fwy o reolaeth dros y clwstwr, a daeth yn haws i ni nodi problemau gyda nodau. Er mwyn cyflawni prosesau tebyg eich hun, gallwch ymgyfarwyddo â nhw .
Neilltuo prosesydd cywir a chais cof:
Ein hofn mwyaf oedd y byddai'r broses yn defnyddio gormod o adnoddau ac y byddai'r nod yn rhoi'r gorau i ymateb i geisiadau. Ers nawr (diolch i Datadog) gallem fonitro'n glir yr holl wasanaethau ar ein clwstwr, dadansoddais sawl mis o weithrediad y rhai yr oeddem yn bwriadu eu dynodi'n rhai “amherthnasol”. Yn syml, gosodais uchafswm y defnydd CPU gydag ymyl o 20%, ac felly dyrannwyd lle yn y nod rhag ofn y bydd k8s yn ceisio neilltuo gwasanaethau eraill i'r nod.
Fel y gwelwch yn y graff, mae'r llwyth uchaf ar y prosesydd wedi cyrraedd 242m creiddiau CPU (0.242 creiddiau prosesydd). Ar gyfer cais prosesydd, mae'n ddigon i gymryd rhif ychydig yn fwy na'r gwerth hwn. Sylwch, gan fod y gwasanaethau'n canolbwyntio ar y defnyddiwr, bod gwerthoedd llwyth brig yn cyd-fynd â thraffig.
Gwnewch yr un peth gyda defnydd cof ac ymholiadau, a voila - rydych chi i gyd wedi'ch sefydlu! I gael mwy o ddiogelwch, gallwch ychwanegu graddoli pod llorweddol. Felly, bob tro y bydd y llwyth adnoddau yn uchel, bydd awto-sgennu yn creu codennau newydd, a bydd kubernetes yn eu dosbarthu i nodau gyda gofod rhydd. Rhag ofn nad oes lle ar ôl yn y clwstwr ei hun, gallwch osod rhybudd i chi'ch hun neu ffurfweddu ychwanegu nodau newydd trwy eu graddio'n awtomatig.
O'r anfanteision, mae'n werth nodi ein bod wedi colli yn “", h.y. nifer y cynwysyddion sy'n rhedeg ar un nod. Efallai y byddwn hefyd yn cael llawer o “ymlacio” ar ddwysedd traffig isel, ac mae siawns hefyd y byddwch chi'n cyrraedd llwyth prosesydd uchel, ond dylai nodau graddio awtomatig helpu gyda'r olaf.
Canfyddiadau
Rwy’n falch o gyhoeddi’r canlyniadau rhagorol hyn o arbrofion dros yr ychydig wythnosau diwethaf; rydym eisoes wedi gweld gwelliannau sylweddol mewn ymateb ar draws yr holl wasanaethau wedi’u haddasu:
Cawsom y canlyniadau gorau ar ein tudalen gartref (), yno cyflymodd y gwasanaeth i mewn dwywaith ar hugain!
A yw'r byg cnewyllyn Linux yn sefydlog?
Oes, dosbarthiadau fersiwn 4.19 ac uwch.
Fodd bynnag, wrth ddarllen ar gyfer yr ail o Fedi 2020 rydym yn dal i ddod ar draws sôn am rai prosiectau Linux gyda nam tebyg. Rwy'n credu bod gan rai dosbarthiadau Linux y byg hwn o hyd a'u bod yn gweithio ar ei drwsio o hyd.
Os yw eich fersiwn dosbarthu yn is na 4.19, byddwn yn argymell diweddaru i'r diweddaraf, ond beth bynnag, dylech geisio cael gwared ar y cyfyngiadau prosesydd a gweld a yw'r sbardun yn parhau. Isod gallwch weld rhestr rannol o wasanaethau rheoli Kubernetes a dosbarthiadau Linux:
- Debian: trwsio wedi'i integreiddio i'r fersiwn ddiweddaraf o'r dosbarthiad, , ac yn edrych yn eithaf ffres (). Efallai y bydd rhai fersiynau blaenorol hefyd yn sefydlog.
- Ubuntu: trwsio wedi'i integreiddio i'r fersiwn diweddaraf
- Mae EKS wedi cael atgyweiriad eto . Os yw eich fersiwn yn is na hyn, dylech ddiweddaru'r AMI.
- cwps: у
kops 1.18+Y brif ddelwedd gwesteiwr fydd Ubuntu 20.04. Os yw'ch fersiwn chi o kops yn hŷn, efallai y bydd yn rhaid i chi aros am atgyweiriad. Rydyn ni ein hunain yn aros nawr. - GKE (Google Cloud): Atgyweiriad integredig , fodd bynnag, mae problemau gyda sbardun .
Beth i'w wneud os yw'r atgyweiriad yn trwsio'r broblem ysgogol?
Nid wyf yn siŵr bod y broblem wedi’i datrys yn llwyr. Pan gyrhaeddwn y fersiwn cnewyllyn gyda'r atgyweiriad, byddaf yn profi'r clwstwr ac yn diweddaru'r post. Os oes unrhyw un eisoes wedi diweddaru, byddai gennyf ddiddordeb mewn darllen eich canlyniadau.
Casgliad
- Os ydych chi'n gweithio gyda chynwysyddion Docker o dan Linux (ni waeth Kubernetes, Mesos, Swarm neu eraill), efallai y bydd eich cynwysyddion yn colli perfformiad oherwydd sbardun;
- Ceisiwch ddiweddaru i'r fersiwn diweddaraf o'ch dosbarthiad yn y gobaith bod y byg eisoes wedi'i drwsio;
- Bydd dileu terfynau prosesydd yn datrys y broblem, ond mae hon yn dechneg beryglus y dylid ei defnyddio'n ofalus iawn (mae'n well diweddaru'r cnewyllyn yn gyntaf a chymharu'r canlyniadau);
- Os ydych chi wedi dileu terfynau CPU, monitro'ch defnydd CPU a chof yn ofalus a gwnewch yn siŵr bod eich adnoddau CPU yn fwy na'ch defnydd;
- Opsiwn diogel fyddai graddio codennau'n awtomatig i greu codennau newydd rhag ofn y bydd llwyth caledwedd uchel, fel bod kubernetes yn eu neilltuo i nodau rhydd.
Rwy'n gobeithio y bydd y swydd hon yn eich helpu i wella perfformiad eich systemau cynhwysydd.
PS mae'r awdur yn gohebu â darllenwyr a sylwebwyr (yn Saesneg).
Ffynhonnell: hab.com