Vytvoril som Kube Eagle - exportéra Prometheus. Ukázalo sa, že je to skvelá vec, ktorá pomáha lepšie pochopiť zdroje malých a stredných klastrov. Nakoniec som ušetril stovky dolárov, pretože som vybral správne typy počítačov a nakonfiguroval limity aplikačných prostriedkov pre pracovné zaťaženie.
Poviem vám o výhodách , ale najprv vysvetlím, čo spôsobilo ten rozruch a prečo bolo potrebné kvalitné monitorovanie.
Spravil som niekoľko zhlukov 4–50 uzlov. Každý klaster obsahuje až 200 mikroslužieb a aplikácií. Aby sa lepšie využil existujúci hardvér, väčšina nasadení bola nakonfigurovaná s výbušnou pamäťou RAM a prostriedkami CPU. Pody tak môžu v prípade potreby odoberať dostupné zdroje a zároveň nezasahovať do iných aplikácií na tomto uzle. No nie je to skvelé?
A hoci klaster spotreboval relatívne málo CPU (8 %) a RAM (40 %), neustále sme mali problémy s preemptovaním modulov, keď sa pokúšali alokovať viac pamäte, ako bolo dostupné v uzle. Vtedy sme mali iba jeden dashboard na monitorovanie zdrojov Kubernetes. Páči sa ti to:
Dashboard Grafana iba s metrikami cAdvisor
S takýmto panelom nie je problém vidieť uzly, ktoré žerú veľa pamäte a CPU. Problém je zistiť, aký je dôvod. Na udržanie modulov na mieste je možné samozrejme nastaviť garantované zdroje na všetkých moduloch (požadované zdroje sa rovnajú limitu). Toto však nie je najinteligentnejšie využitie hardvéru. Klaster mal niekoľko stoviek gigabajtov pamäte, pričom niektoré uzly hladovali, zatiaľ čo iné mali v rezerve 4–10 GB.
Ukazuje sa, že plánovač Kubernetes rozdelil pracovné zaťaženie nerovnomerne medzi dostupné zdroje. Plánovač Kubernetes berie do úvahy rôzne konfigurácie: pravidlá afinity, poškvrny a tolerancie, selektory uzlov, ktoré môžu obmedziť dostupné uzly. Ale v mojom prípade nič také nebolo a moduly boli plánované v závislosti od požadovaných zdrojov na každom uzle.
Pre modul bol vybratý uzol, ktorý má najviac voľných prostriedkov a ktorý spĺňa podmienky požiadavky. Zistili sme, že požadované zdroje na uzloch nezodpovedali skutočnému použitiu, a to je miesto, kde Kube Eagle a jeho možnosti monitorovania zdrojov prišli na pomoc.
Takmer všetky klastre Kubernetes mám monitorované iba pomocou и . Node Exporter poskytuje štatistiky o I/O a využití disku, CPU a RAM, zatiaľ čo Kube State Metrics zobrazuje metriky objektov Kubernetes, ako sú požiadavky a limity CPU a pamäte.
Musíme skombinovať metriky používania s metrikami požiadaviek a limitov v Grafane a potom získame všetky informácie o probléme. Znie to jednoducho, ale tieto dva nástroje v skutočnosti pomenúvajú štítky inak a niektoré metriky nemajú vôbec žiadne štítky metadát. Kube Eagle robí všetko sám 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 mikroslužby potrebujú (alebo sa jednoducho neobťažovali). Neexistoval spôsob, ako nájsť nesprávne požiadavky na zdroje – na to potrebujeme poznať spotrebu plus požiadavky a limity. Teraz vidia metriky Prometheus, monitorujú skutočné využitie a upravujú požiadavky a limity.
- Aplikácie JVM zaberajú toľko pamäte RAM, koľko dokážu zvládnuť. Zberač odpadu uvoľní pamäť iba vtedy, keď sa použije viac ako 75 %. A keďže väčšina služieb má výbušnú pamäť, bola vždy obsadená JVM. Preto všetky tieto Java služby zaberali oveľa viac pamäte RAM, ako sa očakávalo.
- Niektoré aplikácie požadovali príliš veľa pamäte a plánovač Kubernetes tieto uzly nedal iným aplikáciám, aj keď v skutočnosti boli voľnejšie ako iné uzly. Jeden vývojár omylom pridal do požiadavky ďalšiu číslicu a schmatol veľkú časť pamäte RAM: 20 GB namiesto 2. Nikto si to nevšimol. Aplikácia mala 3 repliky, takže boli ovplyvnené až 3 uzly.
- Zaviedli sme limity zdrojov, preplánovali pody so správnymi požiadavkami a dosiahli sme ideálnu rovnováhu využitia hardvéru vo všetkých uzloch. Pár uzlov mohlo byť úplne uzavretých. A potom sme videli, že máme nesprávne stroje (orientované na CPU, nie na pamäť). Zmenili sme typ a odstránili niekoľko ďalších uzlov.
Výsledky
S burstable zdrojmi v klastri využívate dostupný hardvér efektívnejšie, ale plánovač Kubernetes naplánuje moduly na základe požiadaviek na zdroje, čo je náročné. Aby ste zabili dve muchy jednou ranou: aby ste sa vyhli problémom a využili zdroje naplno, potrebujete dobrý monitoring. To je dôvod, prečo to bude užitočné (vývozca Prometheus a prístrojová doska Grafana).
Zdroj: hab.com