Terug in 2016 het ons by Buffer , en nou werk ongeveer 60 nodusse (op AWS) en 1500 houers aan ons k8s-kluster wat bestuur word deur . Ons het egter deur beproewing en fout na mikrodienste oorgegaan, en selfs na 'n paar jaar se werk met k8's word ons steeds met nuwe probleme gekonfronteer. In hierdie pos sal ons praat oor verwerker beperkings: hoekom ons gedink het dit is goeie praktyk en hoekom hulle uiteindelik nie so goed was nie.
Verwerkerbeperkings en versnelling
Soos baie ander Kubernetes-gebruikers, . Sonder so 'n instelling kan houers in 'n nodus al die verwerkerkrag opneem, wat weer belangrike Kubernetes-prosesse veroorsaak (bv. kubelet) sal ophou om op versoeke te reageer. Die opstel van SVE-limiete is dus 'n goeie manier om u nodusse te beskerm.
Verwerkerlimiete stel 'n houer op die maksimum SVE-tyd wat dit vir 'n spesifieke tydperk kan gebruik (verstek is 100ms), en die houer sal nooit hierdie limiet oorskry nie. In Kubernetes vir versmoor houer en verhoed dat dit die limiet oorskry, word 'n spesiale gereedskap gebruik , maar hierdie kunsmatige SVE-limiete benadeel uiteindelik die werkverrigting en verhoog die reaksietyd van jou houers.
Wat kan gebeur as ons nie verwerkerlimiete stel nie?
Ongelukkig moes ons self hierdie probleem die hoof bied. Elke nodus het 'n proses wat verantwoordelik is vir die bestuur van houers kubelet, en hy het opgehou om op versoeke te reageer. Die nodus, wanneer dit gebeur, sal in die staat gaan NotReady, en houers daarvan sal iewers anders herlei word en dieselfde probleme op nuwe nodusse skep. Nie 'n ideale scenario nie, om die minste te sê.
Manifestasie van die probleem van versnelling en reaksie
Die sleutelmaatstaf vir houeropsporing is trottling, wys dit hoeveel keer jou houer versmoor is. Ons het met belangstelling die teenwoordigheid van versnelling in sommige houers opgemerk, ongeag of die verwerkerlas ekstreem was of nie. As voorbeeld, kom ons kyk na een van ons hoof-API's:
Soos u hieronder kan sien, het ons die limiet gestel 800m (0.8 of 80% kern), en piekwaardes bereik ten beste 200m (20% kern). Dit wil voorkom asof ons nog baie verwerkerkrag het voordat ons die diens versmoor ...
U het dalk opgemerk dat selfs wanneer die verwerkerlading onder die gespesifiseerde limiete is - aansienlik onder - versnelling steeds plaasvind.
Gekonfronteer met hierdie, het ons gou ontdek verskeie hulpbronne (, , ) oor die daling in werkverrigting en reaksietyd van dienste as gevolg van versnelling.
Hoekom sien ons versnelling by lae SVE-lading? Die kort weergawe is: "daar is 'n fout in die Linux-kern wat onnodige verswakking van houers met gespesifiseerde verwerkerlimiete veroorsaak." As jy belangstel in die aard van die probleem, kan jy die aanbieding lees ( и opsies) deur Dave Chiluk.
Verwyder SVE-beperkings (met uiterste versigtigheid)
Na lang besprekings het ons besluit om verwerkerbeperkings van alle dienste te verwyder wat kritiese funksionaliteit vir ons gebruikers direk of indirek beïnvloed het.
Die besluit was nie maklik nie, want ons waardeer die stabiliteit van ons groep hoog. In die verlede het ons reeds geëksperimenteer met die onstabiliteit van ons groepering, en toe het die dienste te veel hulpbronne verbruik en die werk van hul hele nodus vertraag. Nou was alles ietwat anders: ons het 'n duidelike begrip gehad van wat ons van ons klusters verwag het, sowel as 'n goeie strategie vir die implementering van die beplande veranderinge.
Sakekorrespondensie oor 'n dringende kwessie.
Hoe om u nodusse te beskerm wanneer beperkings opgehef word?
Isolasie van "onbeperkte" dienste:
In die verlede het ons al gesien hoe sommige nodusse in 'n toestand kom notReady, hoofsaaklik as gevolg van dienste wat te veel hulpbronne verbruik het.
Ons het besluit om sulke dienste in aparte ("gemerkte") nodusse te plaas sodat hulle nie met "verwante" dienste inmeng nie. As gevolg hiervan, deur sommige nodusse te merk en die toleransieparameter by "onverwante" dienste te voeg, het ons groter beheer oor die groepie verkry, en dit het vir ons makliker geword om probleme met nodusse te identifiseer. Om self soortgelyke prosesse uit te voer, kan jy jouself daarmee vergewis .
Toewysing van 'n korrekte verwerker en geheue versoek:
Ons grootste vrees was dat die proses te veel hulpbronne sou verbruik en die nodus sou ophou om op versoeke te reageer. Aangesien ons nou (danksy Datadog) al die dienste op ons groepering duidelik kon monitor, het ek 'n paar maande se werking ontleed van dié wat ons beplan het om as "onverwant" aan te wys. Ek het bloot die maksimum SVE-gebruik met 'n marge van 20% gestel, en sodoende spasie in die nodus toegewys ingeval k8s probeer om ander dienste aan die nodus toe te wys.
Soos jy in die grafiek kan sien, het die maksimum las op die verwerker bereik 242m SVE-kerne (0.242 verwerkerkerne). Vir 'n verwerkerversoek is dit genoeg om 'n getal effens groter as hierdie waarde te neem. Neem asseblief kennis dat aangesien die dienste gebruikergesentreerd is, piekladingswaardes saamval met verkeer.
Doen dieselfde met geheuegebruik en navrae, en voila - jy is alles opgestel! Vir groter sekuriteit, kan jy horisontale peul-outoskaal byvoeg. Dus, elke keer as die hulpbronlading hoog is, sal outoskaal nuwe peule skep, en kubernete sal hulle na nodusse met vrye spasie versprei. As daar geen spasie in die groep self oor is nie, kan jy vir jouself 'n waarskuwing instel of die byvoeging van nuwe nodusse opstel deur hul outoskaal.
Van die minusse is dit opmerklik dat ons verloor het in "", d.w.s. aantal houers wat op een nodus loop. Ons het dalk ook baie "ontspannings" teen lae verkeersdigtheid, en daar is ook 'n kans dat jy 'n hoë verwerkerlading sal bereik, maar outoskaalnodusse behoort met laasgenoemde te help.
Bevindinge
Ek is bly om hierdie uitstekende resultate van eksperimente oor die afgelope paar weke te publiseer; ons het reeds beduidende verbeterings in reaksie oor alle gewysigde dienste gesien:
Ons het die beste resultate op ons tuisblad behaal (), daar het die diens versnel twee en twintig keer!
Is die Linux-kernfout reggestel?
Ja, verspreidings weergawe 4.19 en hoër.
Maar by lees vir die tweede September 2020 ons kry steeds meldings van sommige Linux-projekte met 'n soortgelyke fout. Ek glo dat sommige Linux-verspreidings steeds hierdie fout het en net besig is om dit reg te stel.
As u verspreidingsweergawe laer as 4.19 is, sal ek aanbeveel dat u na die nuutste opdateer, maar u moet in elk geval probeer om die verwerkerbeperkings te verwyder en te kyk of die versnelling voortduur. Hieronder kan u 'n gedeeltelike lys van Kubernetes-bestuursdienste en Linux-verspreidings sien:
- Debian: fix geïntegreer in die nuutste weergawe van die verspreiding, , en lyk redelik vars (). Sommige vorige weergawes kan ook reggestel word.
- Ubuntu: herstel geïntegreer in die nuutste weergawe
- EKS het nog 'n oplossing gekry . As jou weergawe laer as dit is, moet jy die AMI opdateer.
- kops: у
kops 1.18+Die hoofgasheerbeeld sal Ubuntu 20.04 wees. As jou weergawe van kops ouer is, moet jy dalk wag vir 'n oplossing. Ons self wag nou. - GKE (Google Wolk): Herstel geïntegreer , maar daar is probleme met versnelling .
Wat om te doen as die oplossing die versnellingsprobleem opgelos het?
Ek is nie seker die probleem is heeltemal opgelos nie. Wanneer ons by die kernweergawe met die regstelling kom, sal ek die cluster toets en die pos opdateer. As iemand reeds opgedateer het, sal ek belangstel om jou resultate te lees.
Gevolgtrekking
- As jy met Docker-houers onder Linux werk (maak nie saak Kubernetes, Mesos, Swarm of ander nie), kan jou houers werkverrigting verloor as gevolg van versnelling;
- Probeer om op te dateer na die nuutste weergawe van jou verspreiding in die hoop dat die fout reeds reggestel is;
- Die verwydering van verwerkerlimiete sal die probleem oplos, maar dit is 'n gevaarlike tegniek wat met uiterste omsigtigheid gebruik moet word (dit is beter om eers die kern op te dateer en die resultate te vergelyk);
- As jy SVE-limiete verwyder het, monitor jou SVE en geheuegebruik noukeurig en maak seker dat jou SVE-hulpbronne jou verbruik oorskry;
- 'n Veilige opsie sou wees om peule outomaties te skaal om nuwe peule te skep in geval van hoë hardewarelading, sodat kubernetes hulle aan vrye nodusse toewys.
Ek hoop dat hierdie pos jou help om die werkverrigting van jou houerstelsels te verbeter.
PS die skrywer korrespondeer met lesers en kommentators (in Engels).
Bron: will.com