Nodyn. traws.: Mae'r hanes agoriad llygad hwn o Omio - cydgrynwr teithio Ewropeaidd - yn mynd â darllenwyr o ddamcaniaeth sylfaenol i gymhlethdodau ymarferol hynod ddiddorol cyfluniad Kubernetes. Mae bod yn gyfarwydd ag achosion o'r fath yn helpu nid yn unig i ehangu eich gorwelion, ond hefyd i atal problemau nad ydynt yn ddibwys.
A ydych chi erioed wedi cael cais yn sownd yn ei le, rhoi'r gorau i ymateb i wiriadau iechyd, a methu â darganfod pam? Mae un esboniad posibl yn ymwneud â chyfyngiadau cwota adnoddau CPU. Dyma beth y byddwn yn siarad amdano yn yr erthygl hon.
TL; DR:
Rydym yn argymell yn gryf analluogi terfynau CPU yn Kubernetes (neu analluogi cwotâu CFS yn Kubelet) os ydych chi'n defnyddio fersiwn o'r cnewyllyn Linux gyda byg cwota CFS. Yn y craidd difrifol a byg sy'n arwain at ormod o throtlo ac oedi.
Yn Omio Kubernetes sy'n rheoli'r seilwaith cyfan. Mae ein holl lwythi gwaith dirdynnol a di-wladwriaeth yn rhedeg yn gyfan gwbl ar Kubernetes (rydym yn defnyddio Google Kubernetes Engine). Yn ystod y chwe mis diwethaf, rydym wedi dechrau arsylwi ar arafu ar hap. Mae cymwysiadau yn rhewi neu'n rhoi'r gorau i ymateb i wiriadau iechyd, yn colli cysylltiad â'r rhwydwaith, ac ati. Roedd yr ymddygiad hwn wedi peri penbleth i ni am amser hir, ac yn olaf fe benderfynon ni gymryd y broblem o ddifrif.
Crynodeb o'r erthygl:
- Ychydig eiriau am gynwysyddion a Kubernetes;
- Sut mae ceisiadau a therfynau CPU yn cael eu gweithredu;
- Sut mae terfyn CPU yn gweithio mewn amgylcheddau aml-graidd;
- Sut i olrhain throtling CPU;
- Datrys problemau a naws.
Ychydig eiriau am gynwysyddion a Kubernetes
Kubernetes yn ei hanfod yw'r safon fodern yn y byd seilwaith. Ei brif dasg yw offeryniaeth cynhwysydd.
Cynhwyswyr
Yn y gorffennol, roedd yn rhaid i ni greu arteffactau fel Java JARs / WARs, Python Eggs, neu weithrediadau i'w rhedeg ar weinyddion. Fodd bynnag, i wneud iddynt weithredu, roedd yn rhaid gwneud gwaith ychwanegol: gosod yr amgylchedd amser rhedeg (Java / Python), gosod y ffeiliau angenrheidiol yn y mannau cywir, sicrhau eu bod yn gydnaws â fersiwn benodol o'r system weithredu, ac ati. Mewn geiriau eraill, roedd yn rhaid rhoi sylw gofalus i reoli cyfluniad (a oedd yn aml yn destun cynnen rhwng datblygwyr a gweinyddwyr systemau).
Newidiodd cynwysyddion popeth. Nawr mae'r arteffact yn ddelwedd cynhwysydd. Gellir ei gynrychioli fel math o ffeil gweithredadwy estynedig sy'n cynnwys nid yn unig y rhaglen, ond hefyd amgylchedd gweithredu llawn (Java / Python / ...), yn ogystal â'r ffeiliau / pecynnau angenrheidiol, wedi'u gosod ymlaen llaw ac yn barod i rhedeg. Gellir defnyddio cynwysyddion a'u rhedeg ar weinyddion gwahanol heb unrhyw gamau ychwanegol.
Yn ogystal, mae cynwysyddion yn gweithredu yn eu hamgylchedd blwch tywod eu hunain. Mae ganddynt eu adapter rhwydwaith rhithwir eu hunain, eu system ffeiliau eu hunain gyda mynediad cyfyngedig, eu hierarchaeth prosesau eu hunain, eu cyfyngiadau eu hunain ar CPU a chof, ac ati. Mae hyn i gyd yn cael ei weithredu diolch i is-system arbennig o'r cnewyllyn Linux - gofodau enwau.
Kubernetes
Fel y dywedwyd yn gynharach, mae Kubernetes yn gerddorfawr cynhwysydd. Mae'n gweithio fel hyn: rydych chi'n rhoi cronfa o beiriannau iddo, ac yna'n dweud: “Hei, Kubernetes, gadewch i ni lansio deg achos o fy nghynhwysydd gyda 2 brosesydd a 3 GB o gof yr un, a'u cadw i redeg!” Bydd Kubernetes yn gofalu am y gweddill. Bydd yn dod o hyd i gapasiti am ddim, yn lansio cynwysyddion ac yn eu hailgychwyn os oes angen, yn cyflwyno diweddariad wrth newid fersiynau, ac ati. Yn y bôn, mae Kubernetes yn caniatáu ichi dynnu'r gydran caledwedd i ffwrdd ac yn gwneud amrywiaeth eang o systemau sy'n addas ar gyfer defnyddio a rhedeg cymwysiadau.
Kubernetes o safbwynt y lleygwr
Beth yw ceisiadau a therfynau yn Kubernetes
Iawn, rydym wedi gorchuddio cynwysyddion a Kubernetes. Gwyddom hefyd y gall cynwysyddion lluosog fyw ar yr un peiriant.
Gellir llunio cyfatebiaeth â fflat cymunedol. Mae adeilad eang (peiriannau/unedau) yn cael ei gymryd a'i rentu i sawl tenant (cynwysyddion). Mae Kubernetes yn gweithredu fel realtor. Mae'r cwestiwn yn codi, sut i gadw tenantiaid rhag gwrthdaro â'i gilydd? Beth os bydd un ohonyn nhw, dyweder, yn penderfynu benthyg yr ystafell ymolchi am hanner diwrnod?
Dyma lle daw ceisiadau a therfynau i rym. CPU Cais eu hangen at ddibenion cynllunio yn unig. Mae hyn yn rhywbeth fel “rhestr ddymuniadau” o'r cynhwysydd, ac fe'i defnyddir i ddewis y nod mwyaf addas. Ar yr un pryd y CPU terfyn Gellir ei gymharu â chytundeb rhentu - cyn gynted ag y byddwn yn dewis uned ar gyfer y cynhwysydd, y ni all mynd y tu hwnt i derfynau sefydledig. A dyma lle mae'r broblem yn codi ...
Sut mae ceisiadau a therfynau'n cael eu gweithredu yn Kubernetes
Mae Kubernetes yn defnyddio mecanwaith throtling (cylchoedd cloc sgipio) sydd wedi'i ymgorffori yn y cnewyllyn i weithredu terfynau CPU. Os yw cais yn mynd y tu hwnt i'r terfyn, mae sbardun yn cael ei alluogi (h.y. mae'n derbyn llai o gylchoedd CPU). Mae ceisiadau a therfynau cof yn cael eu trefnu'n wahanol, felly maent yn haws eu canfod. I wneud hyn, gwiriwch statws ailgychwyn olaf y pod: a yw'n “OOMKilled”. Nid yw throtlo CPU mor syml, gan mai dim ond metrigau y mae K8s ar gael trwy eu defnyddio, nid gan cgroups.
Cais CPU
Sut mae cais CPU yn cael ei weithredu
Er mwyn symlrwydd, gadewch i ni edrych ar y broses gan ddefnyddio peiriant gyda CPU 4-craidd fel enghraifft.
Mae K8s yn defnyddio mecanwaith grŵp rheoli (cgroups) i reoli dyraniad adnoddau (cof a phrosesydd). Mae model hierarchaidd ar gael ar ei gyfer: mae'r plentyn yn etifeddu terfynau'r grŵp rhiant. Mae'r manylion dosbarthu yn cael eu storio mewn system ffeiliau rhithwir (/sys/fs/cgroup). Yn achos prosesydd mae hyn /sys/fs/cgroup/cpu,cpuacct/*.
Mae K8s yn defnyddio ffeil cpu.share i ddyrannu adnoddau prosesydd. Yn ein hachos ni, mae'r cgroup gwraidd yn cael cyfrannau 4096 o adnoddau CPU - 100% o'r pŵer prosesydd sydd ar gael (1 craidd = 1024; mae hwn yn werth sefydlog). Mae'r grŵp gwraidd yn dosbarthu adnoddau yn gymesur yn dibynnu ar gyfrannau'r disgynyddion sydd wedi'u cofrestru ynddo cpu.share, ac maen nhw, yn eu tro, yn gwneud yr un peth â'u disgynyddion, etc. Ar nod Kubernetes nodweddiadol, mae gan y cgroup gwraidd dri o blant: system.slice, user.slice и kubepods. Defnyddir y ddau is-grŵp cyntaf i ddosbarthu adnoddau rhwng llwythi system critigol a rhaglenni defnyddwyr y tu allan i K8s. Un olaf - kubepods — a grëwyd gan Kubernetes i ddosbarthu adnoddau rhwng codennau.
Mae’r diagram uchod yn dangos bod yr is-grŵp cyntaf a’r ail is-grŵp wedi derbyn pob un 1024 cyfranddaliadau, gyda'r is-grŵp kuberpod wedi'i ddyrannu 4096 cyfranddaliadau Sut mae hyn yn bosibl: wedi'r cyfan, dim ond mynediad i'r grŵp gwraidd 4096 cyfrannau, ac mae swm cyfrannau ei disgynyddion yn sylweddol uwch na'r nifer hwn (6144)? Y pwynt yw bod y gwerth yn gwneud synnwyr rhesymegol, felly mae'r trefnydd Linux (CFS) yn ei ddefnyddio i ddyrannu adnoddau CPU yn gymesur. Yn ein hachos ni, mae'r ddau grŵp cyntaf yn derbyn 680 cyfranddaliadau go iawn (16,6% o 4096), a kubepod yn derbyn y gweddill 2736 cyfranddaliadau Yn achos amser segur, ni fydd y ddau grŵp cyntaf yn defnyddio'r adnoddau a ddyrannwyd.
Yn ffodus, mae gan y trefnydd fecanwaith i osgoi gwastraffu adnoddau CPU nas defnyddiwyd. Mae'n trosglwyddo gallu “segur” i bwll byd-eang, lle mae'n cael ei ddosbarthu i grwpiau sydd angen pŵer prosesydd ychwanegol (mae'r trosglwyddiad yn digwydd mewn sypiau i osgoi colledion talgrynnu). Mae dull tebyg yn cael ei gymhwyso at bob disgynyddion disgynyddion.
Mae'r mecanwaith hwn yn sicrhau dosbarthiad teg o bŵer prosesydd ac yn sicrhau nad oes unrhyw broses yn “dwyn” adnoddau oddi wrth eraill.
Terfyn CPU
Er gwaethaf y ffaith bod cyfluniadau terfynau a cheisiadau yn K8s yn edrych yn debyg, mae eu gweithrediad yn dra gwahanol: hyn mwyaf camarweiniol a'r rhan leiaf dogfenedig.
K8s yn ymgysylltu i weithredu terfynau. Mae eu gosodiadau wedi'u nodi mewn ffeiliau cfs_period_us и cfs_quota_us yn y cyfeiriadur cgroup (mae'r ffeil hefyd wedi'i lleoli yno cpu.share).
Yn wahanol i cpu.share, mae'r cwota yn seiliedig ar cyfnod amser, ac nid ar y pŵer prosesydd sydd ar gael. cfs_period_us yn pennu hyd y cyfnod (epoc) - mae bob amser yn 100000 μs (100 ms). Mae opsiwn i newid y gwerth hwn mewn K8s, ond dim ond mewn alpha y mae ar gael am y tro. Mae'r trefnydd yn defnyddio'r epoc i ailgychwyn cwotâu a ddefnyddiwyd. Ail ffeil cfs_quota_us, yn pennu'r amser sydd ar gael (cwota) ym mhob cyfnod. Sylwch ei fod hefyd wedi'i nodi mewn microseconds. Gall y cwota fod yn fwy na hyd y cyfnod; mewn geiriau eraill, gall fod yn fwy na 100 ms.
Edrychwn ar ddau senario ar beiriannau 16-craidd (y math mwyaf cyffredin o gyfrifiadur sydd gennym yn Omio):
Senario 1: 2 edefyn a therfyn o 200 ms. Dim sbardun
Senario 2: 10 edefyn a therfyn o 200 ms. Mae gwthio yn dechrau ar ôl 20 ms, mae mynediad at adnoddau prosesydd yn ailddechrau ar ôl 80 ms arall
Gadewch i ni ddweud eich bod wedi gosod y terfyn CPU i 2 cnewyllyn; Bydd Kubernetes yn trosi'r gwerth hwn i 200 ms. Mae hyn yn golygu y gall y cynhwysydd ddefnyddio uchafswm o 200ms o amser CPU heb ei wthio.
A dyma lle mae'r hwyl yn dechrau. Fel y soniwyd uchod, y cwota sydd ar gael yw 200 ms. Os ydych yn gweithio ochr yn ochr deg edafedd ar beiriant 12-craidd (gweler y darlun ar gyfer senario 2), tra bod pob cod arall yn segur, bydd y cwota wedi'i ddihysbyddu mewn dim ond 20 ms (ers 10 * 20 ms = 200 ms), a bydd holl edafedd y cod hwn yn hongian » (throttle) ar gyfer yr 80 ms. Y crybwyllwyd eisoes , oherwydd bod gormod o sbardun yn digwydd ac ni all y cynhwysydd hyd yn oed gyflawni'r cwota presennol.
Sut i werthuso throtling mewn codennau?
Dim ond mewngofnodi i'r pod a gweithredu cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods— cyfanswm nifer y cyfnodau amserlennu; -
nr_throttled— nifer y cyfnodau throttled yn y cyfansoddiadnr_periods; -
throttled_time— amser throtiog cronnol mewn nanoseconds.
Beth sy'n digwydd mewn gwirionedd?
O ganlyniad, rydym yn cael llawer o sbardun ym mhob cais. Weithiau mae o i mewn unwaith a hanner cryfach nag a gyfrifwyd!
Mae hyn yn arwain at wallau amrywiol - methiannau gwirio parodrwydd, rhewi cynhwysyddion, toriadau cysylltiad rhwydwaith, seibiannau o fewn galwadau gwasanaeth. Mae hyn yn y pen draw yn arwain at fwy o hwyrni a chyfraddau gwallau uwch.
Penderfyniad a chanlyniadau
Mae popeth yn syml yma. Fe wnaethon ni roi'r gorau i derfynau CPU a dechrau diweddaru cnewyllyn yr AO mewn clystyrau i'r fersiwn ddiweddaraf, lle roedd y nam yn sefydlog. Gostyngodd nifer y gwallau (HTTP 5xx) yn ein gwasanaethau yn sylweddol ar unwaith:
Gwallau HTTP 5xx
Gwallau HTTP 5xx ar gyfer un gwasanaeth critigol
Amser ymateb t95
Cywirdeb ceisiadau gwasanaeth critigol, 95fed canradd
Costau gweithredu
Nifer yr oriau enghraifft a dreuliwyd
Beth yw'r ddalfa?
Fel y dywedwyd ar ddechrau'r erthygl:
Gellir llunio cyfatebiaeth gyda fflat cymunedol... Mae Kubernetes yn gweithredu fel realtor. Ond sut i gadw tenantiaid rhag gwrthdaro â'i gilydd? Beth os bydd un ohonyn nhw, dyweder, yn penderfynu benthyca'r ystafell ymolchi am hanner diwrnod?
Dyma'r dalfa. Gall un cynhwysydd diofal fwyta'r holl adnoddau CPU sydd ar gael ar beiriant. Os oes gennych stac cymhwysiad craff (er enghraifft, mae JVM, Go, Node VM wedi'u ffurfweddu'n iawn), yna nid yw hyn yn broblem: gallwch chi weithio mewn amodau o'r fath am amser hir. Ond os yw cymwysiadau wedi'u optimeiddio'n wael neu heb eu optimeiddio o gwbl (FROM java:latest), gall y sefyllfa fynd allan o reolaeth. Yn Omio rydym wedi awtomataidd Dockerfiles sylfaenol gyda gosodiadau diofyn digonol ar gyfer y pentwr iaith mawr, felly nid oedd y mater hwn yn bodoli.
Rydym yn argymell monitro'r metrigau (defnydd, dirlawnder a gwallau), oedi API a chyfraddau gwallau. Sicrhau bod canlyniadau yn cwrdd â disgwyliadau.
cyfeiriadau
Dyma ein stori ni. Roedd y deunyddiau canlynol yn help mawr i ddeall beth oedd yn digwydd:
- ;
- ;
- ;
- ;
- - chwiliwch am “cpu throttling”.
Adroddiadau byg Kubernetes:
- ;
- ;
- .
A ydych chi wedi dod ar draws problemau tebyg yn eich ymarfer neu a oes gennych chi brofiad yn ymwneud â chyffro mewn amgylcheddau cynhyrchu mewn cynwysyddion? Rhannwch eich stori yn y sylwadau!
PS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «'.
Ffynhonnell: hab.com