Létrehoztam a Kube Eagle-t — egy Prometheus exportálót. Kiderült, hogy ez egy remek eszköz, ami segít jobban megérteni a kis és közepes klaszterek erőforrásait. Így több száz dollárt is megspóroltam, mert a megfelelő géptípusokat választottam és az alkalmazások erőforrás-korlátozásait a munka terheléséhez igazítottam.
Azzal fogok foglalkozni, hogy milyen előnyökkel jár , de először elmagyarázom, miért alakult ki a probléma, és miért volt szükség a minőségi monitorozásra.
Több klasztert irányítottam 4–50 noddal. Minden klaszterben legfeljebb 200 mikroszolgáltatás és alkalmazás volt. Az adott hardver hatékonyabb kihasználásához a legtöbb telepítést burstable RAM-mal és CPU-erőforrásokkal konfigurálták. Így a podok elérhetik a rendelkezésre álló erőforrásokat, ha szükséges, anélkül, hogy akadályoznák más alkalmazásokat az adott nodon. Ugye, milyen nagyszerű?
Bár a klaszter viszonylag kevés CPU-t (8%) és RAM-ot (40%) használt, folyamatosan gondjaink akadtak a podok kiszorításával, amikor többlet memóriát próbáltak igényelni, mint ami a nodon elérhető volt. Akkoriban csak egyetlen panelünk volt a Kubernetes erőforrásainak monitorozására. Íme, ez volt az:
Grafana panel csupán a cAdvisor metrikáival
Ezzel a panellel nem probléma észlelni azokat a nodokat, amelyek sok memóriát és CPU-t használnak. A kihívás azonban az, hogy megértsük az okát. Ahhoz, hogy a podok a helyükön maradjanak, természetesen beállíthattuk volna a garantált erőforrásokat minden podra (az igényelt erőforrások egyenlők a limittel). De ez nem a legjobban kihasználható hardverhasználat. A klaszterben több száz gigabyte RAM volt, mégis egyes nodok éheztek, míg másoknak 4–10 GB tartalékuk maradt.
Ebből adódóan a Kubernetes ütemezője egyenetlenül osztotta el a munka terheléseket a rendelkezésre álló erőforrások között. A Kubernetes ütemezője figyelembe vesz különböző konfigurációkat: affinity szabályok, taints és tolerálások, node szelektorok, amelyek korlátozhatják a rendelkezésre álló nodokat. De az én esetemben ilyesmi nem volt, és a podok az egyes nodok igényelt erőforrásai alapján lettek ütemezve.
A pod számára azt a nodot választották, amely rendelkezett a legnagyobb szabad erőforrásokkal, és amely megfelelt a kérés feltételeinek. Az történt, hogy a nodokon igényelt erőforrások nem egyeztek meg a tényleges használattal, és itt jött a segítségünkre a Kube Eagle és annak erőforrás-monitorozási lehetőségei.
Szinte minden Kubernetes klaszterem csak a és . A Node Exporter statisztikát ad a bemenetről-kimenetről és a lemezhasználatról, CPU-ról és memóriáról, míg a Kube State Metrics a Kubernetes objektumok metrikáit mutatja be, például a CPU és memória erőforrásainak kéréseit és limitjeit.
Össze kell kapcsolnunk a használat metrikákat a kérések és limitjeik metrikáival a Grafana-ban, és akkor megkapjuk az összes problémára vonatkozó információt. Egyszerűen hangzik, de valójában ezekben a két eszközben a címkék különböző neveken futnak, és néhány metrikának nincsenek metaadat címkéi. A Kube Eagle mindent automatikusan megold, és a paneleink így néznek ki:
Sok problémát sikerült megoldanunk az erőforrásokkal, és rengeteg hardvert megkíméltünk:
- Néhány fejlesztő nem tudta, hogy a mikroszolgáltatásoknak mennyi erőforrásra van szükségük (vagy egyszerűen nem érdekelték őket). Nem volt semmink a hibás erőforrás-igények azonosítására - ehhez ismerni kell a fogyasztást, valamint a kéréseket és limitjeiket. Most látják a Prometheus metrikákat, figyelik a tényleges használatot, és a kéréseket és limitjeiket a saját szükségleteikhez igazítják.
- A JVM-alkalmazások annyi memóriát használnak, amennyit elbírnak. A szemétgyűjtő csak akkor szabadít fel memóriát, ha a használat meghaladja a 75%-ot. Mivel a legtöbb szolgáltatás memóriája burstable volt, ezt mindig a JVM foglalta el. Ezért minden Java-szolgáltatás sokkal több memóriát használt, mint amire számítottunk.
- Néhány alkalmazás túl sok memóriát kért, és a Kubernetes ütemező nem adta oda ezeket a csomópontokat a többi alkalmazásnak, holott valójában szabadabbak voltak a másik csomóponthoz képest. Az egyik fejlesztő véletlenül egy plusz számjegyet adott a kéréshez, és így elfoglalta a nagy részt a memóriából: 20 GB helyett 2. Senki sem vette észre. Az alkalmazásnak 3 replikája volt, így összesen 3 csomópont szenvedett.
- Erőforráslimitációkat vezettünk be, és újraütemeztük a podokat a megfelelő kérésekkel, így tökéletes egyensúlyt értünk el a hardverhasználatban a csomópontok között. Néhány csomópontot teljesen le lehetett zárni. Aztán észrevettük, hogy nem megfelelő gépeink vannak (CPU-centrikusak, nem memória-orientáltak). Megváltoztattuk a típust és eltávolítottunk még néhány csomópontot.
Összegzés
A burstable erőforrásokkal a klaszterben hatékonyabban használja a rendelkezésre álló hardvert, de a Kubernetes ütemező a kérések alapján tervezi a podokat, ami problémákhoz vezethet. Ahhoz, hogy két legyet üssön egy csapásra: elkerülje a problémákat és maximálisan kihasználja az erőforrásokat - jó monitoringra van szükség. Erre lesz szükség. (Prometheus exportáló és Grafana vezérlőpult).
Forrás: habr.com
