27. apríl á ráðstefnunni , sem hluti af „DevOps“ hlutanum, var skýrslan „Sjálfvirk stærð og auðlindastjórnun í Kubernetes“ gefin. Það talar um hvernig þú getur notað K8s til að tryggja mikið framboð á forritunum þínum og tryggja hámarksafköst.
Samkvæmt hefð erum við ánægð að kynna (44 mínútur, mun fróðlegri en greinin) og aðalsamantekt í textaformi. Farðu!
Við skulum greina efni skýrslunnar orð fyrir orð og byrja á endanum.
Kubernetes
Segjum að við höfum Docker gáma á gestgjafanum okkar. Til hvers? Til að tryggja endurtekningarhæfni og einangrun, sem aftur gerir kleift að nota einfalda og góða dreifingu, CI/CD. Við eigum mörg slík farartæki með gámum.
Hvað veitir Kubernetes í þessu tilfelli?
- Við hættum að hugsa um þessar vélar og byrjum að vinna með „skýið“ þyrping gáma eða fræbelgur (ílátahópar).
- Þar að auki hugsum við ekki einu sinni um einstaka belg, heldur stjórnum meiraоstærri hópa. Svona frumstæður á háu stigi leyfðu okkur að segja að það sé til sniðmát til að keyra ákveðið vinnuálag, og hér er nauðsynlegur fjöldi tilvika til að keyra það. Ef við breytum sniðmátinu í kjölfarið munu öll tilvik breytast.
- Með yfirlýsingar API Í stað þess að framkvæma röð af sérstökum skipunum lýsum við „byggingu heimsins“ (í YAML), sem er búin til af Kubernetes. Og aftur: þegar lýsingin breytist mun raunveruleg birting hennar einnig breytast.
Auðlindastjórnun
CPU
Leyfðu okkur að keyra nginx, php-fpm og mysql á þjóninum. Þessi þjónusta mun í raun hafa enn fleiri ferli í gangi, sem hvert um sig krefst tölvuauðlinda:
(tölurnar á glærunni eru „páfagaukar“, óhlutbundin þörf hvers ferlis fyrir tölvuafl)
Til að gera það auðveldara að vinna með þetta er rökrétt að sameina ferla í hópa (til dæmis öll nginx ferli í einn hóp “nginx”). Einföld og augljós leið til að gera þetta er að setja hvern hóp í ílát:
Til að halda áfram þarftu að muna hvað gámur er (í Linux). Útlit þeirra var gert mögulegt þökk sé þremur lykileiginleikum í kjarnanum, sem voru innleiddir fyrir nokkuð löngu síðan: , и . Og frekari þróun var auðveldað með annarri tækni (þar á meðal þægilegum „skeljum“ eins og Docker):
Í tengslum við skýrsluna höfum við aðeins áhuga á hópar, vegna þess að stýrihópar eru sá hluti af virkni gáma (Docker, o.s.frv.) sem innleiðir auðlindastjórnun. Ferlar sameinaðir í hópa, eins og við vildum, eru stjórnhópar.
Snúum okkur aftur að örgjörvakröfunum fyrir þessi ferli, og nú fyrir hópa ferla:
(Ég endurtek að allar tölur eru óhlutbundin tjáning á þörfinni fyrir fjármagn)
Á sama tíma hefur örgjörvinn sjálfur ákveðinn endanlegur auðlind (í dæminu er þetta 1000), sem alla kann að vanta (summa þarfa allra hópa er 150+850+460=1460). Hvað mun gerast í þessu tilfelli?
Kjarninn byrjar að dreifa auðlindum og gerir það „sanngjarnt“ og gefur hverjum hópi sama magn af auðlindum. En í fyrra tilvikinu eru þær fleiri en þarf (333>150), þannig að umframmagnið (333-150=183) er áfram í varasjóði, sem einnig er jafnt dreift á milli tveggja annarra gáma:
Fyrir vikið: fyrsti gámurinn hafði nóg fjármagn, annað - það hafði ekki nóg fjármagn, það þriðja - það hafði ekki nóg fjármagn. Þetta er afleiðing aðgerða "heiðarlegur" tímaáætlun í Linux - . Hægt er að stilla virkni þess með því að nota verkefnið þyngd hvern ílát. Til dæmis, svona:
Við skulum skoða tilfelli skorts á fjármagni í seinni ílátinu (php-fpm). Öllum gámaauðlindum er dreift jafnt á milli ferla. Fyrir vikið virkar aðalferlið vel, en allir starfsmenn hægja á sér og fá minna en helming þess sem þeir þurfa:
Svona virkar CFS tímaáætlunin. Við munum frekar kalla lóðin sem við úthlutum í gáma beiðnir. Hvers vegna þetta er svona - sjá nánar.
Við skulum skoða alla stöðuna frá hinni hliðinni. Eins og þú veist, liggja allir vegir til Rómar, og ef um tölvu er að ræða, til CPU. Einn örgjörvi, mörg verkefni - þú þarft umferðarljós. Einfaldasta leiðin til að stjórna tilföngum er „umferðarljós“: þeir gáfu einu ferli fastan aðgangstíma að örgjörvanum, síðan næsta o.s.frv.
Þessi aðferð er kölluð harður kvóti (harðar takmarkanir). Við skulum muna það einfaldlega sem takmörk. Hins vegar, ef þú dreifir takmörkunum á alla gáma, kemur upp vandamál: mysql var að keyra eftir veginum og á einhverjum tímapunkti lauk þörfinni fyrir CPU, en öll önnur ferli neyðast til að bíða þar til CPU aðgerðalaus.
Snúum okkur aftur að Linux kjarnanum og samspili hans við CPU - heildarmyndin er sem hér segir:
cgroup hefur tvær stillingar - í raun eru þetta tvær einfaldar „snúningar“ sem gera þér kleift að ákvarða:
- þyngd fyrir ílát (beiðnir) er hlutabréf;
- hlutfall af heildar CPU tíma fyrir að vinna við gámaverkefni (takmörk) er kvóta.
Hvernig á að mæla CPU?
Það eru mismunandi leiðir:
- hvað páfagaukur, það veit enginn - þú þarft að semja í hvert skipti.
- Vextir skýrari, en afstætt: 50% af þjóni með 4 kjarna og með 20 kjarna eru allt aðrir hlutir.
- Þú getur notað þau sem þegar hafa verið nefnd þyngd, sem Linux þekkir, en þeir eru líka afstæðir.
- Besti kosturinn er að mæla tölvuauðlindir í sekúndur. Þeir. í sekúndum af örgjörvatíma miðað við sekúndur af rauntíma: 1 sekúnda af örgjörvatíma var gefin á 1 raunsekúndu - þetta er einn heill CPU kjarna.
Til að gera það enn auðveldara að tala fóru þeir að mæla beint inn kjarna, sem þýðir af þeim sama CPU tíma miðað við raunverulegan. Þar sem Linux skilur þyngd, en ekki svo mikinn CPU tíma/kjarna, þurfti vélbúnaður til að þýða úr einu yfir í annað.
Við skulum íhuga einfalt dæmi með netþjóni með 3 CPU kjarna, þar sem þrír belg fá þyngd (500, 1000 og 1500) sem auðvelt er að breyta í samsvarandi hluta kjarna sem þeim er úthlutað (0,5, 1 og 1,5).
Ef þú tekur annan netþjón, þar sem það verða tvöfalt fleiri kjarna (6), og setur sömu belg þar, er auðvelt að reikna út dreifingu kjarna með því einfaldlega að margfalda með 2 (1, 2 og 3, í sömu röð). En mikilvægt augnablik á sér stað þegar fjórði belgurinn birtist á þessum netþjóni, en þyngd hans, til hægðarauka, verður 3000. Það tekur í burtu hluta af CPU auðlindum (helmingur kjarna), og fyrir þá belg sem eftir eru eru þeir endurreiknaðir (helmingaðir):
Kubernetes og CPU auðlindir
Í Kubernetes eru örgjörvaauðlindir venjulega mældar í milliadrax, þ.e. 0,001 kjarni er tekinn sem grunnþyngd. (Það sama í Linux/cgroups hugtökum er kallað CPU hlutdeild, þó, nánar tiltekið, 1000 millikjarna = 1024 CPU deilir.) K8s tryggir að það setji ekki fleiri pods á þjóninn en það eru CPU auðlindir fyrir summan af þyngd allra pods.
Hvernig gerist þetta? Þegar þú bætir netþjóni við Kubernetes klasa er greint frá því hversu marga CPU kjarna hann hefur tiltæka. Og þegar þú býrð til nýjan belg veit Kubernetes tímaáætlunin hversu marga kjarna þetta belg þarf. Þannig verður hólfinu úthlutað á netþjón þar sem nóg er af kjarna.
Hvað mun gerast ef ekki beiðni er tilgreind (þ.e. belgurinn hefur ekki skilgreindan fjölda kjarna sem hann þarfnast)? Við skulum reikna út hvernig Kubernetes telur almennt auðlindir.
Fyrir belg geturðu tilgreint bæði beiðnir (CFS tímaáætlun) og mörk (munið þið eftir umferðarljósinu?):
- Ef þeir eru tilgreindir jafnir, þá er belgnum úthlutað QoS flokki tryggingu. Þessi fjöldi kjarna sem er alltaf tiltækur fyrir það er tryggður.
- Ef beiðnin er minni en mörkin - QoS flokkur springanlegur. Þeir. Við gerum ráð fyrir að fræbelgur noti alltaf 1 kjarna, en þetta gildi er ekki takmörkun á því: stundum pod getur notað meira (þegar þjónninn hefur ókeypis úrræði fyrir þetta).
- Það er líka QoS flokkur besta fyrirhöfn — það felur í sér þá belg sem beiðni er ekki tilgreind fyrir. Úrræði eru veitt þeim síðast.
minni
Með minni er ástandið svipað, en aðeins öðruvísi - þegar allt kemur til alls er eðli þessara auðlinda öðruvísi. Almennt séð er líkingin sem hér segir:
Við skulum sjá hvernig beiðnir eru útfærðar í minni. Leyfðu belgunum að lifa á þjóninum, breyta minnisnotkun, þar til einn þeirra verður svo stór að það verður uppiskroppa með minni. Í þessu tilviki birtist OOM morðinginn og drepur stærsta ferlið:
Þetta hentar okkur ekki alltaf og því er hægt að setja reglur um hvaða ferlar eru mikilvægir fyrir okkur og má ekki drepa á. Til að gera þetta, notaðu færibreytuna oom_score_adj.
Snúum okkur aftur að QoS flokkum örgjörvans og drögum líkingu við oom_score_adj gildin sem ákvarða forgangsröðun minnisnotkunar fyrir fræbelg:
- Lægsta oom_score_adj gildi fyrir belg - -998 - þýðir að slíkt belg ætti að drepa síðast, þetta tryggingu.
- Hæsta - 1000 - er besta fyrirhöfn, svona fræbelgir eru drepnir fyrst.
- Til að reikna út gildin sem eftir eru (springanlegur) það er til formúla, sem kjarninn snýst um að því meira úrræði sem fræbelgur hefur beðið um, því minni líkur eru á að hann verði drepinn.
Annað "twist" - takmarka_í_bætum - fyrir takmörk. Með því er allt einfaldara: við úthlutum einfaldlega hámarksmagni útgefnu minnis og hér (ólíkt CPU) er engin spurning um hvernig á að mæla það (minni).
Alls
Hver fræbelgur í Kubernetes er gefinn requests и limits - báðar breytur fyrir CPU og minni:
- byggt á beiðnum, Kubernetes tímaáætlun virkar, sem dreifir belg á netþjóna;
- byggt á öllum breytum, QoS flokkur fræbelgs er ákvarðaður;
- Hlutfallslegt vægi er reiknað út frá CPU beiðnum;
- CFS tímaáætlunin er stillt út frá CPU beiðnum;
- OOM Killer er stillt út frá minnisbeiðnum;
- „umferðarljós“ er stillt út frá CPU takmörkunum;
- Byggt á minnismörkum er takmörk stillt fyrir cgroup.
Almennt séð svarar þessi mynd öllum spurningum um hvernig meginhluti auðlindastjórnunar á sér stað í Kubernetes.
Sjálfvirk stærð
K8s cluster-autoscaler
Við skulum ímynda okkur að allur klasinn sé þegar upptekinn og það þurfi að búa til nýjan belg. Þó að belgurinn geti ekki birst, þá hangir hann í stöðu Bíður. Til að það birtist getum við tengt nýjan netþjón við þyrpinguna eða... sett upp cluster-autoscaler, sem mun gera það fyrir okkur: panta sýndarvél frá skýjaveitunni (með því að nota API beiðni) og tengja hana við þyrpinguna , eftir það verður belgurinn bætt við.
Þetta er sjálfstýring á Kubernetes þyrpingunni, sem virkar frábærlega (að okkar reynslu). Hins vegar, eins og annars staðar, eru nokkur blæbrigði hér ...
Svo lengi sem við stækkuðum klasastærðina var allt í lagi, en hvað gerist þegar klasinn byrjaði að losa sig? Vandamálið er að flutningur á belgjum (til að losa um gestgjafa) er mjög tæknilega erfitt og dýrt miðað við auðlindir. Kubernetes notar allt aðra nálgun.
Íhugaðu þyrping af 3 netþjónum sem eru með dreifingu. Það hefur 6 belg: nú eru 2 fyrir hvern netþjón. Einhverra hluta vegna vildum við slökkva á einum af netþjónunum. Til að gera þetta munum við nota skipunina kubectl drain, sem:
- mun banna að senda nýja belg á þennan netþjón;
- mun eyða núverandi belgjum á þjóninum.
Þar sem Kubernetes ber ábyrgð á að viðhalda fjölda fræbelgja (6), er það einfaldlega mun endurskapa þá á öðrum hnútum, en ekki á þeim sem er óvirkur, þar sem það er þegar merkt sem ófáanlegt til að hýsa nýja belg. Þetta er grundvallar vélvirki fyrir Kubernetes.
Hins vegar er blæbrigði hér líka. Í svipuðum aðstæðum, fyrir StatefulSet (í staðinn fyrir Deployment), verða aðgerðirnar öðruvísi. Núna erum við nú þegar með staðhæft forrit - til dæmis þrjár belg með MongoDB, einn þeirra hefur einhvers konar vandamál (gögnin hafa orðið skemmd eða önnur villa sem kemur í veg fyrir að belgurinn ræsist rétt). Og við ákveðum aftur að slökkva á einum netþjóni. Hvað mun gerast?
MongoDB gæti deyja vegna þess að það þarf ályktun: fyrir þyrping af þremur uppsetningum verða að minnsta kosti tvær að virka. Hins vegar þetta ekki að gerast - þökk sé PodDisruptionBudget. Þessi færibreyta ákvarðar lágmarksfjölda vinnubelgja sem þarf. Að vita að einn af MongoDB belgjunum virkar ekki lengur og sjá að PodDisruptionBudget er stillt á MongoDB minAvailable: 2, Kubernetes mun ekki leyfa þér að eyða belg.
Niðurstaða: til þess að hreyfing (og í raun endurgerð) belgjanna virki rétt þegar þyrpingin er sleppt er nauðsynlegt að stilla PodDisruptionBudget.
Lárétt mælikvarði
Við skulum íhuga aðra stöðu. Það er forrit sem keyrir sem dreifing í Kubernetes. Notendaumferð kemur að belgjum sínum (til dæmis eru þeir þrír) og við mælum ákveðinn vísi í þeim (td CPU álag). Þegar álagið eykst skráum við það á áætlun og fjölgum belgjum til að dreifa beiðnum.
Í dag í Kubernetes þarf ekki að gera þetta handvirkt: sjálfvirk aukning/fækkun á fjölda fræbelgja er stillt eftir gildum mældra álagsvísa.
Helstu spurningarnar hér eru: hvað nákvæmlega á að mæla и hvernig á að túlka fengin gildi (til að taka ákvörðun um að breyta fjölda fræbelgja). Þú getur mælt mikið:
Hvernig á að gera þetta tæknilega - safnaðu mælingum osfrv. — Ég talaði ítarlega í skýrslunni um . Og aðalráðið til að velja ákjósanlegustu breytur er tilraun!
Það er (Nýtingarmettun og villur), merking þess er sem hér segir. Á hvaða grundvelli er skynsamlegt að skala, til dæmis, php-fpm? Miðað við þá staðreynd að starfsmenn eru að klárast, þá er þetta nýting. Og ef starfsmenn eru yfir og nýjar tengingar eru ekki samþykktar, þá er þetta nú þegar mettun. Mæla þarf báðar þessar breytur og eftir gildum þarf að framkvæma mælikvarða.
Í stað þess að niðurstöðu
Skýrslan hefur framhald: um lóðrétta mælikvarða og hvernig á að velja réttu auðlindirnar. Ég mun tala um þetta í framtíðarmyndböndum á - gerast áskrifandi svo þú missir ekki af!
Myndbönd og glærur
Myndband frá sýningunni (44 mínútur):
Kynning á skýrslunni:
PS
Aðrar skýrslur um Kubernetes á blogginu okkar:
- «» (Andrey Polovov; 8. apríl 2019 á Saint HighLoad++);
- «» (Dmitry Stolyarov; 8. nóvember 2018 á HighLoad++);
- «» (Dmitry Stolyarov; 28. maí 2018 á RootConf);
- «» (Dmitry Stolyarov; 7. nóvember 2017 á HighLoad++);
- «» (Dmitry Stolyarov; 6. júní 2017 á RootConf).
Heimild: www.habr.com