Stvorio sam Kube Eagle - Prometheus izvoznika. Pokazalo se da je to super stvar koja pomaže da se bolje razumiju resursi malih i srednjih klastera. Na kraju sam uštedio stotine dolara jer sam izabrao prave tipove mašina i konfigurisao ograničenja resursa aplikacije za radna opterećenja.
Reći ću vam o prednostima , ali prvo ću objasniti što je izazvalo frku i zašto je bio potreban kvalitetan nadzor.
Upravljao sam nekoliko klastera od 4–50 čvorova. Svaki klaster sadrži do 200 mikroservisa i aplikacija. Da bi se bolje iskoristio postojeći hardver, većina implementacija je konfigurisana sa brzim RAM i CPU resursima. Na ovaj način, podovi mogu uzeti raspoložive resurse ako je potrebno, a u isto vrijeme ne ometaju druge aplikacije na ovom čvoru. Pa, zar nije sjajno?
I iako je klaster trošio relativno malo CPU-a (8%) i RAM-a (40%), stalno smo imali problema sa podovima koji su bili preuzeti kada su pokušavali da dodijele više memorije nego što je bilo dostupno na čvoru. Tada smo imali samo jednu kontrolnu tablu za nadgledanje Kubernetes resursa. Volim ovo:
Grafana kontrolna tabla samo sa cAdvisor metrikom
Sa takvim panelom nije problem vidjeti čvorove koji jedu puno memorije i CPU-a. Problem je shvatiti šta je razlog. Da bi se podovi zadržali na mjestu, mogli bi se, naravno, postaviti zagarantovani resursi na svim podovima (zatraženi resursi jednaki ograničenju). Ali ovo nije najpametnija upotreba hardvera. Klaster je imao nekoliko stotina gigabajta memorije, dok su neki čvorovi bili izgladnjeli, dok je drugima ostalo 4-10 GB u rezervi.
Ispostavilo se da je Kubernetes planer raspodijelio radna opterećenja neravnomjerno na dostupne resurse. Kubernetes planer uzima u obzir različite konfiguracije: afinitet, pravila o nedostatku i toleranciji, selektore čvorova koji mogu ograničiti dostupne čvorove. Ali u mom slučaju nije bilo ništa slično, a podovi su planirani ovisno o traženim resursima na svakom čvoru.
Za pod je odabran čvor koji ima najviše slobodnih resursa i koji zadovoljava uslove zahtjeva. Otkrili smo da traženi resursi na čvorovima ne odgovaraju stvarnoj upotrebi, i tu su Kube Eagle i njegove mogućnosti praćenja resursa priskočile u pomoć.
Skoro sve Kubernetes klastere pratim samo sa и . Node Exporter pruža statistiku o upotrebi I/O i diska, CPU-a i RAM-a, dok Kube State Metrics prikazuje metriku Kubernetes objekata kao što su zahtjevi i ograničenja CPU-a i memorijskih resursa.
Trebamo kombinirati metriku korištenja sa metrikom zahtjeva i limita u Grafani i tada ćemo dobiti sve informacije o problemu. Ovo zvuči jednostavno, ali ova dva alata zapravo različito nazivaju oznake, a neke metrike uopće nemaju oznake metapodataka. Kube Eagle sve radi sam i panel izgleda ovako:
Uspjeli smo riješiti mnoge probleme sa resursima i uštedjeti opremu:
- Neki programeri nisu znali koliko resursa je potrebno mikroservisima (ili se jednostavno nisu trudili). Nije bilo načina da pronađemo pogrešne zahtjeve za resursima - za to moramo znati potrošnju plus zahtjeve i ograničenja. Sada vide Prometheus metriku, prate stvarnu upotrebu i prilagođavaju zahtjeve i ograničenja.
- JVM aplikacije zauzimaju onoliko RAM-a koliko mogu podnijeti. Sakupljač smeća oslobađa memoriju samo kada se koristi više od 75%. A pošto većina servisa ima memoriju koja se može raspršiti, nju je uvijek zauzimao JVM. Stoga su svi ovi Java servisi trošili mnogo više RAM-a nego što se očekivalo.
- Neke aplikacije su zahtijevale previše memorije, a Kubernetes planer nije dao ove čvorove drugim aplikacijama, iako su u stvari bili slobodniji od drugih čvorova. Jedan programer je slučajno dodao dodatnu cifru u zahtjev i zgrabio veliki komad RAM-a: 20 GB umjesto 2. Niko nije primijetio. Aplikacija je imala 3 replike, tako da su zahvaćena čak 3 čvora.
- Uveli smo ograničenja resursa, reprogramirali podove s ispravnim zahtjevima i dobili idealnu ravnotežu korištenja hardvera na svim čvorovima. Nekoliko čvorova je moglo biti potpuno zatvoreno. A onda smo vidjeli da imamo pogrešne mašine (CPU orijentisane, a ne memorijske). Promijenili smo tip i izbrisali još nekoliko čvorova.
Ishodi
Sa resursima koji se mogu raspršiti u klasteru, efikasnije koristite raspoloživi hardver, ali Kubernetes planer raspoređuje podove na osnovu zahtjeva za resursima, a to je preopterećeno. Da biste ubili dvije muhe jednim udarcem: da biste izbjegli probleme i maksimalno iskoristili resurse, potreban vam je dobar nadzor. Zbog toga će biti od koristi (Prometheus izvoznik i Grafana kontrolna tabla).
izvor: www.habr.com