27. apríla na konferencii , v rámci sekcie „DevOps“ bola uvedená správa „Automatické škálovanie a správa zdrojov v Kubernetes“. Hovorí o tom, ako môžete použiť K8 na zabezpečenie vysokej dostupnosti vašich aplikácií a zaistenie špičkového výkonu.
Tradične s radosťou predstavujeme (44 minút, oveľa informatívnejšie ako článok) a hlavné zhrnutie v textovej podobe. Choď!
Rozoberme si tému správy slovo po slove a začneme od konca.
Kubernetes
Povedzme, že máme na hostiteľovi kontajnery Docker. Prečo? Na zabezpečenie opakovateľnosti a izolácie, čo zase umožňuje jednoduché a dobré nasadenie, CI/CD. Takýchto vozidiel s kontajnermi máme veľa.
Čo v tomto prípade poskytuje Kubernetes?
- Prestaneme myslieť na tieto stroje a začneme pracovať s „cloudom“ zhluk kontajnerov alebo struky (skupiny nádob).
- Navyše ani nemyslíme na jednotlivé moduly, ale spravujeme viacоväčšie skupiny. Takéto primitívi vysokej úrovne dovoľte nám povedať, že existuje šablóna na spustenie určitej pracovnej záťaže a tu je požadovaný počet inštancií na jej spustenie. Ak následne zmeníme šablónu, zmenia sa všetky inštancie.
- S deklaratívne API Namiesto vykonávania sekvencie konkrétnych príkazov popisujeme „štruktúru sveta“ (v YAML), ktorú vytvára Kubernetes. A opäť: keď sa zmení popis, zmení sa aj jeho skutočné zobrazenie.
Riadenie zdrojov
CPU
Spustite na serveri nginx, php-fpm a mysql. Tieto služby budú mať v skutočnosti spustených ešte viac procesov, z ktorých každý vyžaduje výpočtové zdroje:
(čísla na snímke sú „papagáje“, abstraktná potreba výpočtového výkonu každého procesu)
Aby sa s tým ľahšie pracovalo, je logické spájať procesy do skupín (napríklad všetky procesy nginx do jednej skupiny „nginx“). Jednoduchý a zrejmý spôsob, ako to urobiť, je vložiť každú skupinu do kontajnera:
Ak chcete pokračovať, musíte si pamätať, čo je kontajner (v systéme Linux). Ich vzhľad bol možný vďaka trom kľúčovým funkciám v jadre, ktoré boli implementované už pomerne dávno: , и . A ďalší vývoj uľahčili ďalšie technológie (vrátane pohodlných „škrupín“, ako je Docker):
V kontexte správy nás zaujíma iba to skupiny, pretože riadiace skupiny sú súčasťou funkcionality kontajnerov (Docker atď.), ktorá implementuje správu zdrojov. Procesy spojené do skupín, ako sme chceli, sú kontrolné skupiny.
Vráťme sa k požiadavkám na CPU pre tieto procesy a teraz pre skupiny procesov:
(Opakujem, že všetky čísla sú abstraktným vyjadrením potreby zdrojov)
Samotný CPU má zároveň určitý obmedzený zdroj (v tomto príklade je to 1000), ktorá môže každému chýbať (súčet potrieb všetkých skupín je 150+850+460=1460). Čo sa stane v tomto prípade?
Jadro začne distribuovať zdroje a robí to „spravodlivo“, pričom každej skupine dáva rovnaké množstvo zdrojov. Ale v prvom prípade je ich viac, ako je potrebné (333>150), takže prebytok (333-150=183) zostáva v rezerve, ktorý je tiež rovnomerne rozdelený medzi dva ďalšie kontajnery:
Výsledkom bolo, že prvý kontajner mal dostatok zdrojov, druhý – nemal dostatok zdrojov, tretí – nemal dostatok zdrojov. Toto je výsledok akcií "poctivý" plánovač v Linuxe - . Jeho činnosť je možné upraviť pomocou priradenia závažia každý z kontajnerov. Napríklad takto:
Pozrime sa na prípad nedostatku zdrojov v druhom kontajneri (php-fpm). Všetky prostriedky kontajnera sú rovnomerne rozdelené medzi procesy. Výsledkom je, že hlavný proces funguje dobre, ale všetci pracovníci sa spomaľujú a dostávajú menej ako polovicu toho, čo potrebujú:
Takto funguje plánovač CFS. Váhy, ktoré kontajnerom priradíme, budeme ďalej nazývať žiadosti. Prečo je to tak - pozri ďalej.
Pozrime sa na celú situáciu z druhej strany. Ako viete, všetky cesty vedú do Ríma a v prípade počítača do CPU. Jeden procesor, veľa úloh - potrebujete semafor. Najjednoduchší spôsob, ako spravovať zdroje, je „semafor“: dali jednému procesu pevný čas prístupu k CPU, potom ďalšiemu atď.
Tento prístup sa nazýva tvrdé kvóty (tvrdé obmedzenie). Zapamätajme si to jednoducho ako limity. Ak však rozdelíte limity na všetky kontajnery, nastáva problém: mysql jazdil po ceste a v určitom bode jeho potreba CPU skončila, ale všetky ostatné procesy sú nútené čakať, kým CPU nečinný.
Vráťme sa k linuxovému jadru a jeho interakcii s CPU – celkový obraz je nasledovný:
cgroup má dve nastavenia – v podstate ide o dve jednoduché „zákruty“, ktoré vám umožňujú určiť:
- hmotnosť pre kontajner (požiadavky) je akcie;
- percento celkového času CPU na prácu na úlohách kontajnera (limity) je kvóta.
Ako merať CPU?
Existujú rôzne spôsoby:
- Čo je papagáje, nikto nevie - zakaždým treba zjednávať.
- záujem jasnejšie, ale relatívne: 50 % servera so 4 jadrami a s 20 jadrami sú úplne iné veci.
- Môžete použiť už spomínané závažia, ktoré Linux pozná, no sú aj relatívne.
- Najvhodnejšou možnosťou je meranie výpočtových zdrojov v sekúnd. Tie. v sekundách procesorového času vo vzťahu k sekundám reálneho času: 1 sekunda procesorového času bola udaná za 1 skutočnú sekundu – to je jedno celé jadro CPU.
Aby bolo rozprávanie ešte jednoduchšie, začali merať priamo v jadier, čo znamená rovnaký čas CPU vzhľadom na skutočný. Keďže Linux rozumie váham, ale nie toľko času CPU/jadrám, bol potrebný mechanizmus na preklad z jedného do druhého.
Uvažujme jednoduchý príklad so serverom s 3 jadrami CPU, kde trom modulom budú priradené váhy (500, 1000 1500 a 0,5 1), ktoré sa ľahko prevedú na zodpovedajúce časti jadier, ktoré im boli pridelené (1,5, XNUMX a XNUMX).
Ak vezmete druhý server, kde bude dvakrát toľko jadier (6), a umiestnite tam rovnaké moduly, rozdelenie jadier sa dá ľahko vypočítať jednoduchým vynásobením 2 (1, 2 a 3). Dôležitý moment však nastáva, keď sa na tomto serveri objaví štvrtý modul, ktorého hmotnosť bude pre pohodlie 3000. Odoberie časť zdrojov CPU (polovicu jadier) a pre zostávajúce moduly sa prepočítajú (na polovicu):
Kubernetes a zdroje CPU
V Kubernetes sa zdroje CPU zvyčajne merajú miliadrax, t.j. Ako základná hmotnosť sa berie 0,001 jadra. (To isté sa v terminológii Linux/cgroups nazýva zdieľanie CPU, aj keď presnejšie 1000 milicores = 1024 zdieľaní CPU.) K8s zaisťuje, že na server neumiestňuje viac modulov, ako je zdrojov CPU pre súčet váh všetkých modulov.
Ako sa to stane? Keď pridáte server do klastra Kubernetes, ohlási sa, koľko jadier CPU má k dispozícii. A pri vytváraní nového modulu plánovač Kubernetes vie, koľko jadier bude tento modul potrebovať. Pod bude teda priradený k serveru, kde je dostatok jadier.
Čo sa stane ak nie je zadaná požiadavka (t. j. modul nemá definovaný počet jadier, ktoré potrebuje)? Poďme zistiť, ako Kubernetes vo všeobecnosti počíta zdroje.
Pre modul môžete zadať požiadavky (plánovač CFS) aj limity (pamätáte si na semafor?):
- Ak sú špecifikované ako rovnaké, pod je priradená trieda QoS zaručená. Tento počet jadier, ktoré má vždy k dispozícii, je zaručený.
- Ak je požiadavka menšia ako limit - trieda QoS prasknuteľný. Tie. Očakávame, že napríklad pod bude vždy používať 1 jadro, ale táto hodnota nie je preň obmedzením: niekedy pod môže použiť viac (ak má server na to voľné zdroje).
- Existuje aj trieda QoS maximálne úsilie — zahŕňa práve tie struky, pre ktoré nie je špecifikovaná požiadavka. Zdroje sa im dávajú ako posledné.
pamäť
S pamäťou je situácia podobná, ale mierne odlišná – napokon, povaha týchto zdrojov je iná. Vo všeobecnosti je analógia nasledovná:
Pozrime sa, ako sú požiadavky implementované v pamäti. Nechajte moduly žiť na serveri a zmeňte spotrebu pamäte, kým sa jeden z nich nezväčší natoľko, že mu dôjde pamäť. V tomto prípade sa objaví zabijak OOM a zabije najväčší proces:
Nie vždy nám to vyhovuje, preto sa dá regulovať, ktoré procesy sú pre nás dôležité a netreba ich zabíjať. Ak to chcete urobiť, použite parameter oom_score_adj.
Vráťme sa k triedam QoS CPU a nakreslite analógiu s hodnotami oom_score_adj, ktoré určujú priority spotreby pamäte pre moduly:
- Najnižšia hodnota oom_score_adj pre modul - -998 - znamená, že takýto modul by mal byť zabitý ako posledný. zaručená.
- Najvyššia - 1000 - je maximálne úsilie, takéto struky sa zabijú ako prvé.
- Na výpočet zostávajúcich hodnôt (prasknuteľný) existuje vzorec, ktorého podstata spočíva v tom, že čím viac zdrojov si lusk vyžiada, tým menšia je pravdepodobnosť, že bude zabitý.
Druhý "zákrut" - limit_in_bytes - pre limity. S ním je všetko jednoduchšie: jednoducho priradíme maximálne množstvo vydanej pamäte a tu (na rozdiel od CPU) nie je otázka, ako ju merať (pamäť).
Celkom
Každý modul v Kubernetes je daný requests и limits - oba parametre pre CPU aj pamäť:
- na základe požiadaviek funguje plánovač Kubernetes, ktorý distribuuje moduly medzi servery;
- na základe všetkých parametrov sa určí trieda QoS modulu;
- Relatívne váhy sa vypočítavajú na základe požiadaviek CPU;
- plánovač CFS je nakonfigurovaný na základe požiadaviek CPU;
- OOM zabijak je nakonfigurovaný na základe požiadaviek na pamäť;
- „semafor“ je nakonfigurovaný na základe limitov CPU;
- Na základe limitov pamäte je pre cgroup nakonfigurovaný limit.
Vo všeobecnosti tento obrázok odpovedá na všetky otázky o tom, ako prebieha hlavná časť správy zdrojov v Kubernetes.
Automatické škálovanie
Klastrový automatický scaler K8s
Predstavme si, že celý klaster je už obsadený a je potrebné vytvoriť nový modul. Zatiaľ čo modul sa nemôže zobraziť, visí v stave Až do. Aby sa objavil, môžeme do klastra pripojiť nový server alebo... nainštalovať cluster-autoscaler, ktorý to urobí za nás: objednajte si virtuálny stroj od poskytovateľa cloudu (pomocou API požiadavky) a pripojte ho ku klastru , po ktorom sa pridá lusk .
Ide o autoscaling klastra Kubernetes, ktorý funguje výborne (podľa našich skúseností). Avšak, ako inde, aj tu existujú určité nuansy...
Pokiaľ sme zväčšili veľkosť klastra, všetko bolo v poriadku, ale čo sa stane, keď sa klaster stane sa začal oslobodzovať? Problém je v tom, že migrácia modulov (na uvoľnenie hostiteľov) je veľmi technicky náročná a nákladná z hľadiska zdrojov. Kubernetes používa úplne iný prístup.
Zvážte klaster 3 serverov, ktorý má nasadenie. Má 6 modulov: teraz sú 2 pre každý server. Z nejakého dôvodu sme chceli vypnúť jeden zo serverov. Na to použijeme príkaz kubectl drain, ktorý:
- zakáže odosielanie nových modulov na tento server;
- odstráni existujúce moduly na serveri.
Keďže Kubernetes je zodpovedný za udržiavanie počtu modulov (6), je to jednoduché znovu vytvorí na iných uzloch, ale nie na deaktivovanom, pretože je už označený ako nedostupný pre hosťovanie nových modulov. Toto je základná mechanika pre Kubernetes.
Je tu však aj nuansa. V podobnej situácii pre StatefulSet (namiesto Deployment) budú akcie odlišné. Teraz už máme stavovú aplikáciu – napríklad tri moduly s MongoDB, z ktorých jeden má nejaký problém (údaje sú poškodené alebo iná chyba, ktorá bráni správnemu spusteniu modulu). A opäť sa rozhodneme vypnúť jeden server. Čo sa bude diať?
MongoDB mohol zomrie, pretože potrebuje kvórum: pre skupinu troch inštalácií musia fungovať aspoň dve. Avšak, toto nedeje sa - vďaka PodDisruptionBudget. Tento parameter určuje minimálny požadovaný počet pracovných modulov. Vedieť, že jeden z modulov MongoDB už nefunguje, a vidieť, že PodDisruptionBudget je nastavený pre MongoDB minAvailable: 2, Kubernetes vám nedovolí odstrániť pod.
Zrátané a podčiarknuté: aby pohyb (a vlastne aj opätovné vytváranie) podov po uvoľnení klastra fungoval správne, je potrebné nakonfigurovať PodDisruptionBudget.
Horizontálne škálovanie
Uvažujme o inej situácii. V Kubernetes je spustená aplikácia ako Deployment. Návštevnosť používateľov prichádza do jeho podov (napríklad sú tri) a meriame v nich určitý ukazovateľ (povedzme zaťaženie procesora). Keď sa zaťaženie zvýši, zaznamenáme to podľa plánu a zvýšime počet modulov na distribúciu požiadaviek.
Dnes to v Kubernetes nie je potrebné robiť ručne: automatické zvýšenie/zníženie počtu modulov sa konfiguruje v závislosti od hodnôt nameraných indikátorov zaťaženia.
Hlavné otázky sú tu: čo presne merať и ako interpretovať získané hodnoty (na rozhodnutie o zmene počtu strukov). Môžete merať veľa:
Ako to urobiť technicky - zbierať metriky atď. — Podrobne som hovoril v správe o . A hlavnou radou pre výber optimálnych parametrov je experimentovať!
K dispozícii je (Sýtosť využitia a chyby), ktorého význam je nasledovný. Na základe čoho má zmysel škálovať napríklad php-fpm? Na základe skutočnosti, že pracovníci dochádzajú, je to tak využitia. A ak robotníci skončili a nové spojenia nie sú akceptované, už je to tak nasýtenia. Oba tieto parametre sa musia merať a v závislosti od hodnôt sa musí vykonať mierka.
namiesto záveru
Správa má pokračovanie: o vertikálnom škálovaní a o tom, ako vybrať správne zdroje. Budem o tom hovoriť v budúcich videách - prihláste sa, aby ste nič nezmeškali!
Videá a diapozitívy
Video z predstavenia (44 minút):
Prezentácia správy:
PS
Ďalšie správy o Kubernetes na našom blogu:
- «» (Andrey Polovov; 8. apríla 2019 na Saint HighLoad++);
- «» (Dmitrij Stolyarov; 8. novembra 2018 na HighLoad++);
- «» (Dmitrij Stolyarov; 28. mája 2018 na RootConf);
- «» (Dmitrij Stolyarov; 7. novembra 2017 na HighLoad++);
- «» (Dmitrij Stolyarov; 6. júna 2017 na RootConf).
Zdroj: hab.com