🥇CPU piirangud ja agressiivne trottlemine Kuberneteses

Märk. tõlge.: see looja lugu Omio — Euroopa reisikoguja — viib lugejad alates põhiteooriast kuni köitvate praktiliste nüanssideni Kubernetes'i konfiguratsioonis. Selliste juhtumite tundmine aitab mitte ainult silmaringi laiendada, vaid ka vältida keerulisi probleeme.

Kas olete kunagi kogenud olukorda, kus rakendus „seisis” ja lakkas reageerimast oleku kontrollimisele (health check’ide) ning te ei suutnud selle käitumise põhjust mõista? Üks võimalik seletus on seotud CPU ressursside kvoodiga. Sellega me selles artiklis tegeleme.

Lühikokkuvõte:
Soovitame tungivalt loobuda CPU limiitidest Kubernetes'is (või keelata CFS kvoodid Kubelet'is), kui kasutatakse Linuxi kerneli versiooni, millel on CFS kvoodi viga. Kerneli on olemas tõsine ja hästi tuntud bugi, mis põhjustab liialdatud trottlite ja viivitusi..

Omios on kogu infrastruktuur hallatud Kubernetes’i kaudu.. Kõik meie stateful- ja stateless-koormused töötavad eranditult Kubernetesel (kasutame Google Kubernetes Engine'i). Viimase kuue kuu jooksul oleme märganud juhuslikke viivitusi. Rakendused hanguvad või ei vasta enam health check’idele, kaotavad ühenduse võrgu ja nii edasi. See käitumine pani meid pikka aega segadusse, kuni lõpuks otsustasime probleemiga tõsiselt tegeleda.

Artikli kokkuvõte:

Mõned sõnad konteineritest ja Kubernetesest;
Kuidas on rakendatud CPU request’id ja limit’id;
Kuidas CPU limit töötab mitme tuuma keskkondades;
Kuidas jälgida CPU trottling’ut;
Probleemi lahendamine ja nüansid.

Mõned sõnad konteineritest ja Kubernetesest

Kubernetes on sisuliselt kaasaegne standard infrastruktuuri maailmas. Selle peamine ülesanne on konteinerite orkestreerimine.

Konteinerid

Varem pidime looma artefakte, nagu Java JAR’id/WAR’id, Python Egg’id või käivitatavaid faile, et neid hiljem serverites käivitada. Siiski, et need töötaksid, pidi tegema täiendavat tööd: installima jooksva keskkonna (Java/Python), paigaldama vajalikud failid õigesse kohta, tagama ühilduvuse konkreetse operatsioonisüsteemi versiooniga jne. Teisisõnu, pidime pöörama suurt tähelepanu konfiguratsioonihaldusele (mis põhjustas sageli konflikte arendajate ja süsteemiadministraatorite vahel).

Konteinerid on kõik muutnud. Nüüd on artefakt konteinersüsteem. Seda võib näha kui pikendatud käivitatavat faili, mis sisaldab mitte ainult programmi, vaid ka täielikku jooksva keskkonda (Java/Python/…) ning vajalikke faile/pakette, mis on eelinstalleeritud ja valmis käivitamiseks. Konteinerid saab juurutada ja käivitada erinevates serverites ilma täiendavate toiminguteta.

Lisaks toimivad konteinerid omaenese liivakasti keskkonnas. Neil on oma virtuaalne võrgukaart, oma failisüsteem piiratud juurdepääsuga, oma protsesside hierarhia, oma CPU ja mälu piirangud jne. Kõik see on realiseeritud Linuxi tuuma erilise alamsüsteemi — namespaces (nimetuste ruumide) abil.

Kubernetes

Nagu eelnevalt mainitud, on Kubernetes konteinerite orkestreerija. See töötab järgmiselt: te annate sellele masinate hulga ja seejärel ütlete: "Hei, Kubernetes, käivita kümme eksemplari minu konteinerist, igaühel 2 protsessorit ja 3 GB mälu ning hoolda neid!" Kubernetes hoolitseb ülejäänud eest. See leiab vabad ressursid, käivitab konteinerid ja käivitab need vajadusel uuesti, toob välja värskenduse versioonide vahetumisel jne. Üldiselt võimaldab Kubernetes abstraheerida riistvarast ja muudab kõik süsteemide mitmekesisuse rakenduste juurutamiseks ja töötamiseks sobivaks.

Kubernetes igapäevase kasutaja vaatenurgast

Mis on request'id ja limit'id Kuberneteses

Nüüd oleme containerite ja Kubernetes'ega sina peal. Teame, et mitu konteinerit võivad olla ühel masinal.

Võib tuua paralleeli ühisest korterist. Suur ruum (masinad/sõlmed) antakse mitmele üürnikule (konteineritele). Kubernetes mängib maakleri rolli. Tekib küsimus, kuidas hoida üürnikud konfliktideta? Mis juhtub, kui üks neist otsustab näiteks kasutada vannituba poole päevaks?

Siinkohal tulevad mängu request'id ja limit'id. CPU Request on vajalik ainult planeerimiseks. See on nagu konteineri „soovide nimekiri” ja seda kasutatakse sobivaima sõlme leidmiseks. Samal ajal on CPU Limit võimalik võrrelda üürilepinguga — kui oleme leidnud sõlme konteineri jaoks, siis ei saa ületada kehtestatud piire. Ja siin tekib probleem...

Kuidas on Kubernetes'is rakendatud request'e ja limit'e?

Kubernetes kasutab tuumikus sisseehitatud talitlushäire mehhanismi (taimeri saagimine) CPU piirangute rakendamiseks. Kui rakendus ületab piirangu, aktiveeritakse talitlushäire (st see saab vähem CPU taimerit). Mälu jaoks on päringud ja piirangud organiseeritud teistmoodi, seetõttu on need kergemini tuvastatavad. Selleks piisab, kui kontrollida viimast pod’i taaskäivitamise staatust: kas see ei ole 'OOMKilled'. CPU talitlushäiretega pole kõik nii lihtne, kuna K8s teeb kergesti kergesti ligipääsetavaks ainult kasutusstatistika, mitte cgroups'i kohta.

CPU Päring

Kuidas on rakendatud CPU päring

Lihtsuse huvides vaatame protsessi 4-erialise CPU masina näitel.

K8s kasutab ressursside (mälu ja protsessori) jaotuse haldamiseks kontrollrühmade (cgroups) mehhanismi. Sellel on hierarhiline mudel: laps pärib vanema rühma piirangud. Jaotuse üksikasjad salvestatakse virtuaalsesse failisüsteemi (/sys/fs/cgroup). Protsessoriga seotud osas on see /sys/fs/cgroup/cpu,cpuacct/*.

K8s kasutab faili cpu.share sisaldab CPU ressursside jaotamist. Meie juhul saab peamine kontrollgrupp 4096 CPU ressurssi aktsiat — 100% saadaval olevast protsessorivõimsusest (1 tuum = 1024; see on fikseeritud väärtus). Peamine grupp jaotab ressursse proportsionaalselt alluvate aktsiate alusel, mis on määratud cpu.share, ja need omakorda käituvad sarnaselt oma järeltulijatega jne. Tüüpilises Kubernetes'e sõlmes on peamisel kontrollgrupil kolm järeltulijat: system.slice, user.slice ja kubepods. Esimesi kahte alagruppi kasutatakse ressursside jaotamiseks kriitiliste süsteemikoormuste ja kasutajaprogrammide vahel väljaspool K8s. Viimane — kubepods — loob Kubernetes ressursside jaotamiseks pod'ide vahel.

Ülaltoodud skeemilt on näha, et esimesed kaks alagruppi said kumbki 1024 aktsiat, samal ajal kui alagrupile kubepod on eraldatud 4096 aktsiat. Kuidas see on võimalik: peamise grupi jaoks on saadaval ainult 4096 aktsiat, kuid tema alluvate aktsiate summa ületab seda numbrit märkimisväärselt (6144)? Asi on, et väärtus omab loogilist tähendust, seetõttu kasutab Linuxi planeerija (CFS) seda CPU ressursside proportsionaalseks jaotamiseks. Meie puhul saavad esimesed kaks gruppi 680 reaalseid osasid (16,6% 4096-st), samas kui kubepood saab ülejäänud 2736 osasid. Seisaku korral ei kasuta esimesed kaks gruppi eraldatud ressurssi.

Kümmnes, et planeerijal on mehhanism, mis aitab vältida kasutamata CPU ressursside kadu. See suunab „seisakusse” jäävad võimsused globaalsetesse fondidesse, kust need jaotatakse gruppidesse, mis vajavad täiendavaid CPU võimsusi (jaotamine toimub partiitide kaupa, et vältida kadu ümmardamise tõttu). Sarnast meetodit rakendatakse ka kõikide järeltulijate puhul.

See mehhanism tagab CPU võimsuste õiglase jaotamise ja jälgib, et ükski protsess ei „varastaks” ressursse teistelt.

CPU Limit

Kuigi K8si limitide ja requestide konfigureerimised näevad sarnased välja, on nende rakendamine kardinaalselt erinev: see on kõige eksitavam ja väheseima dokumentatsiooni korral.

K8s kasutab CFS kvootide mehhanismi. piiride rakendamiseks. Nende seaded on määratletud failides cfs_period_us ja cfs_quota_us cgroup kaustas (seal asub ka fail cpu.share).

Erinevalt cpu.share, on kvoot põhinev ajaperioodil, mitte saadaval oleval protsessorivõimsusel. cfs_period_us määrab perioodi (ajastu) kestuse – see on alati 100000 µs (100 ms). K8s-is on võimalik seda väärtust muuta, kuid see on hetkel saadaval ainult alfa-versioonis. Planeerija kasutab ajastut kasutatud kvootide taaskäivitamiseks. Teine fail, cfs_quota_us, määrab saadaval oleva aja (kvoodi) iga ajastu jooksul. Pange tähele, et see on samuti antud mikroskeedes. Kvoot võib ületada ajastu kestuse; teisisõnu, see võib olla üle 100 ms.

Vaadakem kahte stsenaariumi 16- tuumasilma masinatel (kõige levinum arvutitüüp meie Omios):

Stsenaarium 1: 2 niiti ja piirang 200 ms. Ilma trottlinguta

Stsenaarium 2: 10 niiti ja piirang 200 ms. Trottling algab pärast 20 ms, juurde pääs protsessori ressurssidele taastub veel 80 ms pärast

Oletame, et olete seadnud CPU piirangu 2 tuum; Kubernetes tõlgib selle väärtuse 200 ms-ks. See tähendaks, et konteiner võib kasutada maksimaalselt 200 ms protsessoriaega ilma throttlinguta.

Ja siin hakkab asi huvitavaks minema. Nagu eelnevalt mainitud, on saadaval olev kvoot 200 ms. Kui teil töötab samal ajal kümme niiti 12-tuumalises masinas (vt stsenaariumi 2 illustratsiooni), samal ajal kui kõik teised pod'id seisavad, kvoot otsa saab juba 20 ms jooksul (kuna 10 * 20 ms = 200 ms), ja kõik selle pod'i voolud "jäävad kinni" (throttle) järgmise 80 ms jooksul. Probleemi halvendab juba mainitud planeerija viga, mille tõttu toimub ülemäärane throttling ja konteiner ei suuda isegi olemasolevat kvooti ära kasutada.

Kuidas hinnata throttlingut pod'ides?

Lihtsalt logige sisse pod'i ja tehke cat /sys/fs/cgroup/cpu/cpu.stat.

nr_periods — planeerija kogupindade arv;
nr_throttled — throttled-perioodide arv; nr_periods;
throttled_time — kogu throttled-aeg nanosekundites.

Mis tegelikult toimub?

Kokkuvõttes saame ühtlast kõrget throttlingut kõigis rakendustes. Mõnikord on see poolteise korra võrra tugevam kui arvutatud!

See to erinevad vead – valmisoleku kontrolle (readiness) põhjustavad tõrked, konteinerite seiskumised, võrguühenduste katkestused ja teenusekõnede ajaviivitused. Lõppkokkuvõttes väljendub see suurema viivituse ja veateate arvu suurenemises.

Lahendus ja tagajärjed

Siin on kõik lihtne. Me loobusime CPU limitidest ja värskendasime klastrite OS-i kerneli kõige uuemaks versiooniks, kus viga oli parandatud. Meie teenustes tekkivate veateadete (HTTP 5xx) arv langes kohe märgatavalt:

HTTP 5xx vead

Ühe kriitilise teenuse HTTP 5xx vead

Vastusaja p95

Kriitilise teenuse päringute viivitus, 95. percentiil

Eksploiteerimise kulud

Kulunud eksemplari-tunnid

Mis on petuouks?

Nagu artikli alguses öeldud:

Võib teha analoogia kommunaalkorteriga… Kubernetes on nagu kinnisvaramaakler. Kuidas aga hoida üürnikud konfliktideta? Mis juhtub, kui üks neist otsustab näiteks võtta vannitoa pooleks päevaks enda kasutusse?

Siin on probleem. Üks kehv konteiner võib ära kasutada kõik masina pöördusressursid. Kui teil on korralik rakenduste virn (näiteks õigesti seadistatud JVM, Go, Node VM), siis ei ole see probleem: sellistes tingimustes saab töötada pikka aega. Aga kui rakendused on halvasti optimeeritud või üldse mitte optimeeritud (FROM java:latest), võib olukord kontrolli alt väljas olla. Meil Omios on automatiseeritud põhja Dockerfiles koos adekvaatsete vaikeseadetega peamiste keelte virna jaoks, seega sellist probleemi ei tekkinud.

Soovitame jälgida mõõdikuid USE (kasutamine, küllastus ja vead), API-late viivitusi ja vigade esinemise sagedust. Jälgige, et tulemused vastaksid ootustele.

Lingid

Selline on meie lugu. Järgmised materjalid aitasid palju mõista, mis toimub:

kernel.org → CFS Scheduler;
kernel.org → CFS Bandwidth Control;
Understanding Linux Container Scheduling;
Everything You Need to Know about Linux Containers, Part I: Linux Control Groups and Process Isolation;
Kubernetes Failure Stories — otsige "cpu throttling".

Kubernetesi veateated:

Kas olete oma praktikas kokku puutunud sarnaste probleemidega või on teil kogemusi konteinerites käituvate tootmiskeskkondade trottlimisega? Jagage oma lugu kommentaarides!