Kthehu në 2016 ne në Buffer , dhe tani rreth 60 nyje (në AWS) dhe 1500 kontejnerë po punojnë në grupin tonë k8s të menaxhuar nga . Megjithatë, ne kaluam në mikroshërbime përmes provave dhe gabimeve, dhe edhe pas disa vitesh pune me k8s, ne ende përballemi me probleme të reja. Në këtë postim do të flasim për kufizimet e procesorit: pse menduam se ishin praktikë e mirë dhe pse përfunduan jo aq të mira.
Kufizimet dhe mbytja e procesorit
Ashtu si shumë përdorues të tjerë të Kubernetes, . Pa një cilësim të tillë, kontejnerët në një nyje mund të marrin të gjithë fuqinë e procesorit, gjë që nga ana tjetër shkakton procese të rëndësishme Kubernetes (për shembull kubelet) do të ndalojë së përgjigjuri ndaj kërkesave. Kështu, vendosja e kufijve të CPU-së është një mënyrë e mirë për të mbrojtur nyjet tuaja.
Kufijtë e procesorit vendosin një kontejner në kohën maksimale të CPU-së që mund të përdorë për një periudhë të caktuar (parazgjedhja është 100 ms) dhe kontejneri nuk do ta kalojë kurrë këtë kufi. Në Kubernetes për mbytëse enë dhe për të parandaluar tejkalimin e kufirit, përdoret një mjet i veçantë , por këto kufizime artificiale të CPU-së përfundojnë duke dëmtuar performancën dhe duke rritur kohën e përgjigjes së kontejnerëve tuaj.
Çfarë mund të ndodhë nëse nuk vendosim kufijtë e procesorit?
Fatkeqësisht, ne vetë duhej të përballeshim me këtë problem. Çdo nyje ka një proces përgjegjës për menaxhimin e kontejnerëve kubelet, dhe ai nuk iu përgjigj kërkesave. Nyja, kur kjo të ndodhë, do të shkojë në gjendje NotReady, dhe kontejnerët prej tij do të ridrejtohen diku tjetër dhe do të krijojnë të njëjtat probleme në nyjet e reja. Jo një skenar ideal, për të thënë të paktën.
Manifestimi i problemit të mbytjes dhe reagimit
Metrika kryesore për gjurmimin e kontejnerëve është trottling, tregon se sa herë është mbytur kontejneri juaj. Vëmë re me interes praninë e mbytjes në disa kontejnerë, pavarësisht nëse ngarkesa e procesorit ishte ekstreme apo jo. Si shembull, le të hedhim një vështrim në një nga API-të tona kryesore:
Siç mund ta shihni më poshtë, ne kemi vendosur kufirin në 800m (0.8 ose 80% thelbi), dhe vlerat maksimale arrijnë në rastin më të mirë 200m (20% bërthamë). Duket se përpara se të ndalojmë shërbimin, ne kemi ende shumë fuqi procesori, megjithatë...
Ju mund të keni vënë re se edhe kur ngarkesa e procesorit është nën kufijtë e specifikuar - dukshëm më poshtë - përsëri ndodh mbytja.
Përballë kësaj, ne së shpejti zbuluam disa burime (, , ) në lidhje me rënien e performancës dhe kohën e përgjigjes së shërbimeve për shkak të mbytjes.
Pse shohim mbytje me ngarkesë të ulët të CPU? Versioni i shkurtër është: "ka një gabim në kernelin Linux që shkakton mbytje të panevojshme të kontejnerëve me kufizime të specifikuara të procesorit." Nëse jeni të interesuar për natyrën e problemit, mund të lexoni prezantimin ( и opsionet) nga Dave Chiluk.
Heqja e kufizimeve të CPU (me kujdes ekstrem)
Pas diskutimeve të gjata, vendosëm të heqim kufizimet e procesorit nga të gjitha shërbimet që ndikuan drejtpërdrejt ose tërthorazi në funksionalitetin kritik për përdoruesit tanë.
Vendimi nuk ishte i lehtë sepse ne vlerësojmë shumë stabilitetin e grupit tonë. Në të kaluarën, ne kemi eksperimentuar tashmë me paqëndrueshmërinë e grupit tonë, dhe më pas shërbimet konsumuan shumë burime dhe ngadalësuan punën e të gjithë nyjës së tyre. Tani gjithçka ishte disi ndryshe: ne kishim një kuptim të qartë të asaj që prisnim nga grupimet tona, si dhe një strategji të mirë për zbatimin e ndryshimeve të planifikuara.
Korrespondencë biznesi për një çështje urgjente.
Si të mbroni nyjet tuaja kur hiqen kufizimet?
Izolimi i shërbimeve "të pakufizuara":
Në të kaluarën, ne kemi parë tashmë disa nyje të marrin një gjendje notReady, kryesisht për shkak të shërbimeve që konsumuan shumë burime.
Ne vendosëm të vendosim shërbime të tilla në nyje të veçanta ("të etiketuara") në mënyrë që ato të mos ndërhyjnë në shërbimet "të lidhura". Si rezultat, duke shënuar disa nyje dhe duke shtuar parametrin e tolerancës në shërbime "të palidhura", ne arritëm një kontroll më të madh mbi grupin dhe u bë më e lehtë për ne të identifikonim problemet me nyjet. Për të kryer vetë procese të ngjashme, mund të njiheni .
Caktimi i një kërkese të saktë për procesorin dhe kujtesën:
Frika jonë më e madhe ishte se procesi do të konsumonte shumë burime dhe nyja do të ndalonte përgjigjen ndaj kërkesave. Meqenëse tani (në sajë të Datadog) ne mund të monitoronim qartë të gjitha shërbimet në grupin tonë, unë analizova disa muaj të funksionimit të atyre që kishim planifikuar t'i përcaktonim si "të palidhura". Unë thjesht vendosa përdorimin maksimal të CPU-së me një diferencë prej 20%, dhe kështu ndava hapësirë në nyje në rast se k8s përpiqet të caktojë shërbime të tjera në nyje.
Siç mund ta shihni në grafik, ngarkesa maksimale në procesor ka arritur 242m Bërthamat e procesorit (0.242 bërthama procesori). Për një kërkesë për procesor, mjafton të merret një numër pak më i madh se kjo vlerë. Ju lutemi vini re se meqenëse shërbimet janë të përqendruara te përdoruesi, vlerat e ngarkesës maksimale përkojnë me trafikun.
Bëni të njëjtën gjë me përdorimin e kujtesës dhe pyetjet, dhe voila - jeni gati! Për siguri më të madhe, mund të shtoni shkallëzimin automatik të podeve horizontale. Kështu, sa herë që ngarkesa e burimeve është e lartë, shkallëzimi automatik do të krijojë pods të rinj dhe kubernetes do t'i shpërndajë ato në nyje me hapësirë të lirë. Në rast se nuk ka hapësirë në vetë grupimin, mund t'i vendosni vetes një alarm ose të konfiguroni shtimin e nyjeve të reja përmes shkallëzimit automatik të tyre.
Nga minuset, vlen të përmendet se ne humbëm në "", d.m.th. numri i kontejnerëve që funksionojnë në një nyje. Mund të kemi gjithashtu shumë "relaksime" me densitet të ulët trafiku, dhe ka gjithashtu një shans që të arrini një ngarkesë të lartë të procesorit, por nyjet e shkallëzimit automatik duhet të ndihmojnë me këtë të fundit.
Gjetjet
Jam i kënaqur të publikoj këto rezultate të shkëlqyera nga eksperimentet gjatë javëve të fundit; ne kemi parë tashmë përmirësime të rëndësishme në përgjigje në të gjitha shërbimet e modifikuara:
Ne arritëm rezultatet më të mira në faqen tonë kryesore (), atje shërbimi u përshpejtua njëzet e dy herë!
A është rregulluar gabimi i kernelit Linux?
Po, shpërndarjet versioni 4.19 dhe më i lartë.
Megjithatë, me leximin për datën e dytë të shtatorit 2020 ne ende hasim përmendje të disa projekteve Linux me një gabim të ngjashëm. Unë besoj se disa shpërndarje Linux e kanë ende këtë gabim dhe thjesht po punojnë për ta rregulluar atë.
Nëse versioni juaj i shpërndarjes është më i ulët se 4.19, unë do të rekomandoja përditësimin në versionin më të fundit, por në çdo rast duhet të provoni të hiqni kufizimet e procesorit dhe të shihni nëse mbytja vazhdon. Më poshtë mund të shihni një listë të pjesshme të shërbimeve të menaxhimit të Kubernetes dhe shpërndarjeve Linux:
- Debian: rregullim i integruar në versionin më të fundit të shpërndarjes, , dhe duket mjaft e freskët (). Disa versione të mëparshme mund të rregullohen gjithashtu.
- Ubuntu: rregullim i integruar në versionin më të fundit
- EKS ka ende një rregullim . Nëse versioni juaj është më i ulët se ky, duhet të përditësoni AMI-në.
- kops: у
kops 1.18+Imazhi kryesor i hostit do të jetë Ubuntu 20.04. Nëse versioni juaj i kops është më i vjetër, mund t'ju duhet të prisni për një rregullim. Ne vetë jemi duke pritur tani. - GKE (Google Cloud): Rregullimi i integruar , megjithatë ka probleme me mbytjen .
Çfarë duhet të bëni nëse rregullimi rregulloi problemin e mbytjes?
Nuk jam i sigurt se problemi është zgjidhur plotësisht. Kur të arrijmë te versioni i kernelit me rregullimin, unë do të testoj grupin dhe do të përditësoj postimin. Nëse dikush ka përditësuar tashmë, do të isha i interesuar të lexoja rezultatet tuaja.
Përfundim
- Nëse punoni me kontejnerë Docker nën Linux (pa marrë parasysh Kubernetes, Mesos, Swarm ose të tjerë), kontejnerët tuaj mund të humbasin performancën për shkak të mbytjes;
- Provoni të përditësoni në versionin më të fundit të shpërndarjes tuaj me shpresën se defekti është rregulluar tashmë;
- Heqja e kufijve të procesorit do ta zgjidhë problemin, por kjo është një teknikë e rrezikshme që duhet përdorur me kujdes ekstrem (është më mirë që fillimisht të përditësoni kernelin dhe të krahasoni rezultatet);
- Nëse i keni hequr kufijtë e CPU-së, monitoroni me kujdes përdorimin e CPU-së dhe kujtesës dhe sigurohuni që burimet e CPU-së të tejkalojnë konsumin tuaj;
- Një opsion i sigurt do të ishte që pod-et të shkallëzohen automatikisht për të krijuar pod-e të reja në rast të ngarkesës së lartë të harduerit, në mënyrë që kubernetes t'i caktojë ato në nyje të lira.
Shpresoj që ky postim t'ju ndihmojë të përmirësoni performancën e sistemeve tuaja të kontejnerëve.
PS autori korrespondon me lexuesit dhe komentuesit (në anglisht).
Burimi: www.habr.com