Cúpla bliain ó shin Kubernetes ar bhlag oifigiúil GitHub. Ó shin i leith, tá sé ar an teicneolaíocht chaighdeánach chun seirbhísí a imscaradh. Bainistíonn Kubernetes anois cuid shuntasach de sheirbhísí inmheánacha agus poiblí. De réir mar a d'fhás ár mbraislí agus de réir mar a d'éirigh le riachtanais feidhmíochta níos déine, thugamar faoi deara go raibh roinnt seirbhísí ar Kubernetes ag fulaingt ó am go ham nach bhféadfaí a mhíniú de bharr ualach an fheidhmchláir féin.
Go bunúsach, bíonn foighne líonra randamach de suas le 100ms nó níos mó ag feidhmchláir, rud a fhágann go mbíonn amanna istigh nó go ndéanann siad atriail. Bhíothas ag súil go mbeadh seirbhísí in ann freagra a thabhairt ar iarratais i bhfad níos tapúla ná 100ms. Ach tá sé seo dodhéanta má thógann an nasc féin an oiread sin ama. Ar leithligh, thugamar faoi deara fiosruithe MySQL an-tapa ar cheart dóibh na milleasoicindí a thógáil, agus chríochnaigh MySQL ina milleasoicindí, ach ó dhearcadh an iarratais iarrthaigh, ghlac an freagra 100 ms nó níos mó.
Ba léir láithreach nár tharla an fhadhb ach amháin nuair a nascadh le nód Kubernetes, fiú má tháinig an glao ó lasmuigh de Kubernetes. Is é an bealach is éasca chun an fhadhb a atáirgeadh ná i dtástáil , a ritheann ó aon óstach inmheánach, déanann sé tástáil ar sheirbhís Kubernetes ar chalafort ar leith, agus cláraíonn sé ard-fhanacht ó am go chéile. San Airteagal seo, féachfaimid ar conas a bhí muid in ann cúis na faidhbe seo a rianú síos.
Deireadh a chur le castacht neamhriachtanach sa slabhra as a dtagann teip
Tríd an sampla céanna a atáirgeadh, bhíomar ag iarraidh fócas na faidhbe a laghdú agus sraitheanna castachta nach raibh gá leo a bhaint. Ar dtús, bhí an iomarca eilimintí sa sreabhadh idir Vegeta agus na pods Kubernetes. Chun fadhb líonra níos doimhne a aithint, ní mór duit cuid acu a chur as an áireamh.
Cruthaíonn an cliant (Vegeta) nasc TCP le haon nód sa bhraisle. Feidhmíonn Kubernetes mar líonra forleagan (ar bharr an líonra ionad sonraí atá ann cheana féin) a úsáideann , is é sin, cuimsíonn sé na paicéid IP den líonra forleagan taobh istigh de phaicéid IP an ionaid sonraí. Nuair a cheanglaítear leis an gcéad nód, déantar aistriúchán seoltaí líonra (NAT) stát chun an seoladh IP agus calafort an nód Kubernetes a aistriú chuig an seoladh IP agus port sa líonra forleagan (go sonrach, an pod leis an bhfeidhmchlár). I gcás paicéid isteach, déantar an t-ord droim ar ais de ghníomhartha. Is córas casta é le go leor stáit agus go leor gnéithe a nuashonraítear agus a athraítear i gcónaí de réir mar a bhíonn seirbhísí á n-imscaradh agus á n-aistriú.
Fóntais tcpdump i dtástáil Vegeta tá moill le linn chroitheadh láimhe TCP (idir SYN agus SYN-ACK). Chun an chastacht gan ghá seo a bhaint, is féidir leat é a úsáid hping3 le haghaidh “pings” simplí le paicéid SYN. Déanaimid seiceáil an bhfuil moill ar an bpaicéad freagartha, agus ansin athshocróimid an nasc. Is féidir linn na sonraí a scagadh chun gan ach paicéid níos mó ná 100ms a áireamh agus bealach níos éasca a fháil chun an fhadhb a atáirgeadh ná tástáil sraithe 7 líonra iomlán Vegeta. Seo iad "pings" nód Kubernetes ag baint úsáide as TCP SYN/SYN-ACK ar an "port nód" seirbhíse (30927) ag eatraimh 10ms, scagtha ag na freagraí is moille:
theojulienne@shell ~ $ sudo hping3 172.16.47.27 -S -p 30927 -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=1485 bua=29200 rtt=127.1 ms
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=1486 bua=29200 rtt=117.0 ms
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=1487 bua=29200 rtt=106.2 ms
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=1488 bua=29200 rtt=104.1 ms
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=5024 bua=29200 rtt=109.2 ms
fad=46 ip=172.16.47.27 ttl=59 DF id=0 spórt=30927 bratacha=SA seicheamh=5231 bua=29200 rtt=109.2 ms
An féidir a dhéanamh láithreach an chéad bhreathnóireacht. Agus na huimhreacha seichimh agus na hamanna á meas, is léir nach plódú aonuaire iad seo. Is minic a charnann an mhoill agus déantar é a phróiseáil sa deireadh.
Ansin, ba mhaith linn a fháil amach cé na comhpháirteanna a d'fhéadfadh a bheith bainteach le plódú tráchta. B'fhéidir gurb iad seo cuid de na céadta rialacha iptables i NAT? Nó an bhfuil fadhbanna ar bith le tollánú IPIP ar an líonra? Bealach amháin chun é seo a sheiceáil ná gach céim den chóras a thástáil trína dhíchur. Cad a tharlaíonn má bhaineann tú NAT agus loighic balla dóiteáin, ag fágáil ach an chuid IPIP:
Go fortunately, is furasta do Linux an ciseal forleagan IP a rochtain go díreach má tá an meaisín ar an líonra céanna:
theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
fad=40 ip=10.125.20.64 ttl=64 DF id=0 spórt=0 bratacha=RA seicheamh=7346 bua=0 rtt=127.3 ms
fad=40 ip=10.125.20.64 ttl=64 DF id=0 spórt=0 bratacha=RA seicheamh=7347 bua=0 rtt=117.3 ms
fad=40 ip=10.125.20.64 ttl=64 DF id=0 spórt=0 bratacha=RA seicheamh=7348 bua=0 rtt=107.2 ms
Ag meas na dtorthaí, tá an fhadhb fós ann! Ní áirítear leis seo iptables agus NAT. Mar sin tá an fhadhb TCP? A ligean ar a fheiceáil conas a théann ping ICMP rialta:
theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
fad=28 ip=10.125.20.64 ttl=64 id=42594 icmp_seq=104 rtt=110.0 ms
fad=28 ip=10.125.20.64 ttl=64 id=49448 icmp_seq=4022 rtt=141.3 ms
fad=28 ip=10.125.20.64 ttl=64 id=49449 icmp_seq=4023 rtt=131.3 ms
fad=28 ip=10.125.20.64 ttl=64 id=49450 icmp_seq=4024 rtt=121.2 ms
fad=28 ip=10.125.20.64 ttl=64 id=49451 icmp_seq=4025 rtt=111.2 ms
fad=28 ip=10.125.20.64 ttl=64 id=49452 icmp_seq=4026 rtt=101.1 ms
fad=28 ip=10.125.20.64 ttl=64 id=50023 icmp_seq=4343 rtt=126.8 ms
fad=28 ip=10.125.20.64 ttl=64 id=50024 icmp_seq=4344 rtt=116.8 ms
fad=28 ip=10.125.20.64 ttl=64 id=50025 icmp_seq=4345 rtt=106.8 ms
fad=28 ip=10.125.20.64 ttl=64 id=59727 icmp_seq=9836 rtt=106.1 ms
Léiríonn na torthaí nach bhfuil an fhadhb imithe. B'fhéidir gur tollán IPIP é seo? Déanaimis an tástáil a shimpliú tuilleadh:
An seoltar gach paicéad idir an dá óstach seo?
theojulienne@kube-node-client ~ $ sudo hping3 172.16.47.27 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
fad=46 ip=172.16.47.27 ttl=61 id=41127 icmp_seq=12564 rtt=140.9 ms
fad=46 ip=172.16.47.27 ttl=61 id=41128 icmp_seq=12565 rtt=130.9 ms
fad=46 ip=172.16.47.27 ttl=61 id=41129 icmp_seq=12566 rtt=120.8 ms
fad=46 ip=172.16.47.27 ttl=61 id=41130 icmp_seq=12567 rtt=110.8 ms
fad=46 ip=172.16.47.27 ttl=61 id=41131 icmp_seq=12568 rtt=100.7 ms
fad=46 ip=172.16.47.27 ttl=61 id=9062 icmp_seq=31443 rtt=134.2 ms
fad=46 ip=172.16.47.27 ttl=61 id=9063 icmp_seq=31444 rtt=124.2 ms
fad=46 ip=172.16.47.27 ttl=61 id=9064 icmp_seq=31445 rtt=114.2 ms
fad=46 ip=172.16.47.27 ttl=61 id=9065 icmp_seq=31446 rtt=104.2 ms
Táimid tar éis an cás a shimpliú chuig dhá nód Kubernetes ag seoladh aon phaicéad dá chéile, fiú ping ICMP. Feiceann siad fós latency má tá an sprioc-óstach "olc" (cuid acu níos measa ná a chéile).
Anois an cheist dheireanach: cén fáth nach dtarlaíonn an mhoill ach ar fhreastalaithe kube-nód? Agus a tharlaíonn sé nuair is kube-nód an seoltóir nó an glacadóir? Ar ámharaí an tsaoil, is furasta é seo a dhéanamh amach freisin trí phaicéad a sheoladh ó óstach lasmuigh de Kubernetes, ach leis an bhfaighteoir “olc” céanna. Mar a fheiceann tú, níl an fhadhb imithe:
theojulienne@shell ~ $ sudo hping3 172.16.47.27 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
fad=46 ip=172.16.47.27 ttl=61 DF id=0 spórt=9876 bratacha=RA seicheamh=312 bua=0 rtt=108.5 ms
fad=46 ip=172.16.47.27 ttl=61 DF id=0 spórt=9876 bratacha=RA seicheamh=5903 bua=0 rtt=119.4 ms
fad=46 ip=172.16.47.27 ttl=61 DF id=0 spórt=9876 bratacha=RA seicheamh=6227 bua=0 rtt=139.9 ms
fad=46 ip=172.16.47.27 ttl=61 DF id=0 spórt=9876 bratacha=RA seicheamh=7929 bua=0 rtt=131.2 ms
Ansin rithfimid na hiarratais chéanna ón bhfoinse kube-node roimhe seo chuig an ósta seachtrach (rud a eisiann an t-óstach foinse toisc go bhfuil comhpháirt RX agus TX araon san áireamh sa ping):
theojulienne@kube-node-client ~ $ sudo hping3 172.16.33.44 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
^C
--- 172.16.33.44 hping statistic ---
22352 packets transmitted, 22350 packets received, 1% packet loss
round-trip min/avg/max = 0.2/7.6/1010.6 ms
Trí scrúdú a dhéanamh ar ghabhálacha paicéid latency, fuaireamar roinnt faisnéise breise. Go sonrach, go bhfeiceann an seoltóir (bun) an teorainn ama seo, ach ní fheiceann an faighteoir (barr) - féach colún Delta (i soicindí):
Ina theannta sin, má fhéachann tú ar an difríocht in ord paicéid TCP agus ICMP (de réir uimhreacha seicheamh) ar thaobh an fhaighteora, tagann paicéid ICMP i gcónaí san ord céanna inar seoladh iad, ach le hamanna éagsúla. Ag an am céanna, uaireanta idirleathnaíonn paicéid TCP, agus téann cuid acu i bhfostú. Go háirithe, má scrúdaíonn tú calafoirt paicéid SYN, tá siad in ord ar thaobh an tseoltóra, ach ní ar thaobh an ghlacadóra.
Tá difríocht subtle i conas próiseálann freastalaithe nua-aimseartha (cosúil leo siúd inár lárionad sonraí) paicéid ina bhfuil TCP nó ICMP. Nuair a thagann paicéad isteach, déanann an t-oiriúnóir líonra "é a hashes in aghaidh an naisc", is é sin, déanann sé iarracht na naisc a bhriseadh ina scuainí agus gach scuaine a sheoladh chuig croí próiseálaí ar leith. Maidir le TCP, cuimsíonn an hash seo an seoladh IP foinse agus ceann scríbe agus an calafort. I bhfocail eile, tá gach nasc hashed (d'fhéadfadh) difriúil. Maidir le ICMP, ní dhéantar ach seoltaí IP a lua, toisc nach bhfuil aon chalafoirt ann.
Breathnú nua eile: le linn na tréimhse seo feicimid moilleanna ICMP ar gach cumarsáid idir dhá óstach, ach ní dhéanann TCP. Insíonn sé seo dúinn gur dócha go mbaineann an chúis le hashing scuaine RX: tá an brú tráchta beagnach cinnte i bpróiseáil paicéid RX, ní le linn freagraí a sheoladh.
Cuireann sé seo deireadh le paicéid a sheoladh ón liosta cúiseanna féideartha. Tá a fhios againn anois go bhfuil an fhadhb próiseála paicéad ar an taobh glactha ar roinnt freastalaithe kube-nód.
Tuiscint a fháil ar phróiseáil paicéad san eithne Linux
Chun a thuiscint cén fáth a dtarlaíonn an fhadhb ag an nglacadóir ar roinnt freastalaithe kube-nód, déanaimis féachaint ar conas a phróiseálann eithne Linux paicéid.
Ag filleadh ar an gcur i bhfeidhm traidisiúnta is simplí, faigheann an cárta líonra an paicéad agus cuireann sé an eithne Linux go bhfuil pacáiste ann nach mór a phróiseáil. Stopann an eithne obair eile, aistríonn sé comhthéacs chuig an láimhseálaí idirbhriste, próiseálann an paicéad, agus ansin filleann sé ar na tascanna reatha.
Tá an t-athrú comhthéacs seo mall: b'fhéidir nach raibh latency faoi deara ar chártaí líonra 10Mbps sna '90s, ach ar chártaí 10G nua-aimseartha le tréchur uasta de 15 milliún paicéad in aghaidh an tsoicind, is féidir cur isteach ar gach croí-fhreastalaí beag ocht-lárnach. de huaire sa soicind.
D'fhonn gan cur isteach a láimhseáil i gcónaí, chuir Linux leis na blianta fada ó shin : Líonra API a úsáideann gach tiománaí nua-aimseartha chun feidhmíocht a fheabhsú ag luasanna ard. Ar luasanna ísle faigheann an eithne fós idirbhriste ón gcárta líonra ar an seanbhealach. Nuair a shroicheann a dhóthain paicéid a sháraíonn an tairseach, cuireann an eithne isteach ar dhíchumasú agus ina ionad sin tosaíonn sé ag vótáil ar an adapter líonra agus ag piocadh suas paicéid ina smután. Déantar próiseáil i softirq, is é sin, i tar éis glaonna córais agus isteach crua-earraí, nuair a bhíonn an eithne (seachas spás úsáideora) ag rith cheana féin.
Tá sé seo i bhfad níos tapúla, ach is cúis le fadhb eile. Má tá an iomarca paicéid ann, caitear an t-am ar fad ag próiseáil paicéid ón gcárta líonra, agus níl am ag próisis spáis úsáideoirí na scuainí seo a fholmhú (léamh ó naisc TCP, etc.). Faoi dheireadh líonann na scuainí agus tosaímid ag titim paicéid. In iarracht teacht ar iarmhéid, socraíonn an eithne buiséad don uaslíon paicéad a phróiseáiltear i gcomhthéacs softirq. Nuair a sháraítear an buiséad seo, músclaítear snáithe ar leith ksoftirqd (feicfidh tú ceann acu i ps in aghaidh an chroí) a láimhseálann na softirqs seo lasmuigh den ghnáthchosán syscall/cur isteach. Tá an snáithe seo sceidealta ag baint úsáide as an sceidealóir próiseas caighdeánach, a dhéanann iarracht acmhainní a leithdháileadh go cothrom.
Tar éis staidéar a dhéanamh ar an gcaoi a bpróiseálann an eithne paicéid, is féidir leat a fheiceáil go bhfuil dóchúlacht áirithe ann go mbeidh brú tráchta ann. Mura bhfaightear glaonna softirq chomh minic sin, beidh ar phaicéid fanacht ar feadh tamaill le go bpróiseálfar iad sa scuaine RX ar an gcárta líonra. D'fhéadfadh sé seo a bheith mar gheall ar thasc éigin ag cur bac ar chroílár an phróiseálaí, nó go bhfuil rud éigin eile ag cur cosc ar an gcroí ó softirq a rith.
An phróiseáil a laghdú go dtí an croí nó an modh
Níl i moilleanna Softirq ach buille faoi thuairim faoi láthair. Ach déanann sé ciall, agus tá a fhios againn go bhfuil rud éigin an-chosúil le feiceáil againn. Mar sin is é an chéad chéim eile an teoiric seo a dhearbhú. Agus má dheimhnítear é, ansin faigh an chúis atá leis an moill.
Fillfimid ar ár bpacáistí mall:
len=46 ip=172.16.53.32 ttl=61 id=29573 icmp_seq=1953 rtt=99.3 ms
fad=46 ip=172.16.53.32 ttl=61 id=29574 icmp_seq=1954 rtt=89.3 ms
fad=46 ip=172.16.53.32 ttl=61 id=29575 icmp_seq=1955 rtt=79.2 ms
fad=46 ip=172.16.53.32 ttl=61 id=29576 icmp_seq=1956 rtt=69.1 ms
fad=46 ip=172.16.53.32 ttl=61 id=29577 icmp_seq=1957 rtt=59.1 ms
fad=46 ip=172.16.53.32 ttl=61 id=29790 icmp_seq=2070 rtt=75.7 ms
fad=46 ip=172.16.53.32 ttl=61 id=29791 icmp_seq=2071 rtt=65.6 ms
fad=46 ip=172.16.53.32 ttl=61 id=29792 icmp_seq=2072 rtt=55.5 ms
Mar a pléadh níos luaithe, baintear na paicéid ICMP seo isteach i scuaine RX NIC amháin agus próiseáiltear iad ag croí LAP amháin. Más mian linn a thuiscint conas a oibríonn Linux, tá sé úsáideach go mbeadh a fhios cén áit (ar a bhfuil croí an LAP) agus conas (softirq, ksoftirqd) a phróiseáiltear na pacáistí seo chun an próiseas a rianú.
Anois tá sé in am uirlisí a úsáid a ligeann duit monatóireacht a dhéanamh ar an eithne Linux i bhfíor-am. Seo a úsáid againn . Ligeann an tacar uirlisí seo duit cláir bheaga C a scríobh a dhúnann feidhmeanna treallach san eithne agus a mhaolaíonn na himeachtaí isteach i gclár Python spáis úsáideora ar féidir leo iad a phróiseáil agus an toradh a thabhairt ar ais chugat. Is ábhar casta é feidhmeanna treallacha a chur san eithne, ach tá an áirgiúlacht deartha le haghaidh slándála uasta agus tá sé deartha chun na cineálacha saincheisteanna táirgthe nach bhfuil a atáirgeadh go héasca i dtimpeallacht tástála nó forbartha a rianú síos go díreach.
Tá an plean anseo simplí: tá a fhios againn go bpróiseálann an eithne na pings ICMP seo, mar sin cuirfimid duán ar an bhfeidhm eithne , a ghlacann le paicéad iarratais macalla ICMP atá ag teacht isteach agus a chuireann tús le freagra macalla ICMP a sheoladh. Is féidir linn paicéad a aithint tríd an uimhir icmp_seq a mhéadú, rud a thaispeánann hping3 níos airde.
Cód cuma casta, ach níl sé chomh scary mar is cosúil. Feidhm icmp_echo aistrithe struct sk_buff *skb: Is paicéad é seo le "iarratas macalla". Is féidir linn é a rianú, an t-ord a tharraingt amach echo.sequence (atá i gcomparáid le icmp_seq ag hping3 выше), agus é a sheoladh chuig spás úsáideora. Tá sé áisiúil freisin ainm/ID an phróisis reatha a ghabháil. Seo thíos na torthaí a fheicimid go díreach agus na paicéid á bpróiseáil ag an eithne:
TGID PID ProCess ICMP_seq 0 0 Swapper/11 770 0 0 Swapper/11 771 0 0 Swapper/11 772 0 0 Swapper/11 773 0 0 Swapper/11 774 20041 20086 SWAP775 SWAP0 0 PROMETHS FHEIDHM/ 11 776 0 0 swapper/11 777 0 0 urlabhraí-tuarascáil- s 11
Ba chóir a thabhairt faoi deara anseo gur i gcomhthéacs softirq beidh próisis a rinne glaonna córais le feiceáil mar "phróisis" nuair is é an t-eithne a phróiseálann paicéid go sábháilte i gcomhthéacs na heithne.
Leis an uirlis seo is féidir linn próisis shonracha a cheangal le pacáistí sonracha a léiríonn moill de hping3. Déanaimis simplí é grep ar an ngabháil seo do luachanna áirithe icmp_seq. Tugadh faoi deara paicéid a mheaitseálann na luachanna icmp_seq thuas mar aon lena RTT a thugamar faoi deara thuas (i lúibíní tá na luachanna RTT a bhfuiltear ag súil leo do phaicéid a rinneamar scagadh amach mar gheall ar luachanna RTT níos lú ná 50 ms):
AINM PRÓISEAS PID TGID ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 76 ksoftirqd/11 1954 ** 89ms 76 76 ksoftirqd/ 11 1955 ** 79ms 76 76 ksoftirqd/11 1956 ** 69ms 76 76 ksoftirqd/11 1957 ** (59ms) 76 76 ksoftirqd/11 1958 ** (49ms) 76 76 ksoftirqd/11 1959 ** (39ms) 76 76 ksoftirqd/11 qd/ 1960 29 ** (76ms) 76 11 ksoftirqd/1961 19 ** (76ms) -- 76 11 cadvisor 1962 9 10137 cadvisor 10436 2068 10137 ksoftirqd/10436 2069 76 ksoftirqd/76 11 2070 ** 75ms 76 76 ksoftirqd/ 11 2071 ** 65ms 76 76 ksoftirqd/11 2072 ** (55ms) 76 76 ksoftirqd/11 2073 ** (45ms) 76 76 ksoftirqd/11 2074 ** (35ms) 76 ksoftirqd/76 11 ** (2075ms) 25 ksoftirqd/76 76 ** (11ms2076) 15 ksoftirqd/76 76 ** (11ms) 2077 ksoftirqd/5 XNUMXm XNUMX ksoftirqd/XNUMX XNUMX ** (XNUMXms) XNUMX ksoftirqd/XNUMX XNUMXm XNUMX XNUMX ksoftirqd/XNUMX XNUMXm XNUMX ksoftirqd/XNUMX ms ) XNUMX XNUMX ksoftirqd/XNUMX XNUMX ** (XNUMXms)
Insíonn na torthaí roinnt rudaí dúinn. Ar an gcéad dul síos, déanann an comhthéacs na pacáistí seo go léir a phróiseáil ksoftirqd/11. Ciallaíonn sé seo gur baineadh paicéid ICMP go croí 11 ag an taobh glactha. Feicimid freisin, aon uair a bhíonn subh ann, go bhfuil paicéid ann a phróiseáiltear i gcomhthéacs ghlao an chórais cadvisor... Ansin ksoftirqd glacann sé an tasc ar láimh agus próiseálann sé an scuaine carntha: go díreach an líon paicéad atá carntha ina dhiaidh cadvisor.
Ar an bhfíric go díreach sula n-oibríonn sé i gcónaí cadvisor, le tuiscint go bhfuil baint aige leis an bhfadhb. Go híorónta, an cuspóir - "anailís a dhéanamh ar úsáid acmhainní agus ar shaintréithe feidhmíochta na gcoimeádán reatha" seachas an tsaincheist feidhmíochta seo a chruthú.
Mar is amhlaidh le gnéithe eile de na coimeádáin, is uirlisí sárfhorbartha iad seo go léir agus beifear ag súil go mbeidh fadhbanna feidhmíochta acu in imthosca áirithe gan choinne.
Cad a dhéanann cadvisor a mhoillíonn scuaine na bpaicéad?
Tá tuiscint mhaith againn anois ar conas a tharlaíonn an timpiste, cén próiseas is cúis leis, agus cén LAP. Feicimid, mar gheall ar bhlocáil chrua, nach bhfuil am ag an eithne Linux sceideal ksoftirqd. Agus feicimid go ndéantar paicéid a phróiseáil i gcomhthéacs cadvisor. Tá sé loighciúil glacadh leis go cadvisor seolann sé syscall mall, agus ina dhiaidh sin déantar gach paicéad a bhailítear ag an am sin a phróiseáil:
Is teoiric é seo, ach conas é a thástáil? Is é an rud is féidir linn a dhéanamh ná croí an LAP a rianú ar fud an phróisis seo, faigh an pointe ina dtéann líon na bpacáistí thar an mbuiséad agus go dtugtar ksoftirqd air, agus ansin breathnú ar ais beagán níos faide chun a fheiceáil cad go díreach a bhí ag rith ar chroílár an LAP díreach roimh an bpointe sin. . Tá sé cosúil le x-ghathú an LAP gach cúpla milleasoicind. Beidh sé cuma rud éigin mar seo:
Go háisiúil, is féidir é seo go léir a dhéanamh le huirlisí atá ann cheana féin. Mar shampla, seiceálann sé croí LAP tugtha ag minicíocht shonraithe agus is féidir leis sceideal glaonna chuig an gcóras reatha a ghiniúint, lena n-áirítear spás úsáideora agus an eithne Linux araon. Is féidir leat an taifead seo a thógáil agus é a phróiseáil le forc beag den chlár ó Brendan Gregg, a chaomhnaíonn ord rian an chruach. Is féidir linn rianta cruachta aonlíne a shábháil gach 1 ms, agus ansin sampla 100 milleasoicindí a aibhsiú agus a shábháil sula mbuaileann an rian ksoftirqd:
# record 999 times a second, or every 1ms with some offset so not to align exactly with timers
sudo perf record -C 11 -g -F 999
# take that recording and make a simpler stack trace.
sudo perf script 2>/dev/null | ./FlameGraph/stackcollapse-perf-ordered.pl | grep ksoftir -B 100
Seo na torthaí:
(сотни следов, которые выглядят похожими)
cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_iter cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;ixgbe_poll;ixgbe_clean_rx_irq;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;bond_handle_frame;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;ipip_tunnel_xmit;ip_tunnel_xmit;iptunnel_xmit;ip_local_out;dst_output;__ip_local_out;nf_hook_slow;nf_iterate;nf_conntrack_in;generic_packet;ipt_do_table;set_match_v4;ip_set_test;hash_net4_kadt;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;hash_net4_test ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;gro_cell_poll;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;dev_queue_xmit_nit;packet_rcv;tpacket_rcv;sch_direct_xmit;validate_xmit_skb_list;validate_xmit_skb;netif_skb_features;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;__dev_queue_xmit;dev_hard_start_xmit;__bpf_prog_run;__bpf_prog_run
Tá a lán rudaí anseo, ach is é an rud is mó ná go bhfaighimid an patrún “cadvisor before ksoftirqd” a chonaic muid níos luaithe sa rianaitheoir ICMP. Céard is brí leis?
Is rian LAP gach líne ag pointe áirithe ama. Scartar leathstad le gach glao síos an chruach ar líne. I lár na línte feicimid an syscall a dtugtar: read(): .... ;do_syscall_64;sys_read; .... Mar sin caitheann cadvisor go leor ama ar an nglao córais read()a bhaineann le feidhmeanna mem_cgroup_* (barr an chairn glaonna/deireadh na líne).
Tá sé deacair a fheiceáil i nglao cad go díreach atá á léamh, mar sin déanaimis rith strace agus féachaimis cad a dhéanann cadvisor agus faighimid glaonna córais níos faide ná 100 ms:
theojulienne@kube-node-bad ~ $ sudo strace -p 10137 -T -ff 2>&1 | egrep '<0.[1-9]'
[pid 10436] <... futex resumed> ) = 0 <0.156784>
[pid 10432] <... futex resumed> ) = 0 <0.258285>
[pid 10137] <... futex resumed> ) = 0 <0.678382>
[pid 10384] <... futex resumed> ) = 0 <0.762328>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 658 <0.179438>
[pid 10384] <... futex resumed> ) = 0 <0.104614>
[pid 10436] <... futex resumed> ) = 0 <0.175936>
[pid 10436] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.228091>
[pid 10427] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.207334>
[pid 10411] <... epoll_ctl resumed> ) = 0 <0.118113>
[pid 10382] <... pselect6 resumed> ) = 0 (Timeout) <0.117717>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 660 <0.159891>
[pid 10417] <... futex resumed> ) = 0 <0.917495>
[pid 10436] <... futex resumed> ) = 0 <0.208172>
[pid 10417] <... futex resumed> ) = 0 <0.190763>
[pid 10417] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 576 <0.154442>
Mar a bheifeá ag súil leis, feicimid glaonna mall anseo read(). Ón ábhar oibríochtaí léite agus comhthéacs mem_cgroup tá sé soiléir go bhfuil na dúshláin seo read() tagairt don chomhad memory.stat, a thaispeánann úsáid chuimhne agus teorainneacha cgroup (teicneolaíocht aonrú acmhainní Docker). Cuireann an uirlis cadvisor ceist ar an gcomhad seo chun faisnéis a fháil faoi úsáid acmhainní le haghaidh coimeádán. Déanaimis seiceáil an bhfuil an t-eithne nó an comhairleoir ag déanamh rud éigin gan choinne:
theojulienne@kube-node-bad ~ $ time cat /sys/fs/cgroup/memory/memory.stat >/dev/null
fíor-0m0.153s
úsáideoir 0m0.000s
córas 0m0.152s
theojulienne@kube-node-bad ~ $
Anois is féidir linn an fabht a atáirgeadh agus a thuiscint go bhfuil an eithne Linux os comhair paiteolaíochta.
Cén fáth a bhfuil an oibríocht léite chomh mall sin?
Ag an gcéim seo, tá sé i bhfad níos éasca teachtaireachtaí a fháil ó úsáideoirí eile faoi fhadhbanna den chineál céanna. Mar a tharla sé, sa rianaitheoir cadvisor tuairiscíodh go raibh an fabht seo , níl ann ach nár thug aon duine faoi deara go bhfuil an latency léirithe go randamach freisin sa chairn líonra. Tugadh faoi deara go deimhin go raibh an cadvisor ag caitheamh níos mó ama LAP ná mar a bhíothas ag súil leis, ach níor tugadh mórán tábhachta dó seo, ós rud é go bhfuil go leor acmhainní LAP ag ár bhfreastalaithe, mar sin níor rinneadh staidéar cúramach ar an bhfadhb.
Is í an fhadhb atá ann go cgroups a chur san áireamh úsáid chuimhne laistigh den ainmspás (coimeádán). Nuair a scoireann gach próiseas sa cgroup seo, scaoileann Docker an cgroup cuimhne. Mar sin féin, ní hamháin cuimhne próisis é "cuimhne". Cé nach n-úsáidtear an chuimhne próisis féin a thuilleadh, dealraíonn sé go sannann an eithne fós inneachar i dtaisce, mar fhiaclóirí agus inóidí (meiteashonraí eolaire agus comhaid), atá i dtaisce sa cgroup cuimhne. Ó chur síos ar an bhfadhb:
cgroups zombie: cgroups nach bhfuil aon phróisis acu agus a scriosadh, ach a bhfuil cuimhne leithdháilte orthu fós (i mo chás, ón taisce fiacla, ach is féidir é a leithdháileadh freisin ón taisce leathanach nó tmpfs).
Féadfaidh seiceáil na heithne ar na leathanaigh go léir sa taisce a bheith an-mhall nuair a bhíonn cgroup á shaoradh, mar sin roghnaítear an próiseas leisciúil: fan go n-iarrtar na leathanaigh seo arís, agus ansin glan an cgroup ar deireadh nuair a bhíonn an chuimhne ag teastáil i ndáiríre. Go dtí an pointe seo, cuirtear cgroup san áireamh fós agus staitisticí á mbailiú.
Ó thaobh feidhmíochta de, rinne siad íobairt cuimhne le haghaidh feidhmíochta: ag luasghéarú an glanta tosaigh trí roinnt cuimhne i dtaisce a fhágáil taobh thiar de. Tá sé seo go breá. Nuair a úsáideann an eithne an ceann deireanach den chuimhne i dtaisce, glantar an cgroup sa deireadh, mar sin ní féidir "sceitheadh" a thabhairt air. Ar an drochuair, cur i bhfeidhm sonrach an mheicníocht chuardaigh memory.stat sa leagan eithne seo (4.9), in éineacht leis an méid mór cuimhne ar ár freastalaithe, ciallaíonn sé go dtógann sé i bhfad níos faide chun na sonraí is déanaí i dtaisce a chur ar ais agus zombies cgroup a ghlanadh.
Tharlaíonn sé go raibh an oiread sin zombies cgroup ag cuid dár nóid gur sháraigh an léamh agus an latency soicind.
Is é an réiteach oibre don fhadhb comhairleoir ná taisceadáin dentries/nóid a shaoradh láithreach ar fud an chórais, rud a chuireann deireadh láithreach le latency léite chomh maith le latency líonra ar an ósta, ós rud é imréitigh an taisce casadh ar na leathanaigh taisce zombie cgroup agus saorann sé iad freisin. Ní réiteach é seo, ach deimhníonn sé cúis na faidhbe.
Tharla sé gur feabhsaíodh feidhmíocht glaonna i leaganacha eithne níos nuaí (4.19+). memory.stat, mar sin shocraigh aistriú chuig an eithne seo an fhadhb. Ag an am céanna, bhí uirlisí againn chun nóid fhadhbacha a bhrath i mbraislí Kubernetes, iad a dhraenáil go galánta agus iad a atosú. Chíoramar na braislí go léir, d'aimsigh muid nóid a raibh latency ard go leor agus d'atosaigh muid iad. Thug sé seo am dúinn an OS a nuashonrú ar na freastalaithe eile.
Achoimre
Toisc gur chuir an fabht seo stop le próiseáil scuaine RX NIC ar feadh na gcéadta milleasoicindí, ba chúis leis ag an am céanna ard-fhoighne ar naisc ghearra agus latency lárnasctha, amhail idir iarratais MySQL agus paicéid freagartha.
Tá tuiscint agus cothabháil ar fheidhmíocht na gcóras is bunúsaí, mar Kubernetes, ríthábhachtach d'iontaofacht agus luas na seirbhísí go léir atá bunaithe orthu. Baineann gach córas a ritheann tú leas as feabhsuithe feidhmíochta Kubernetes.
Foinse: will.com
