Sukūriau Kube Eagle – Prometheus eksportuotoją. Tai pasirodė šaunus dalykas, padedantis geriau suprasti mažų ir vidutinių klasterių išteklius. Galiausiai sutaupiau šimtus dolerių, nes pasirinkau tinkamus mašinų tipus ir sukonfigūravau darbo krūvių taikomųjų išteklių apribojimus.
Papasakosiu apie privalumus , bet pirmiausia paaiškinsiu, kas sukėlė triukšmą ir kodėl reikėjo kokybiško stebėjimo.
Valdžiau keletą 4–50 mazgų grupių. Kiekviename klasteryje yra iki 200 mikro paslaugų ir programų. Siekiant geriau išnaudoti esamą aparatinę įrangą, dauguma diegimų buvo sukonfigūruoti naudojant sugadintus RAM ir procesoriaus išteklius. Tokiu būdu blokai prireikus gali užimti turimus išteklius ir tuo pačiu netrukdyti kitoms šio mazgo programoms. Na, argi ne puiku?
Ir nors klasteris sunaudojo palyginti mažai procesoriaus (8 %) ir RAM (40 %), nuolat turėdavome problemų, kai blokai buvo iš anksto apsaugoti, kai jie bandė skirti daugiau atminties, nei buvo mazge. Tada turėjome tik vieną informacijos suvestinę Kubernetes ištekliams stebėti. Kaip šitas:
„Grafana“ prietaisų skydelis tik su „cAdvisor“ metrika
Naudojant tokį skydelį, nėra problemų matyti mazgus, kurie valgo daug atminties ir procesoriaus. Problema yra išsiaiškinti, kokia yra priežastis. Norint, kad ankštys liktų savo vietose, galima, žinoma, nustatyti garantuotus išteklius visose talpyklose (prašomi ištekliai lygūs limitui). Tačiau tai nėra pats protingiausias aparatinės įrangos naudojimas. Klasteryje buvo keli šimtai gigabaitų atminties, o kai kurie mazgai badavo, o kituose rezerve liko 4–10 GB.
Pasirodo, kad Kubernetes planavimo priemonė darbo krūvius paskirstė netolygiai tarp turimų išteklių. Kubernetes planavimo priemonė atsižvelgia į įvairias konfigūracijas: giminingumą, nešvarumų ir tolerancijos taisykles, mazgų parinkiklius, kurie gali apriboti galimus mazgus. Bet mano atveju nieko panašaus nebuvo, o ankštys buvo planuojamos atsižvelgiant į prašomus išteklius kiekviename mazge.
Podavimui buvo pasirinktas mazgas, turintis daugiausiai laisvų išteklių ir atitinkantis užklausos sąlygas. Mes nustatėme, kad mazgų prašomi ištekliai neatitiko faktinio naudojimo, todėl čia į pagalbą atėjo Kube Eagle ir jos išteklių stebėjimo galimybės.
Beveik visas „Kubernetes“ grupes stebiu tik naudojant и . „Node Exporter“ pateikia statistiką apie įvesties / išvesties ir disko, procesoriaus ir RAM naudojimą, o „Kube State Metrics“ rodo „Kubernetes“ objektų metriką, pvz., užklausas ir procesoriaus bei atminties išteklių limitus.
Turime sujungti naudojimo metriką su užklausų ir apribojimų metrika Grafana, tada gausime visą informaciją apie problemą. Tai skamba paprastai, tačiau iš tikrųjų abu įrankiai etiketes pavadina skirtingai, o kai kuriose metrikose metaduomenų etikečių apskritai nėra. Kube Eagle viską daro pats, o skydelis atrodo taip:
Pavyko išspręsti daug problemų su ištekliais ir sutaupyti įrangos:
- Kai kurie kūrėjai nežinojo, kiek išteklių reikia mikropaslaugoms (arba tiesiog nesivargino). Mes negalėjome rasti neteisingų išteklių užklausų – tam turime žinoti suvartojimą, užklausas ir ribas. Dabar jie mato „Prometheus“ metrikas, stebi faktinį naudojimą ir koreguoja užklausas bei apribojimus.
- JVM programos užima tiek RAM, kiek gali apdoroti. Šiukšlių rinktuvas atmintį išlaisvina tik tada, kai naudojama daugiau nei 75 proc. Ir kadangi dauguma paslaugų turi sugadintą atmintį, ją visada užėmė JVM. Todėl visos šios „Java“ paslaugos sunaudojo daug daugiau RAM, nei tikėtasi.
- Kai kurios programos reikalavo per daug atminties, o Kubernetes planavimo priemonė nesuteikė šių mazgų kitoms programoms, nors iš tikrųjų jie buvo laisvesni nei kiti mazgai. Vienas kūrėjas netyčia pridėjo papildomą skaitmenį prašyme ir pagriebė didelę RAM: 20 GB vietoj 2. Niekas nepastebėjo. Programa turėjo 3 kopijas, todėl buvo paveikti net 3 mazgai.
- Įvedėme išteklių apribojimus, perplanavome rinkinius su teisingomis užklausomis ir pasiekėme idealų aparatinės įrangos naudojimo balansą visuose mazguose. Pora mazgų galėjo būti visiškai uždaryti. Ir tada pamatėme, kad turime netinkamus įrenginius (orientuotus į centrinį procesorių, o ne į atmintį). Pakeitėme tipą ir ištrynėme dar kelis mazgus.
rezultatai
Kai klasteryje yra sugadintų išteklių, efektyviau naudojate turimą aparatinę įrangą, tačiau Kubernetes planavimo priemonė suplanuoja rinkinius pagal išteklių užklausas, o tai yra labai sunku. Norėdami vienu akmeniu nužudyti du paukščius: norint išvengti problemų ir maksimaliai panaudoti išteklius, reikia gero stebėjimo. Štai kodėl tai bus naudinga („Prometheus“ eksportuotojas ir „Grafana“ prietaisų skydelis).
Šaltinis: www.habr.com