🥇Pratimo resurse Kubernetes klastera

Stvorio sam Kube Eagle - Prometheus izvoznik. Ispostavilo se da je to sjajan alat koji pomaže bolje razumjeti resurse malih i srednjih klastera. Na kraju sam uštedio nekoliko stotina dolara jer sam odabrao prave vrste mašina i postavio ograničenja resursa aplikacija prema radnim opterećenjima.

Ispričat ću o prednostima Kube Eagle, ali prvo ću objasniti zbog čega je došlo do problema i zašto je potrebna kvalitetna monitoringa.

Upravljao sam nekoliko klastera s 4–50 nodova. U svakom klasteru - do 200 mikroservisa i aplikacija. Da bismo učinkovitije koristili dostupno hardver, većina implementacija je bila postavljena s burstable RAM-om i resursima CPU-a. Tako podovi mogu uzeti dostupne resurse kada je potrebno, a da pritom ne ometaju druge aplikacije na toj nodi. Zar to nije sjajno?

Iako je klaster relativno malo trošio CPU (8%) i RAM (40%), stalno smo se suočavali s problemima vezanima za izbacivanje podova kada su pokušavali dodijeliti više memorije nego što je dostupno na nodi. Tada smo imali samo jednu ploču za praćenje resursa Kubernetes-a. Ovako je izgledala:

Grafana ploča samo s metrikama cAdvisor

S ovom pločom, nodovi koji troše mnogo memorije i CPU-a, jasno se vide. Problem je razumjeti uzrok. Da bi podovi ostali na svom mjestu, moglo bi se naravno postaviti garantirane resurse na svim podovima (zahtijevani resursi su jednaki limitima). No, to nije najsmaršnije iskorištavanje hardvera. U klasteru je bilo nekoliko stotina gigabajta memorije, a neki nodovi su bili pošteđeni, dok su drugi imali u rezervi po 4–10 GB.

Dakle, Kubernetes planer je nerazmjerno raspodijelio radna opterećenja između dostupnih resursa. Kubernetes planer uzima u obzir različite konfiguracije: pravila affinity, taints i tolerations, selektore nodova, koji mogu ograničiti dostupne nodove. No, u mom slučaju nije bilo ništa od toga, a podovi su se planirali na temelju zahtijevanih resursa na svakoj nodi.

Za pod se odabire noda koja ima najviše slobodnih resursa i koja ispunjava uvjete zahtjeva. Imali smo situaciju da zahtijevani resursi na nodovima ne odgovaraju stvarnoj upotrebi, i tu je Kube Eagle došao u pomoć sa svojim mogućnostima praćenja resursa.

Gotovo svi moji Kubernetes klasteri bili su praćeni samo s Node exporter i Kube State Metrics. Node Exporter pruža statistiku o ulazu-izlazu i upotrebi diskova, CPU-a i RAM-a, dok Kube State Metrics prikazuje metrike objekata Kubernetes, poput zahtjeva i ograničenja za CPU i memoriju.

Moramo kombinirati metrike korištenja s metrima zahtjeva i ograničenja u Grafani, a tada ćemo dobiti sve informacije o problemu. Zvuci jednostavno, ali u ovim dvjema alatima oznake se nazivaju različito, a neke metrike uopće nemaju oznake metapodataka. Kube Eagle sve to radi automatski, a panel izgleda ovako:

Kube Eagle nadzorna ploča

Uspjeli smo riješiti mnoge probleme s resursima i sačuvati opremu:

Neki programeri nisu znali koliko je resursa potrebno mikroservisima (ili jednostavno nisu obraćali pažnju). Nismo imali način da pronađemo neispravne zahtjeve za resursima - za to je potrebno znati potrošnju plus zahtjeve i ograničenja. Sada vide metrike Prometheus-a, prate stvarnu upotrebu i prilagođavaju zahtjeve i ograničenja.
JVM aplikacije uzimaju koliko god RAM-a mogu. Sakupljač smeća oslobađa memoriju samo ako je iskorišteno više od 75%. Budući da je većini servisa memorija burstable, JVM ju je uvijek zauzimao. Stoga su svi ti Java servisi trošili mnogo više RAM-a nego što se očekivalo.
Neke aplikacije su tražile previše memorije, a Kubernetes planer nije dopuštao ovim nodovima da budu dostupni drugim aplikacijama, iako su u stvarnosti bili slobodniji od drugih nodova. Jedan programer je slučajno dodao suvišnu cifru u zahtjevu i zauzeo veliki dio RAM-a: 20 GB umjesto 2. Nitko to nije primijetio. Aplikacija je imala 3 replike, tako da su pogođena čak 3 noda.
Postavili smo ograničenja na resurse, reorganizirali podove s pravilnim zahtjevima i postigli savršenu ravnotežu korištenja hardvera između svih nodova. Nekoliko nodova se čak moglo zatvoriti. A onda smo primijetili da imamo pogrešne mašine (usmjerene na CPU, a ne na memoriju). Promijenili smo tip i uklonili još nekoliko nodova.

Zaključci

S burstable resursima u klasteru efikasnije koristite dostupni hardver, ali Kubernetes planer raspoređuje podove prema zahtjevima za resursima, što može izazvati probleme. Da bismo ubili dvije muhe jednim udarcem: izbjegli probleme i u potpunosti iskoristili resurse, potrebna je dobra nadzorna ploča. Zato je to od pomoći. Kube Eagle (eksporter Prometheus i kontrolna ploča Grafana).

Izvor: habr.com