Kubernetes klastrite ressursside jälgimine

Ma lõin Kube Eagle'i – Prometheus'e eksportija. See on lahe tööriist, mis aitab paremini mõista väikeste ja keskmiste klasside ressursse. Lõppkokkuvõttes säästsin ma mitusada dollarit, kuna suutsin leida õiged masina tüübid ja seadistada rakenduste ressursipiirangud vastavalt töökoormusele.

Räägin eelistest Kube Eagle, kuid kõigepealt selgitan, mis probleemid tekkisid ja miks oli vajalik kvaliteetne jälgimine.

Haldasin mõnda klassi, kus oli 4–50 sõlme. Igas klassis oli kuni 200 mikroteenust ja rakendust. Et tõhusamalt kasutada olemasolevat riistvara, olid enamus kasutuselevõtteid seadistatud burstable-mälu ja CPU ressurssidega. Nii saavad pood võtta kasutusele saadaval olevad ressursid, kui neid on vaja, ja seejuures ei sega nad teisi rakendusi selle sõlme peal. Kas see pole tore?

Ja kuigi klass kasutas suhteliselt vähe CPU-d (8%) ja mälu (40%), tekkis meil pidevalt probleeme poodide väljatõrjumisega, kui need püüdsid eraldada rohkem mälu, kui sõlmes oli saadaval. Meil oli tol ajal ainult üks paneel Kubernetes'e ressursside jälgimiseks. Selline:

Grafana paneel ainult cAdvisor'i mõõdikute jaoks

Sellega paneeliga ei ole probleem näha sõlmi, mis tarbivad palju mälu ja CPU-d. Probleem on aru saada, mis on põhjuseks. Et potid ikka paigal püsiksid, võiks kõikides pod'des tõepoolest seadistada tagatud ressursid (taotletud ressursid on võrdsed piiranguga). Kuid see ei ole ruumi kõige nutikam kasutamine. Klassis oli mitusada gigabaiti mälu, kuid mõned sõlmed nälgisid, samas kui teistel jäi üle 4–10 GB.

Tuleb välja, et Kubernetes'e planeerija jagas töökoormusi saadaval olevate ressursside vahel ebavõrdselt. Kubernetes'e planeerija arvesse võtab erinevaid konfiguratsioone: affinity reeglid, taints ja tolerantsid, sõlmede valijad, mis võivad piirata saadaval olevaid sõlmi. Kuid minu puhul ei olnud midagi sellist, ja pod'd planeeriti vastavalt igas sõlmes taotletud ressurssidele.

Pod'ile valiti sõlm, kus oli kõige rohkem vabu ressursse ja mis vastas taotluse tingimustele. Lõpuks selgus, et sõlmedes taotletud ressursid ei kattunud tegeliku kasutusega, ja siin tuli appi Kube Eagle ning tema ressursside jälgimisvõimalused.

Peaaegu kõik minu Kubernetes'i klassid jälgiti ainult Node exporter ja Kube State MetricsNode Exporter annab statistikat sisendi, väljundi ja ketta kasutamise, CPU ja RAM-i kohta, samas kui Kube State Metrics näitab Kubernetes'i objektide mõõdikuid, näiteks CPU ja mälu ressursi nõudeid ja limiite.

Peame ühendama kasutuse mõõdikud nõudluse ja limiitidega Grafanas, et saada kogu teave probleemist. Tundub lihtne, kuid tegelikult on nende kahe tööriista märgistamine erinev ning mõnel mõõdikul pole isegi metaandmete sildid. Kube Eagle teeb kõik ise ja paneel näeb välja selline:

Kube Eagle'i jälgimispaneel

Oleme suutnud lahendada palju ressursiprobleeme ja säästa riistvara:

1. Mõned arendajad ei teadnud, kui palju ressursse mikroteenused vajavad (või ei viitsinud sellega tegeleda). Meil polnud vahendeid vale ressursi nõudluse leidmiseks - selleks peab teadma kasutust ning nõudmisi ja limiite. Nüüd nad näevad Prometheuse mõõdikuid, jälgivad tegelikku kasutust ja kohandavad nõudmisi ja limiite.
2. JVM-i rakendused võtavad nii palju RAM-i, kui nad saavad. Prügikoristaja vabastab mälu ainult siis, kui kasutus ületab 75%. Kuna enamikul teenustest on mälu burstable, kasutas JVM alati rohkem mälu. Seetõttu tarbisid kõik need Java-teenused palju rohkem RAM-i, kui oodata oli.
3. Mõned rakendused küsisid liiga palju mälu, ja Kubernetes'i planeerija ei eraldanud neid sõlmede teistele rakendustele, ehkki tegelikult olid nad vabad. Üks arendaja lisas kogemata nõudlusse liigse numbri ja haaras endale suure osa RAM-ist: 20 GB asemel 2. Keegi ei märganud. Rakendusel oli 3 replikat, nii et kannatada sai koguni 3 sõlme.
4. Oleme kehtestanud piirangud ressurssidele, ümber planeerinud podid õigete nõudmistega ja saavutanud ideaalse tasakaalu raudvara kasutuses kõigis sõlmedes. Mõned sõlmed oleks isegi võimalik sulgeda. Ja siis nägime, et meil on valed masinad (CPU-le orienteeritud, mitte mälule). Muutsime tüüpi ja eemaldasime veel mõned sõlmed.

Summary

Burstable ressurssidega klastris kasutate paremini olemasolevat riistvara, kuid Kubernetes'i planeerija plaanib podid ressursside nõudluste alusel, mis on ohtlik. Et kahe kärbsega pihta saada: vältida probleeme ja kasutada ressursse maksimaalselt, on vajalik hea jälgimine. Seda ongi vaja. Kube Eagle (Prometheuse eksportija ja Grafana jälgimistahvel).

Allikas: habr.com