Vytvoril som Kube Eagle — exportér Prometheus. Ukázalo sa, že to je skvelý nástroj, ktorý pomáha lepšie sa zorientovať v zdrojoch malých a stredných klastrov. V konečnom dôsledku som ušetril nie jednu stovku dolárov, pretože som vyberal správne typy strojov a nastavoval obmedzenia zdrojov aplikácií podľa pracovných záťaží.
Povediem vás k výhodám , ale najprv vysvetlím, čo spôsobilo neporozumenie a na čo bol potrebný kvalitný monitoring.
Spravoval som niekoľko klastrov so 4–50 uzlami. V každom klastri bolo až 200 mikroslužieb a aplikácií. Aby som účinnejšie využil dostupný hardvér, väčšina nasadení bola nastavená so burstable operačnou pamäťou a CPU zdrojmi. Tak podové kontajnery môžu využiť dostupné zdroje, ak to potrebujú, a pri tom neobmedzujú ostatné aplikácie na tomto uzle. No nie je to skvelé?
A hoci klaster spotreboval relatívne málo CPU (8%) a pamäte (40%), neustále sme sa stretávali s problémami pri vytláčaní podov, keď sa snažili získať viac pamäte, než bolo dostupné na uzle. Vtedy sme mali len jediné rozhranie pre monitoring zdrojov Kubernetes. Takéto:
Grafana panel iba s metrikami cAdvisor
S takýmto panelom je vidieť uzly, ktoré spotrebúvajú veľa pamäte a CPU, bez problémov. Problém je pochopiť, v čom je príčina. Aby podové kontajnery zostali na mieste, bolo by možné samozrejme nastaviť garantované zdroje na všetkých podoch (požadované zdroje sú rovné limitu). Ale to nie je najrozumnejšie využitie hardvéru. V klastere bolo niekoľko stoviek gigabajtov pamäte, pričom niektoré uzly hladovali, a iné mali v rezervách po 4–10 GB.
Vychádza to tak, že Kubernetes plánovač rozdeľoval pracovné záťaže po dostupných zdrojoch nerovnomerne. Kubernetes plánovač berie do úvahy rôzne konfigurácie: pravidlá affinity, taint a tolerancie, selektory uzlov, ktoré môžu obmedziť dostupné uzly. Ale v mojom prípade nič také neexistovalo, a podové kontajnery sa plánovali na základe požadovaných zdrojov na každom uzle.
Pre podový kontajner sa vybrala uzol s najviac voľnými zdrojmi a ktorý spĺňal podmienky požiadavky. Ukázalo sa, že požadované zdroje na uzloch sa nezhodovali so skutočným využitím, a tu prišiel na pomoc Kube Eagle a jeho možnosti monitorovania zdrojov.
Takmer všetky moje Kubernetes klastre boli sledované iba pomocou a . Node Exporter poskytuje štatistiky o vstupe a výstupe, využití disku, CPU a pamäte, zatiaľ čo Kube State Metrics ukazuje metriky objektov Kubernetes, ako napríklad požiadavky a limity na zdroje CPU a pamäť.
Musíme skombinovať metriky o využití so metrikami požiadaviek a limitov v Grafane, čím získame všetky informácie o probléme. Znie to jednoducho, ale v týchto dvoch nástrojoch sú označenia nazvané rôzne a niektoré metriky nemajú vôbec žiadne metadátové označenia. Kube Eagle to robí všetko automaticky a panel vyzerá takto:
Podarilo sa nám vyriešiť veľa problémov so zdrojmi a ušetriť vybavenie:
- Niektorí vývojári nevedeli, koľko zdrojov potrebujú mikroslužby (alebo sa jednoducho nezamýšľali). Nemali sme nástroje na identifikáciu nesprávnych požiadaviek na zdroje - na to je potrebné poznať spotrebu plus požiadavky a limity. Teraz vidia metriky Prometheus, sledujú skutočné využitie a prispôsobujú požiadavky a limity.
- JVM aplikácie zaberajú toľko pamäte, koľko môžu. Zberateľ odpadu uvoľňuje pamäť iba vtedy, ak je využité viac ako 75%. A keďže väčšina služieb má pamäť s burstable vlastnosťami, JVM ju vždy zaberal. Preto tieto Java služby spotrebovávali oveľa viac operatívnej pamäte, než sa očakávalo.
- Niektoré aplikácie požadovali príliš veľa pamäte, a plánovač Kubernetes nedovolil týmto uzlom priradiť ostatné aplikácie, hoci v skutočnosti boli voľnejšie ako iné uzly. Jeden vývojár náhodou pridal nadbytočnú číslicu v požiadavke a zabral veľký kus pamäte: 20 GB namiesto 2. Nikto si to nevšimol. Aplikácia mala 3 repliky, takže trpeli aj 3 uzly.
- Zaviedli sme obmedzenia na zdroje, preplánovali pod a získali ideálny balans využitia hardvéru na všetkých uzloch. Niektoré uzly sme vôbec mohli uzavrieť. A potom sme zistili, že máme nesprávne mašiny (orientované na CPU, a nie na pamäť). Zmenili sme typ a odstránili ďalšie niekoľko uzlov.
Zhrnutie
S burstable zdrojmi v klastri efektívnejšie využívate existujúci hardvér, avšak plánovač Kubernetes plánuje pod podľa požiadaviek na zdroje, čo môže byť problematické. Aby sme sa vyhli problémom a využili zdroje naplno, potrebujeme dobré monitorovanie. Na to sa aj hodí. (exportér Prometheus a panelu monitorovania Grafana).
Zdroj: habr.com
