Vytvořil jsem Kube Eagle – exportéra Prometheus. Ukázalo se, že je to skvělá věc, která pomáhá lépe porozumět zdrojům malých a středních klastrů. Nakonec jsem ušetřil stovky dolarů, protože jsem vybral správné typy strojů a nakonfiguroval limity aplikačních prostředků pro pracovní zátěž.
Řeknu vám o výhodách , ale nejprve vysvětlím, co způsobilo ten povyk a proč bylo potřeba kvalitní monitorování.
Spravoval jsem několik shluků 4–50 uzlů. Každý cluster obsahuje až 200 mikroslužeb a aplikací. Pro lepší využití stávajícího hardwaru byla většina nasazení nakonfigurována s burstable RAM a CPU prostředky. Pody tak mohou v případě potřeby odebírat dostupné zdroje a zároveň nezasahovat do ostatních aplikací na tomto uzlu. No, není to skvělé?
A přestože cluster spotřeboval relativně málo CPU (8 %) a RAM (40 %), neustále jsme měli problémy s preemptováním modulů, když se snažily alokovat více paměti, než bylo na uzlu dostupné. Tehdy jsme měli pouze jeden řídicí panel pro monitorování zdrojů Kubernetes. Takhle:
Ovládací panel Grafana pouze s metrikami cAdvisor
S takovým panelem není problém vidět uzly, které žerou hodně paměti a CPU. Problém je zjistit, jaký je důvod. Aby moduly zůstaly na místě, bylo možné samozřejmě nastavit garantované zdroje na všech modulech (požadované zdroje rovnající se limitu). To ale není nejchytřejší využití hardwaru. Cluster měl několik set gigabajtů paměti, zatímco některé uzly hladověly, zatímco jiným zbývalo v rezervě 4–10 GB.
Ukázalo se, že plánovač Kubernetes rozložil pracovní zátěž nerovnoměrně mezi dostupné zdroje. Plánovač Kubernetes bere v úvahu různé konfigurace: pravidla afinity, narušení a tolerancí, selektory uzlů, které mohou omezit dostupné uzly. Ale v mém případě nic takového nebylo a moduly byly naplánovány v závislosti na požadovaných zdrojích na každém uzlu.
Pro pod byl vybrán uzel, který má nejvíce volných prostředků a který splňuje podmínky požadavku. Zjistili jsme, že požadované zdroje na uzlech neodpovídaly skutečnému využití, a to je místo, kde Kube Eagle a jeho možnosti monitorování zdrojů přišli na pomoc.
Téměř všechny clustery Kubernetes mám monitorované pouze pomocí и . Node Exporter poskytuje statistiky I/O a využití disku, CPU a RAM, zatímco Kube State Metrics zobrazuje metriky objektů Kubernetes, jako jsou požadavky a limity CPU a paměti.
Musíme zkombinovat metriky využití s metrikami požadavků a limitů v Grafaně a pak získáme všechny informace o problému. Zní to jednoduše, ale tyto dva nástroje ve skutečnosti pojmenovávají štítky jinak a některé metriky nemají vůbec žádné štítky metadat. Kube Eagle dělá vše sám a panel vypadá takto:
Podařilo se nám vyřešit mnoho problémů se zdroji a ušetřit vybavení:
- Někteří vývojáři nevěděli, kolik zdrojů mikroslužby potřebují (nebo se prostě neobtěžovali). Neexistoval způsob, jak najít nesprávné požadavky na zdroje - k tomu potřebujeme znát spotřebu plus požadavky a limity. Nyní vidí metriky Prometheus, monitorují skutečné využití a upravují požadavky a limity.
- Aplikace JVM zabírají tolik paměti RAM, kolik mohou zvládnout. Kolektor uvolnění paměti uvolní paměť pouze při využití více než 75 %. A protože většina služeb má burstable paměť, byla vždy obsazena JVM. Proto všechny tyto Java služby spotřebovávaly mnohem více RAM, než se očekávalo.
- Některé aplikace požadovaly příliš mnoho paměti a plánovač Kubernetes tyto uzly nedal jiným aplikacím, i když ve skutečnosti byly volnější než jiné uzly. Jeden vývojář omylem přidal do požadavku další číslici a sebral velký kus paměti RAM: 20 GB místo 2. Nikdo si toho nevšiml. Aplikace měla 3 repliky, takže byly ovlivněny až 3 uzly.
- Zavedli jsme limity zdrojů, přeplánovali pody se správnými požadavky a dosáhli ideální rovnováhy využití hardwaru napříč všemi uzly. Pár uzlů mohlo být úplně uzavřeno. A pak jsme viděli, že máme špatné stroje (orientované na CPU, ne na paměť). Změnili jsme typ a odstranili několik dalších uzlů.
Výsledky
S burstable zdroji v clusteru využíváte dostupný hardware efektivněji, ale plánovač Kubernetes plánuje moduly na základě požadavků na zdroje, a to je náročné. Chcete-li zabít dvě mouchy jednou ranou: abyste se vyhnuli problémům a využili zdroje naplno, potřebujete dobrý dohled. To je důvod, proč to bude užitečné (Exportér Prometheus a řídicí panel Grafana).
Zdroj: www.habr.com