Vytvořil jsem Kube Eagle — exporter Prometheus. Ukázalo se to jako skvělý nástroj, který pomáhá lépe porozumět prostředkům malých a středních clusterů. Nakonec jsem ušetřil několik stovek dolarů, protože jsem vybíral správné typy strojů a nastavoval limity prostředků aplikací dle pracovních zátěží.
Povím o výhodách , ale nejprve vysvětlím, proč došlo ke konfliktu a k čemu bylo potřeba kvalitní monitorování.
Spravoval jsem několik clusterů s 4–50 uzly. V každém clusteru bylo až 200 mikroslužeb a aplikací. Abychom efektivně využili dostupný hardware, většina nasazení byla nastavena s burstable RAM a CPU prostředky. Tak mohly pody vzít dostupné prostředky, když bylo potřeba, a přitom nebránit ostatním aplikacím na tomto uzlu. No, není to skvělé?
I když cluster spotřebovával relativně málo CPU (8 %) a RAM (40 %), neustále jsme měli problémy s odstraňováním podů, když se snažily alokovat více paměti, než bylo na uzlu k dispozici. Měli jsme tehdy pouze jeden panel pro monitorování zdrojů Kubernetes. Takovýto:
Panel Grafana pouze s metrikami cAdvisor
S takovým panelem není problém vidět uzly, které spotřebovávají hodně paměti a CPU. Problém je pochopit, co je příčinou. Aby pody zůstaly na svém místě, mohly by se samozřejmě nastavit garantované prostředky na všech podech (požadované prostředky se rovnají limitu). Ale to není nejchytřejší způsob využití hardwaru. V clusteru bylo několik stovek gigabajtů paměti, přičemž některé uzly hladověly a jiné měly rezervu 4–10 GB.
Výsledkem bylo, že plánovač Kubernetes rozděloval pracovní zátěže podle dostupných prostředků nerovnoměrně. Plánovač Kubernetes zohledňuje různé konfigurace: pravidla affinity, taint a tolerace, selektory uzlů, které mohou omezovat dostupné uzly. Ale v mém případě nic takového nebylo a pody byly plánovány podle požadovaných prostředků na každém uzlu.
Pro pod se vybírala uzlová, která měla nejvíce dostupných prostředků a splňovala požadavky. Měli jsme situaci, že požadované prostředky na uzlech se neshodovaly s skutečným využitím, a zde přišel na pomoc Kube Eagle a jeho schopnosti monitorování prostředků.
Skoro všechny moje Kubernetes clustery byly sledovány pouze s a . Node Exporter poskytuje statistiky o vstupu a výstupu, využití disku, CPU a RAM, zatímco Kube State Metrics zobrazuje metriky objektů Kubernetes, jako jsou požadavky a limity na zdroje CPU a paměti.
Musíme zkombinovat metriky o využití se metrikami požadavků a limitů v Grafaně, a pak získáme všechny informace o problému. Zní to jednoduše, ale ve skutečnosti se v těchto dvou nástrojích označení liší a některé metriky nemají vůbec žádné metadata. Kube Eagle to dělá za vás a panel vypadá takto:
Roz řešili jsme mnohé problémy se zdroji a ušetřili jsme hardware:
- Někteří vývojáři nevěděli, kolik zdrojů potřebují mikroservisy (nebo se prostě nezamýšleli). Neměli jsme co použít k hledání špatných požadavků na zdroje — k tomu je potřeba znát spotřebu plus požadavky a limity. Teď vidí metriky Prometheus, monitorují skutečné využití a přizpůsobují požadavky a limity.
- JVM aplikace berou tolik RAM, kolik vlezou. Garbage collector uvolňuje paměť, pouze pokud je využito více než 75%. A jelikož většina služeb má paměť burstable, JVM ji vždy zabíral. Proto všechny tyto Java služby spotřebovaly mnohem více RAM, než se očekávalo.
- Některé aplikace požadovaly příliš mnoho paměti, a plánovač Kubernetes nedovolil tyto uzly ostatním aplikacím, i když byly ve skutečnosti svobodnější než jiné uzly. Jeden vývojář omylem přidal navíc číslo do požadavku a zabral velký kus paměti: 20 GB místo 2. Nikdo si toho nevšiml. Aplikace měla 3 repliky, takže poškodilo to hned 3 uzly.
- Zavedli jsme omezení na zdroje, přeplánovali jsme pody s správnými požadavky a získali ideální rovnováhu ve využití hardwaru na všech uzlech. Některé uzly jsme mohli dokonce vypnout. A pak jsme zjistili, že máme nesprávný typ strojů (zaměřené na CPU, nikoli na paměť). Změnili jsme typ a odstranili další uzly.
Závěry
S burstable zdroji v clustru efektivněji využíváte dostupný hardware, ale plánovač Kubernetes naplánuje pody podle požadavků na zdroje, což může být problematické. Abychom zmátli dvě mouchy jednou ranou: vyhnuli se problémům a plně využili zdroje, potřebujeme dobré monitorování. K tomu se hodí. (exportér Prometheus a panel pro sledování Grafana).
Zdroj: habr.com
