2016 m. mes buferyje , o dabar apie 60 mazgų (AWS) ir 1500 konteinerių dirba mūsų k8s klasteryje, kurį valdo . Tačiau bandymų ir klaidų būdu perėjome prie mikroservisų ir net po kelerių metų darbo su k8 vis dar susiduriame su naujomis problemomis. Šiame įraše kalbėsime apie procesoriaus apribojimai: kodėl manėme, kad tai buvo gera praktika ir kodėl jos nebuvo tokios geros.
Procesoriaus apribojimai ir droselis
Kaip ir daugelis kitų „Kubernetes“ vartotojų, . Be tokio nustatymo konteineriai mazge gali užimti visą procesoriaus galią, o tai savo ruožtu sukelia svarbius Kubernetes procesus (pvz. kubelet) nustos atsakyti į užklausas. Taigi procesoriaus apribojimų nustatymas yra geras būdas apsaugoti mazgus.
Procesoriaus apribojimai nustato didžiausią talpyklos procesoriaus laiką, kurį jis gali naudoti tam tikrą laikotarpį (numatytasis yra 100 ms), ir konteineris niekada neviršys šios ribos. In Kubernetes už droselis konteinerį ir neleisti jam viršyti ribos, naudojamas specialus įrankis , tačiau šie dirbtiniai procesoriaus apribojimai pablogina našumą ir padidina sudėtinių rodinių atsako laiką.
Kas gali nutikti, jei nenustatysime procesoriaus apribojimų?
Deja, mums patiems teko susidurti su šia problema. Kiekvienas mazgas turi procesą, atsakingą už konteinerių valdymą kubelet, ir jis nustojo atsakyti į užklausas. Kai tai įvyks, mazgas pereis į būseną NotReady, o konteineriai iš jo bus nukreipti kur nors kitur ir sukurs tas pačias problemas naujuose mazguose. Ne idealus scenarijus, švelniai tariant.
Droselio ir atsako problemos pasireiškimas
Pagrindinė konteinerio stebėjimo metrika yra trottling, rodoma, kiek kartų konteineris buvo užblokuotas. Su susidomėjimu pastebėjome, kad kai kuriuose konteineriuose yra droselis, neatsižvelgiant į tai, ar procesoriaus apkrova buvo didelė, ar ne. Pavyzdžiui, pažvelkime į vieną iš pagrindinių API:
Kaip matote toliau, nustatėme ribą iki 800m (0.8 arba 80 % branduolio) ir didžiausios vertės geriausiu pasiekiamumu 200m (20 % branduolio). Atrodytų, kad prieš stabdydami paslaugą dar turime pakankamai procesoriaus galios, tačiau...
Galbūt pastebėjote, kad net tada, kai procesoriaus apkrova yra mažesnė už nurodytas ribas - žymiai mažesnė - droselis vis tiek vyksta.
Atsižvelgdami į tai, netrukus atradome keletą išteklių (, , ) apie paslaugų našumo ir atsako laiko sumažėjimą dėl droselio.
Kodėl matome droselį esant mažai procesoriaus apkrovai? Trumpa versija yra tokia: „Linux branduolyje yra klaida, dėl kurios be reikalo ribojami konteineriai su nurodytais procesoriaus apribojimais“. Jei jus domina problemos pobūdis, galite perskaityti pristatymą ( и parinktys) pateikė Dave Chiluk.
CPU apribojimų pašalinimas (labai atsargiai)
Po ilgų diskusijų nusprendėme pašalinti procesoriaus apribojimus visoms paslaugoms, kurios tiesiogiai ar netiesiogiai turėjo įtakos mūsų vartotojų kritinėms funkcijoms.
Sprendimas nebuvo lengvas, nes labai vertiname savo klasterio stabilumą. Anksčiau jau eksperimentavome su savo klasterio nestabilumu, tada paslaugos sunaudodavo per daug resursų ir sulėtino viso savo mazgo darbą. Dabar viskas buvo kiek kitaip: turėjome aiškų supratimą, ko tikimės iš savo klasterių, taip pat gerą strategiją, kaip įgyvendinti planuojamus pokyčius.
Verslo korespondencija aktualia problema.
Kaip apsaugoti mazgus panaikinus apribojimus?
„Neribotų“ paslaugų išskyrimas:
Praeityje jau matėme, kad kai kurie mazgai pateko į būseną notReady, visų pirma dėl paslaugų, kurios sunaudojo per daug išteklių.
Nusprendėme tokias paslaugas talpinti į atskirus („paženklintus“) mazgus, kad jos netrukdytų „susijusioms“ paslaugoms. Dėl to, pažymėję kai kuriuos mazgus ir įtraukę tolerancijos parametrą prie „nesusijusių“ paslaugų, pasiekėme didesnę klasterio kontrolę, o mums tapo lengviau nustatyti mazgų problemas. Norėdami patys atlikti panašius procesus, galite susipažinti su .
Tinkamo procesoriaus ir atminties užklausos priskyrimas:
Didžiausia baimė buvo ta, kad procesas sunaudos per daug išteklių ir mazgas nustos reaguoti į užklausas. Kadangi dabar (dėka „Datadog“) galime aiškiai stebėti visas savo klasterio paslaugas, išanalizavau kelių mėnesių veikimą tų, kurias planavome priskirti „nesusijusioms“. Aš tiesiog nustatiau maksimalų procesoriaus naudojimą su 20% marža ir taip paskirstau vietos mazge, jei k8s bandytų priskirti mazgui kitas paslaugas.
Kaip matote diagramoje, maksimali procesoriaus apkrova pasiekė 242m CPU branduoliai (0.242 procesoriaus branduolių). Procesoriaus užklausai pakanka paimti šiek tiek didesnį skaičių nei ši vertė. Atminkite, kad paslaugos yra orientuotos į vartotoją, todėl didžiausios apkrovos vertės sutampa su srautu.
Atlikite tą patį su atminties naudojimu ir užklausomis, ir voila – viskas nustatyta! Siekiant didesnio saugumo, galite pridėti horizontalųjį automatinį mastelio keitimą. Taigi kiekvieną kartą, kai išteklių apkrova yra didelė, automatinis mastelio keitimas sukurs naujus blokus, o kubernetes paskirstys juos mazgams, kuriuose yra laisvos vietos. Jei pačiame klasteryje neliko vietos, galite nustatyti sau įspėjimą arba sukonfigūruoti naujų mazgų pridėjimą naudodami automatinį jų mastelį.
Iš minusų verta paminėti, kad pralaimėjome „", t.y. konteinerių, veikiančių viename mazge, skaičius. Taip pat galime turėti daug „atsipalaidavimo“ esant mažam srauto tankiui, taip pat yra tikimybė, kad pasieksite didelę procesoriaus apkrovą, tačiau pastarajam turėtų padėti automatinio mastelio mazgai.
rezultatai
Džiaugiuosi galėdamas paskelbti šiuos puikius pastarųjų kelių savaičių eksperimentų rezultatus; jau pastebėjome reikšmingus visų pakeistų paslaugų patobulinimus:
Geriausius rezultatus pasiekėme savo pagrindiniame puslapyje (), ten paslauga paspartėjo dvidešimt du kartus!
Ar ištaisyta Linux branduolio klaida?
Taip, platinimų 4.19 ir naujesnės versijos.
Tačiau perskaičius 2020 metų rugsėjo antrajai dienai vis dar susiduriame su kai kurių Linux projektų su panašia klaida paminėjimais. Manau, kad kai kurie „Linux“ platinimai vis dar turi šią klaidą ir tik stengiasi ją ištaisyti.
Jei jūsų platinimo versija yra žemesnė nei 4.19, rekomenduočiau atnaujinti į naujausią, tačiau bet kuriuo atveju turėtumėte pabandyti pašalinti procesoriaus apribojimus ir pažiūrėti, ar ribojimas išlieka. Žemiau galite pamatyti dalinį Kubernetes valdymo paslaugų ir Linux platinimų sąrašą:
- Debian: pataisymas integruotas į naujausią platinimo versiją, ir atrodo visai šviežiai (). Kai kurios ankstesnės versijos taip pat gali būti pataisytos.
- Ubuntu: pataisymas integruotas į naujausią versiją
- EKS dar turi pataisymą . Jei jūsų versija yra senesnė nei ši, turėtumėte atnaujinti AMI.
- kops: у
kops 1.18+Pagrindinis kompiuterio vaizdas bus Ubuntu 20.04. Jei jūsų kops versija senesnė, gali tekti palaukti, kol bus pataisyta. Mes patys dabar laukiame. - GKE („Google Cloud“): integruotas pataisymas , tačiau yra problemų su droseliu .
Ką daryti, jei pataisymas išsprendė droselio problemą?
Nesu tikras, kad problema visiškai išspręsta. Kai pasieksime branduolio versiją su pataisymu, išbandysiu klasterį ir atnaujinsiu įrašą. Jei kas nors jau atnaujino, man būtų įdomu paskaityti jūsų rezultatus.
išvada
- Jei dirbate su „Docker“ konteineriais sistemoje „Linux“ (nesvarbu, „Kubernetes“, „Mesos“, „Swarm“ ar kt.), jūsų konteineriai gali prarasti našumą dėl droselio;
- Pabandykite atnaujinti į naujausią platinimo versiją, tikėdamiesi, kad klaida jau buvo ištaisyta;
- Procesoriaus apribojimų pašalinimas išspręs problemą, tačiau tai pavojinga technika, kurią reikia naudoti labai atsargiai (geriau pirmiausia atnaujinti branduolį ir palyginti rezultatus);
- Jei pašalinote procesoriaus apribojimus, atidžiai stebėkite procesoriaus ir atminties naudojimą ir įsitikinkite, kad procesoriaus ištekliai viršija jūsų suvartojimą;
- Saugus pasirinkimas būtų automatinio mastelio keitimas, kad būtų sukurtos naujos aparatinės įrangos apkrovos, kad kubernetes priskirtų juos laisviems mazgams.
Tikiuosi, kad šis įrašas padės pagerinti konteinerių sistemų našumą.
PS autorius susirašinėja su skaitytojais ir komentatoriais (anglų kalba).
Šaltinis: www.habr.com