Lõin Kube Eagle’i – Prometheuse eksportija. See osutus lahedaks asjaks, mis aitab paremini mõista väikeste ja keskmise suurusega klastrite ressursse. Lõpuks säästsin sadu dollareid, kuna valisin õiged masinatüübid ja konfigureerisin rakenduste ressursipiirangud töökoormuse jaoks.
Ma räägin teile eelistest , kuid kõigepealt selgitan, mis tekitas kära ja miks oli vaja kvaliteetset seiret.
Mul õnnestus mitu 4–50 sõlmest koosnevat klastrit. Iga klaster sisaldab kuni 200 mikroteenust ja rakendust. Olemasoleva riistvara paremaks kasutamiseks konfigureeriti enamik juurutusi puruneva RAM-i ja protsessori ressurssidega. Nii saavad kaustad vajadusel kasutada olemasolevaid ressursse ja samal ajal ei sega selle sõlme teisi rakendusi. Noh, kas pole suurepärane?
Ja kuigi klaster tarbis suhteliselt vähe CPU-d (8%) ja RAM-i (40%), oli meil pidevalt probleeme kaunade ennetamisega, kui nad üritasid eraldada rohkem mälu, kui sõlmes oli. Sel ajal oli meil Kubernetese ressursside jälgimiseks ainult üks armatuurlaud. Nagu nii:
Grafana armatuurlaud ainult cAdvisori mõõdikutega
Sellise paneeli puhul pole probleem näha sõlme, mis söövad palju mälu ja protsessorit. Probleem on välja selgitada, mis on põhjus. Podide paigal hoidmiseks võiks loomulikult kõikidele kaunadele seadistada garanteeritud ressursid (nõutud ressursid on limiidiga võrdsed). Kuid see pole riistvara kõige nutikam kasutamine. Klastris oli mitusada gigabaiti mälu, samas kui mõned sõlmed olid näljas, samas kui teistel oli reservi jäänud 4–10 GB.
Selgub, et Kubernetese planeerija jaotas töökoormused saadaolevate ressursside vahel ebaühtlaselt. Kubernetese planeerija võtab arvesse erinevaid konfiguratsioone: afiinsus-, kahjustus- ja taluvusreeglid, sõlmevalijad, mis võivad piirata saadaolevaid sõlmi. Kuid minu puhul polnud midagi sellist ja kaunad kavandati sõltuvalt iga sõlme taotletud ressurssidest.
Podi jaoks valiti sõlm, millel on kõige rohkem vabu ressursse ja mis vastab päringu tingimustele. Leidsime, et sõlmede taotletud ressursid ei vastanud tegelikule kasutusalale ja siin tulid appi Kube Eagle ja selle ressursi jälgimise võimalused.
Peaaegu kõiki Kubernetese klastreid olen jälginud ainult sellega и . Node Exporter pakub statistikat I/O ja ketta, protsessori ja RAM-i kasutamise kohta, samas kui Kube State Metrics näitab Kubernetese objektimõõdikuid, nagu päringud ning protsessori ja mäluressursside piirangud.
Peame ühendama kasutusmõõdikud Grafana taotluste ja piirangute mõõdikutega ning siis saame kogu teabe probleemi kohta. See kõlab lihtsalt, kuid need kaks tööriista nimetavad silte erinevalt ja mõnel mõõdikul pole metaandmete silte üldse. Kube Eagle teeb kõik ise ja paneel näeb välja selline:
Meil õnnestus lahendada palju probleeme ressurssidega ja säästa seadmeid:
- Mõned arendajad ei teadnud, kui palju ressursse mikroteenused vajavad (või lihtsalt ei viitsinud). Meil polnud võimalust leida valesid ressursside päringuid – selleks peame teadma tarbimist pluss päringuid ja limiite. Nüüd näevad nad Prometheuse mõõdikuid, jälgivad tegelikku kasutust ning kohandavad taotlusi ja limiite.
- JVM-i rakendused võtavad nii palju RAM-i kui suudavad. Prügikoguja vabastab mälu ainult siis, kui kasutatakse rohkem kui 75%. Ja kuna enamikul teenustel on purunev mälu, oli see alati JVM-i hõivatud. Seetõttu sõid kõik need Java-teenused oodatust palju rohkem RAM-i.
- Mõned rakendused nõudsid liiga palju mälu ja Kubernetese ajakava ei andnud neid sõlme teistele rakendustele, kuigi tegelikult olid need vabamad kui teised sõlmed. Üks arendaja lisas kogemata taotlusesse lisanumbri ja haaras suure tüki RAM-i: 20 GB asemel 2 GB. Keegi ei märganud. Rakendusel oli 3 koopiat, seega oli mõjutatud kuni 3 sõlme.
- Võtsime kasutusele ressursipiirangud, ajasime ümber õigete päringutega kaustad ja saavutasime kõigi sõlmede riistvarakasutuse ideaalse tasakaalu. Paar sõlme oleks võinud üldse kinni panna. Ja siis nägime, et meil on valed masinad (CPU orienteeritud, mitte mälule orienteeritud). Muutsime tüüpi ja kustutasime veel mitu sõlme.
Tulemused
Klastris olevate purunevate ressursside korral kasutate saadaolevat riistvara tõhusamalt, kuid Kubernetese ajakava ajastab kaustasid ressursside taotluste alusel ja see on tülikas. Kahe kärbe tapmiseks ühe hoobiga: probleemide vältimiseks ja ressursside maksimaalseks kasutamiseks on vaja head jälgimist. Seetõttu on see kasulik (Prometheuse eksportija ja Grafana armatuurlaud).
Allikas: www.habr.com