2016an Buffer-en gaude , eta orain 60 nodo inguru (AWSn) eta 1500 edukiontzi ari dira lanean gure k8s klusterrean. . Hala ere, mikrozerbitzuetara joan ginen saiakeraren eta erroreen bidez, eta k8s-ekin hainbat urtez lanean egon ondoren ere arazo berrien aurrean gaude. Post honetan buruz hitz egingo dugu prozesadorearen mugak: zergatik uste genuen praktika onak zirela eta zergatik ez ziren hain onak izaten azkenean.
Prozesadorearen mugak eta throttling
Kuberneteseko beste erabiltzaile askok bezala, . Ezarpen hori gabe, nodo bateko edukiorrek prozesadorearen potentzia guztia har dezakete, eta horrek Kubernetes prozesu garrantzitsuak eragiten ditu (adibidez kubelet) eskaerei erantzuteari utziko dio. Beraz, PUZaren mugak ezartzea zure nodoak babesteko modu ona da.
Prozesadorearen mugek edukiontzi bat aldi jakin baterako erabil dezakeen CPU denboraren gehienezko denborarekin ezartzen dute (lehenetsia 100 ms-koa da), eta edukiontziak ez du inoiz muga hori gaindituko. Kubernetes-en itotzea edukiontzia eta muga gaindi ez dezan, tresna berezi bat erabiltzen da , baina CPU muga artifizial hauek errendimenduari kalte egiten diote eta zure edukiontzien erantzun-denbora handitzen dute.
Zer gerta daiteke prozesadorearen mugak ezartzen ez baditugu?
Zoritxarrez, guk geuk arazo honi aurre egin behar izan diogu. Nodo bakoitzak edukiontziak kudeatzeaz arduratzen den prozesu bat du kubelet, eta eskaerei erantzuteari utzi zion. Nodoa, hori gertatzen denean, egoerara joango da NotReady, eta bertatik datozen edukiontziak beste nonbaitera birbideratuko dira eta arazo berdinak sortuko dituzte nodo berrietan. Ez da eszenatoki ideala, zer esanik ez.
Usteltzearen eta erantzunaren arazoaren agerpena
Edukiontzien jarraipena egiteko giltzarria da trottling, zure edukiontzia zenbat aldiz estutu den erakusten du. Interes handiz ohartu ginen edukiontzi batzuetan throttling presentzia, prozesadorearen karga muturrekoa izan ala ez kontuan hartu gabe. Adibide gisa, ikus dezagun gure API nagusietako bati:
Jarraian ikus dezakezun bezala, muga jarri dugu 800m (% 0.8 edo 80 nukleoa), eta gailurreko balioak iristen direnean 200m (%20 nukleoa). Badirudi zerbitzua zapaldu aurretik oraindik prozesadorearen potentzia handia dugula, hala ere...
Baliteke konturatu izana prozesadorearen karga zehaztutako mugen azpitik dagoenean ere - nabarmen azpitik - throttling oraindik gertatzen dela.
Honen aurrean, laster hainbat baliabide aurkitu genituen (, , ) zerbitzuen errendimenduaren eta erantzun denboraren jaitsierari buruz, throttling dela eta.
Zergatik ikusten dugu throttling CPU karga baxuan? Bertsio laburra honako hau da: "Linux nukleoan akats bat dago, prozesadorearen mugak zehaztutako edukiontzien alferrikako murrizketa eragiten duena". Arazoaren izaera interesatzen bazaizu, aurkezpena irakur dezakezu ( и aukerak) Dave Chiluk-ek.
CPU murrizketak kentzea (kontu handiz)
Eztabaida luzeen ostean, gure erabiltzaileentzako funtzionalitate kritikoetan zuzenean edo zeharka eragiten zuten zerbitzu guztietatik prozesadore-murrizketak kentzea erabaki genuen.
Erabakia ez zen erraza izan, gure klusterraren egonkortasuna oso baloratzen dugulako. Iraganean, dagoeneko esperimentatu dugu gure klusterraren ezegonkortasunarekin, eta orduan zerbitzuek baliabide gehiegi kontsumitu eta beren nodo osoaren lana moteldu zuten. Orain dena zertxobait ezberdina zen: argi genuen gure klusterrengandik espero genuena, baita aurreikusitako aldaketak gauzatzeko estrategia on bat ere.
Presazko gai bati buruzko korrespondentzia komertziala.
Nola babestu zure nodoak murrizketak kentzen direnean?
"Mugarik gabeko" zerbitzuen isolamendua:
Iraganean, dagoeneko ikusi dugu nodo batzuk egoera batean sartzen notReady, batez ere baliabide gehiegi kontsumitzen zituzten zerbitzuengatik.
Zerbitzu horiek nodo bereizietan jartzea erabaki genuen, "lotutako" zerbitzuekin oztopa ez dezaten. Ondorioz, nodo batzuk markatuz eta “loturarik gabeko” zerbitzuei tolerantzia-parametroa gehituz, klusterren gaineko kontrol handiagoa lortu genuen, eta errazagoa egin zitzaigun nodoen arazoak identifikatzea. Zuk zeuk antzeko prozesuak burutzeko, ezagutu dezakezu .
Prozesadore eta memoria eskaera zuzena esleitzea:
Gure beldurrik handiena zen prozesuak baliabide gehiegi kontsumituko zituela eta nodoak eskaerei erantzuteari utziko ziola. Orain (Datadog-i esker) gure klusterreko zerbitzu guztiak argi eta garbi kontrolatu genituzkeenez, hainbat hilabeteko funtzionamendua aztertu nuen “loturarik gabeko” gisa izendatu nahi genituenak. PUZaren erabilera maximoa % 20ko marjina batekin ezarri dut, eta, beraz, nodoan espazioa esleitu dut k8s-ek nodoari beste zerbitzu batzuk esleitzen saiatzen bada.
Grafikoan ikus dezakezun bezala, prozesadorearen gehienezko kargara iritsi da 242m CPU nukleoak (0.242 prozesadore nukleoak). Prozesadore eskaera baterako, nahikoa da balio hori baino apur bat handiagoa den zenbaki bat hartzea. Kontuan izan zerbitzuak erabiltzaileengan oinarritzen direnez, karga gailurreko balioak trafikoarekin bat datozela.
Egin gauza bera memoriaren erabilerarekin eta kontsultekin, eta listo - dena prest zaude! Segurtasun handiagoa lortzeko, lekaren eskalatze automatikoa gehi dezakezu. Horrela, baliabideen karga handia den bakoitzean, eskalatze automatikoak pod berriak sortuko ditu, eta kubernetesek espazio librea duten nodoetara banatuko ditu. Klusterean bertan lekurik geratzen ez bada, alerta bat ezar dezakezu edo nodo berriak gehitzea konfigura dezakezu haien eskalatze automatikoaren bidez.
Eragozpenetatik, azpimarratzekoa da galdu genuela “", alegia. nodo batean exekutatzen diren edukiontzi kopurua. Trafiko dentsitate baxuan "erlaxazio" asko ere izan ditzakegu, eta prozesadorearen karga handira iristeko aukera ere badago, baina autoeskalatze-nodoek azken horretan lagundu beharko lukete.
Findings
Pozik nago azken asteotako esperimentuen emaitza bikain hauek argitaratzeaz; dagoeneko hobekuntza nabarmenak ikusi ditugu aldatutako zerbitzu guztietan:
Emaitza onenak gure hasierako orrian lortu ditugu (), hor zerbitzua azkartu zen hogeita bi aldiz!
Konpontzen al da Linux nukleoaren akatsa?
Bai, banaketak 4.19 bertsioa eta berriagoa.
Hala ere, irakurtzean 2020ko irailaren bigarrenerako oraindik ere antzeko akats batekin Linux proiektu batzuen aipamenak topatzen ditugu. Uste dut Linux banaketa batzuek oraindik akats hau dutela eta konpontzen ari direla.
Zure banaketa-bertsioa 4.19 baino baxuagoa bada, azkenera eguneratzea gomendatuko nuke, baina, edonola ere, prozesadorearen murrizketak kentzen saiatu beharko zenuke eta ikusi murrizketak jarraitzen duen. Jarraian Kubernetes kudeaketa zerbitzuen eta Linux banaketaren zerrenda partziala ikus dezakezu:
- Debian: konponketa banaketaren azken bertsioan integratua, , eta nahiko freskoa dirudi (). Baliteke aurreko bertsio batzuk ere konponduta egotea.
- Ubuntu: konponketa azken bertsioan integratuta
- EKS-k konponketa bat lortu du oraindik . Zure bertsioa hau baino txikiagoa bada, AMI eguneratu beharko zenuke.
- kops: у
kops 1.18+Ostalariaren irudi nagusia Ubuntu 20.04 izango da. Zure kops-en bertsio zaharragoa bada, baliteke konponketa baten zain egon behar izatea. Gu geu gaude orain zain. - GKE (Google Cloud): konponketa integratua , hala ere, throttling arazoak daude .
Zer egin konponketak throttling arazoa konpondu badu?
Ez nago ziur arazoa guztiz konpondu denik. Konponketarekin nukleoaren bertsiora iristen garenean, clusterra probatuko dut eta mezua eguneratuko dut. Norbaitek dagoeneko eguneratu badu, zure emaitzak irakurtzea interesatuko litzaidake.
Ondorioa
- Linux-en Docker-eko edukiontziekin lan egiten baduzu (berdin da Kubernetes, Mesos, Swarm edo beste batzuk), zure edukiorrek errendimendua gal dezakete murrizketa dela eta;
- Saiatu zure banaketaren azken bertsiora eguneratzen akatsa dagoeneko konponduta dagoelakoan;
- Prozesadorearen mugak kentzeak arazoa konponduko du, baina kontu handiz erabili behar den teknika arriskutsua da (hobe da lehenik nukleoa eguneratzea eta emaitzak alderatzea);
- PUZaren mugak kendu badituzu, zaindu arretaz zure PUZaren eta memoriaren erabilera eta ziurtatu zure PUZaren baliabideak zure kontsumoa gainditzen ari direla;
- Aukera seguru bat pods automatikoki eskalatzea litzateke, hardware karga handia izanez gero, pod berriak sortzeko, kubernetes-ek doako nodoetara eslei ditzan.
Espero dut mezu honek zure edukiontzi-sistemen errendimendua hobetzen lagunduko dizula.
PS egilea irakurleekin eta iruzkintzaileekin bat egiten du (ingelesez).
Iturria: www.habr.com