Automatinis mastelio keitimas ir išteklių valdymas „Kubernetes“ (apžvalga ir vaizdo įrašų ataskaita)

Konferencijoje balandžio 27 d Streikas 2019 m, kaip „DevOps“ skyriaus dalis, buvo pateikta ataskaita „Automatinis mastelio keitimas ir išteklių valdymas Kubernetes“. Jame kalbama apie tai, kaip galite naudoti K8, kad užtikrintumėte aukštą programų prieinamumą ir didžiausią našumą.

Pagal tradiciją mums malonu pristatyti reportažo vaizdo įrašas (44 min., daug informatyvesnis nei straipsnis) ir pagrindinė santrauka tekstiniu pavidalu. Pirmyn!

Išanalizuokime pranešimo temą žodis po žodžio ir pradėkime nuo pabaigos.

Kubernetes

Tarkime, kad mūsų priegloboje yra „Docker“ konteineriai. Kam? Siekiant užtikrinti pakartojamumą ir izoliaciją, o tai savo ruožtu leidžia lengvai ir gerai įdiegti, CI/CD. Turime daug tokių transporto priemonių su konteineriais.

Ką šiuo atveju suteikia Kubernetes?

1. Nustojame galvoti apie šias mašinas ir pradedame dirbti su „debesimi“ konteinerių klasteris arba ankštys (talpyklų grupės).
2. Be to, mes net negalvojame apie atskiras ankštis, o valdome daugiauоdidesnės grupės. Toks aukšto lygio primityvai Leiskite mums pasakyti, kad yra šablonas, skirtas tam tikram darbo krūviui paleisti, ir čia yra reikiamas egzempliorių skaičius jam paleisti. Jei vėliau pakeisime šabloną, pasikeis visi atvejai.
3. naudojant deklaratyvioji API Užuot vykdydami konkrečių komandų seką, aprašome „pasaulio struktūrą“ (YAML), kurią sukūrė Kubernetes. Ir vėl: pasikeitus aprašymui, pasikeis ir jo tikrasis rodymas.

Resursu valdymas

CPU

Serveryje paleiskite nginx, php-fpm ir mysql. Šios paslaugos iš tikrųjų veiks dar daugiau procesų, kurių kiekvienam reikia skaičiavimo išteklių:

(skaičiai skaidrėje yra „papūga“, abstraktus kiekvieno proceso poreikis skaičiuoti galią)

Kad būtų lengviau dirbti su tuo, logiška procesus sujungti į grupes (pavyzdžiui, visus nginx procesus į vieną grupę „nginx“). Paprastas ir akivaizdus būdas tai padaryti yra sudėti kiekvieną grupę į konteinerį:

Norėdami tęsti, turite atsiminti, kas yra konteineris (Linux). Jų atsiradimas buvo įmanomas dėl trijų pagrindinių branduolio funkcijų, įdiegtų gana seniai: galimybes, vardų erdvės и grupės. Ir tolesnę plėtrą palengvino kitos technologijos (įskaitant patogius „apvalkalus“, tokius kaip Docker):

Ataskaitos kontekste mus domina tik grupės, nes valdymo grupės yra konteinerių (Docker ir kt.) funkcionalumo dalis, įgyvendinanti išteklių valdymą. Procesai, sujungti į grupes, kaip norėjome, yra kontrolinės grupės.

Grįžkime prie CPU reikalavimų šiems procesams, o dabar – procesų grupėms:

(Kartoju, kad visi skaičiai yra abstrakti išteklių poreikio išraiška)

Tuo pačiu metu pats centrinis procesorius turi tam tikrus ribotus išteklius (pavyzdyje tai yra 1000), kurio gali pritrūkti kiekvienam (visų grupių poreikių suma 150+850+460=1460). Kas bus šiuo atveju?

Branduolys pradeda paskirstyti išteklius ir daro tai „sąžiningai“, kiekvienai grupei suteikdamas tą patį išteklių kiekį. Bet pirmuoju atveju jų yra daugiau nei reikia (333>150), todėl perteklius (333-150=183) lieka rezerve, kuris taip pat tolygiai paskirstomas tarp dviejų kitų konteinerių:

Rezultatas: pirmas konteineris turėjo pakankamai resursų, antrasis - neturėjo pakankamai resursų, trečiasis - neturėjo pakankamai resursų. Tai yra veiksmų rezultatas „sąžiningas“ planuotojas sistemoje „Linux“. - CFS. Jo veikimą galima koreguoti naudojant užduotį svoris kiekvienas iš konteinerių. Pavyzdžiui, taip:

Pažiūrėkime į resursų trūkumo atvejį antrame konteineryje (php-fpm). Visi konteinerių ištekliai paskirstomi vienodai tarp procesų. Dėl to pagrindinis procesas veikia gerai, tačiau visi darbuotojai sulėtėja ir gauna mažiau nei pusę to, ko jiems reikia:

Taip veikia CFS planuoklis. Toliau vadinsime svorius, kuriuos priskiriame konteineriams prašymus. Kodėl taip yra – žiūrėkite toliau.

Pažvelkime į visą situaciją iš kitos pusės. Kaip žinia, visi keliai veda į Romą, o kompiuterio atveju – į centrinį procesorių. Vienas CPU, daug užduočių – reikia šviesoforo. Paprasčiausias būdas valdyti išteklius yra „šviesoforas“: vienam procesui buvo suteiktas fiksuotas prieigos prie procesoriaus laikas, tada kitam ir pan.

Šis metodas vadinamas griežtosiomis kvotomis (kietas ribojimas). Prisiminkime tai tiesiog kaip ribas. Tačiau jei paskirstysite limitus visiems konteineriams, iškyla problema: mysql važiavo keliu ir kažkuriuo momentu jo procesoriaus poreikis baigėsi, bet visi kiti procesai yra priversti laukti, kol procesorius tuščiąja eiga.

Grįžkime prie Linux branduolio ir jo sąveikos su CPU – bendras vaizdas toks:

cgroup turi du nustatymus – iš esmės tai yra du paprasti „posūkiai“, leidžiantys nustatyti:

1. konteinerio svoris (užklausos) yra akcijos;
2. procentas viso CPU laiko, skirto dirbti su konteinerio užduotimis (ribos). kvota.

Kaip išmatuoti procesorių?

Yra įvairių būdų:

1. ką papūgos, niekas nežino – derėtis reikia kiekvieną kartą.
2. Palūkanos aiškesnis, bet santykinis: 50% serverio su 4 branduoliais ir su 20 branduolių yra visiškai skirtingi dalykai.
3. Galite naudoti jau minėtus svoris, kuriuos Linux žino, bet jie taip pat yra santykiniai.
4. Tinkamiausias pasirinkimas yra išmatuoti skaičiavimo išteklius sekundžių. Tie. procesoriaus laiko sekundėmis, palyginti su realaus laiko sekundėmis: 1 sekundė procesoriaus laiko buvo suteikta per 1 realią sekundę - tai yra vienas visas procesoriaus branduolys.

Kad būtų dar lengviau kalbėti, jie pradėjo matuotis tiesiai branduoliai, tai reiškia tą patį procesoriaus laiką, palyginti su tikruoju. Kadangi „Linux“ supranta svorius, bet ne tiek daug procesoriaus laiko / branduolių, reikėjo mechanizmo, kuris išverstų iš vieno į kitą.

Panagrinėkime paprastą pavyzdį su serveriu su 3 procesoriaus branduoliais, kur trims podams bus suteikti svoriai (500, 1000 ir 1500), kurie lengvai konvertuojami į atitinkamas jiems paskirtas branduolių dalis (0,5, 1 ir 1,5).

Jei imsite antrą serverį, kuriame bus dvigubai daugiau branduolių (6), ir ten patalpinsite tuos pačius blokus, branduolių pasiskirstymą galima nesunkiai apskaičiuoti tiesiog padauginus iš 2 (atitinkamai 1, 2 ir 3). Tačiau svarbus momentas įvyksta, kai šiame serveryje atsiranda ketvirtas podas, kurio svoris patogumo dėlei bus 3000. Tai atima dalį procesoriaus resursų (pusę branduolių), o likusiems podams jie perskaičiuojami (perpusinami):

Kubernetes ir procesoriaus ištekliai

„Kubernetes“ procesoriaus ištekliai paprastai matuojami miliadraksas, t.y. Baziniu svoriu imamas 0,001 šerdies. (Tas pats dalykas Linux/cgroups terminologijoje vadinamas procesoriaus dalimi, nors, tiksliau, 1000 milicores = 1024 procesoriaus dalys.) K8s užtikrina, kad į serverį nepadės daugiau blokų, nei yra procesoriaus resursų susumavus visų podų svorius.

Kaip tai atsitinka? Kai pridedate serverį prie Kubernetes klasterio, pranešama, kiek jame yra procesoriaus branduolių. Ir kurdamas naują podą, Kubernetes planuotojas žino, kiek branduolių reikės šiam podeliui. Taigi, podas bus priskirtas serveriui, kuriame yra pakankamai branduolių.

Kas bus, jei ne nurodyta užklausa (t. y. podyje nėra nustatyto branduolių skaičiaus, kurio jam reikia)? Išsiaiškinkime, kaip „Kubernetes“ paprastai skaičiuoja išteklius.

Podui galite nurodyti ir užklausas (CFS planuoklį), ir ribas (pamenate šviesoforą?):

• Jei jie nurodyti lygūs, tada podui priskiriama QoS klasė garantuojama. Šis visada prieinamas branduolių skaičius yra garantuotas.
• Jei užklausa mažesnė už limitą – QoS klasė sprogstamasis. Tie. Mes tikimės, kad, pavyzdžiui, blokas visada naudos 1 branduolį, tačiau ši vertė nėra jo apribojimas: kartais pod gali naudoti daugiau (kai serveris tam turi laisvų išteklių).
• Taip pat yra QoS klasė geriausios pastangos — tai apima tas ankštis, dėl kurių prašymas nenurodytas. Ištekliai jiems suteikiami paskutiniai.

atmintis

Su atmintimi situacija panaši, bet šiek tiek kitokia – juk skiriasi šių išteklių prigimtis. Apskritai analogija yra tokia:

Pažiūrėkime, kaip užklausos įgyvendinamos atmintyje. Leiskite podiams gyventi serveryje, keisdami atminties suvartojimą, kol vienas iš jų pasidarys toks didelis, kad pritrūks atminties. Tokiu atveju pasirodo OOM žudikas ir užmuša didžiausią procesą:

Tai ne visada mums tinka, todėl galima reguliuoti, kurie procesai mums svarbūs ir neturėtų būti žudomi. Norėdami tai padaryti, naudokite parametrą oom_score_adj.

Grįžkime prie procesoriaus QoS klasių ir nubrėžkime analogiją su oom_score_adj reikšmėmis, kurios nustato atminties sunaudojimo prioritetus podams:

• Mažiausia rinkinio oom_score_adj reikšmė – –998 – reiškia, kad tokia grupė turi būti nužudyta paskutinė. garantuojama.
• Aukščiausia – 1000 – yra geriausios pastangos, tokios ankštys žudomos pirmiausia.
• Norėdami apskaičiuoti likusias reikšmes (sprogstamasis) yra formulė, kurios esmė susiveda į tai, kad kuo daugiau išteklių prašė ankštis, tuo mažesnė tikimybė, kad ji bus nužudyta.

Antrasis „posūkis“ - limit_in_bytes - už ribas. Su juo viskas paprasčiau: tiesiog priskiriame maksimalų išduodamos atminties kiekį, o čia (skirtingai nei CPU) nekyla klausimas, kaip ją išmatuoti (atmintį).

Iš viso

Kiekviena „Kubernetes“ anga yra pateikta requests и limits - abu procesoriaus ir atminties parametrai:

1. pagal užklausas veikia Kubernetes planavimo priemonė, kuri paskirsto paketus tarp serverių;
2. pagal visus parametrus nustatoma podelio QoS klasė;
3. Santykiniai svoriai apskaičiuojami pagal CPU užklausas;
4. CFS planuoklis sukonfigūruojamas pagal CPU užklausas;
5. OOM killer sukonfigūruotas pagal atminties užklausas;
6. „šviesoforas“ sukonfigūruotas pagal procesoriaus ribas;
7. Remiantis atminties apribojimais, cgroup yra sukonfigūruotas limitas.

Apskritai šis paveikslėlis atsako į visus klausimus apie tai, kaip pagrindinė išteklių valdymo dalis vyksta Kubernetes.

Automatinis mastelio keitimas

K8s klasteris-automatinis skaleris

Įsivaizduokime, kad visas klasteris jau užimtas ir reikia sukurti naują podą. Nors ankštis negali pasirodyti, ji kabo Kol. Kad jis atsirastų, galime prie klasterio prijungti naują serverį arba... įdiegti cluster-autoscaler, kuris tai padarys už mus: užsakyti virtualią mašiną iš debesies tiekėjo (naudojant API užklausą) ir prijungti ją prie klasterio. , po kurio ankštis bus pridėta .

Tai yra „Kubernetes“ klasterio automatinis mastelio keitimas, kuris puikiai veikia (mūsų patirtimi). Tačiau, kaip ir kitur, čia yra keletas niuansų...

Kol padidinome klasterio dydį, viskas buvo gerai, bet kas atsitiks, kai klasteris pradėjo laisvėti? Problema ta, kad podų perkėlimas (atlaisvinti pagrindinius kompiuterius) yra labai techniškai sudėtingas ir brangus išteklių požiūriu. Kubernetes taiko visiškai kitokį požiūrį.

Apsvarstykite 3 serverių grupę, kurioje yra diegimas. Jame yra 6 blokai: dabar kiekvienam serveriui yra po 2. Kažkodėl norėjome išjungti vieną iš serverių. Norėdami tai padaryti, naudosime komandą kubectl drain, kuris:

• uždraus siųsti naujus rinkinius į šį serverį;
• ištrins esamas talpyklas serveryje.

Kadangi Kubernetes yra atsakingas už ankščių skaičiaus palaikymą (6), tai tiesiog atkurs juos kituose mazguose, bet ne tame, kuris išjungtas, nes jis jau pažymėtas kaip nepasiekiamas naujiems blokams priglobti. Tai pagrindinė Kubernetes mechanika.

Tačiau čia taip pat yra niuansas. Panašioje situacijoje „StatefulSet“ (o ne „Deployment“) veiksmai bus skirtingi. Dabar mes jau turime būseną nustatančią programą - pavyzdžiui, tris blokus su MongoDB, iš kurių viena turi kažkokią problemą (duomenys sugadinti arba kita klaida, neleidžianti podui tinkamai paleisti). Ir vėl nusprendžiame išjungti vieną serverį. Kas nutiks?

MongoDB galėtų miršta, nes jai reikia kvorumo: trijų įrenginių grupėje turi veikti bent du. Tačiau šis nevyksta - ačiū PodDisruptionBudget. Šis parametras nustato minimalų reikalingą darbinių ankščių skaičių. Žinodami, kad vienas iš „MongoDB“ rinkinių nebeveikia, ir matydami, kad „PodDisruptionBudget“ nustatytas „MongoDB“ minAvailable: 2, „Kubernetes“ neleis ištrinti rinkinio.

Apatinė eilutė: norint, kad blokų judėjimas (ir iš tikrųjų – iš naujo) veiktų tinkamai, kai klasteris išleidžiamas, būtina sukonfigūruoti PodDisruptionBudget.

Horizontalus mastelio keitimas

Panagrinėkime kitą situaciją. „Kubernetes“ yra programa, kuri veikia kaip diegimas. Vartotojų srautas ateina į jo podelius (pavyzdžiui, jų yra trys), juose matuojame tam tikrą rodiklį (tarkim, procesoriaus apkrovą). Kai apkrova didėja, mes įrašome jį į grafiką ir padidiname podų skaičių, kad paskirstytume užklausas.

Šiandien „Kubernetes“ to nereikia daryti rankiniu būdu: automatinis ankščių skaičiaus padidinimas / sumažinimas sukonfigūruojamas atsižvelgiant į išmatuotų apkrovos rodiklių vertes.

Pagrindiniai klausimai čia yra: ką tiksliai matuoti и kaip interpretuoti gautos vertės (sprendimui dėl ankščių skaičiaus keitimo priimti). Galite išmatuoti daug:

Kaip tai padaryti techniškai – rinkti metrikas ir pan. — Apie tai pranešime išsamiai kalbėjau Stebėjimas ir Kubernetes. O pagrindinis patarimas renkantis optimalius parametrus yra eksperimentas!

Yra NAUDOTI metodą (Naudojimo prisotinimas ir klaidos), kurio reikšmė tokia. Kokiu pagrindu prasminga keisti mastelį, pavyzdžiui, php-fpm? Remiantis tuo, kad darbuotojų senka, tai yra panaudojimas. Ir jei darbuotojai baigėsi ir nauji ryšiai nepriimami, tai jau yra sotis. Abu šie parametrai turi būti išmatuoti ir, atsižvelgiant į vertes, turi būti atliktas mastelio keitimas.

Vietoj išvados

Ataskaitoje yra tęsinys: apie vertikalųjį mastelį ir kaip pasirinkti tinkamus išteklius. Apie tai kalbėsiu būsimuose vaizdo įrašuose mūsų „YouTube“. - Prenumeruokite, kad nepraleistumėte!

Vaizdo įrašai ir skaidrės

Vaizdo įrašas iš spektaklio (44 min.):

Pranešimo pristatymas:

PS

Kiti pranešimai apie Kubernetes mūsų tinklaraštyje:

• «„Kubernetes“ išplėtimas ir papildymas» (Andrejus Polovas; 8 m. balandžio 2019 d. per „Saint HighLoad++“);
• «Duomenų bazės ir Kubernetes» (Dmitrijus Stoliarovas; 8 m. lapkričio 2018 d. „HighLoad++“);
• «Stebėjimas ir Kubernetes» (Dmitrijus Stoliarovas; 28 m. gegužės 2018 d., RootConf);
• «CI / CD geriausia praktika naudojant „Kubernetes“ ir „GitLab“.» (Dmitrijus Stoliarovas; 7 m. lapkričio 2017 d. „HighLoad++“);
• «Mūsų patirtis su Kubernetes mažuose projektuose» (Dmitrijus Stolyarovas; 6 m. birželio 2017 d. RootConf).

Šaltinis: www.habr.com