Jälgime Kubernetes klastri ressursse

Loomisin Kube Eagle'i – Prometheuse eksportija. Selgus, et see on lahe tööriist, mis aitab paremini mõista väikeste ja keskmise suurusega klastrite ressursse. Lõppkokkuvõttes sääsin mitusada dollarit, sest valisin õiged masinatüübid ja kohandasin rakenduste ressursipiirangud vastavalt töökoormusele.

Räägin eeliste kohta Kube Eagle, aga enne seletan, mis probleemid tekkisid ja miks oli vajalik kvaliteetne vaatlus.

Haldasin mitut klastri 4–50 sõlmega. Igas klastris oli kuni 200 mikroteenust ja rakendust. Et kasutada olemasolevat riistvara tõhusamalt, olid enamik juurutusi seadistatud burstable-mäluga ja CPU ressurssidega. Nii saavad podid võtta vajadusel saadaval olevaid ressursse, segamata samas teisi rakendusi sellel sõlmel. Kas pole tore?

Ja kuigi klaster tarbis suhteliselt vähe CPU-d (8%) ja mälukuunde (40%), tekkis meil pidevalt probleeme podide väljasaatmisega, kui nad üritasid eraldada rohkem mälu, kui sõlmelt saadaval oli. Siis oli meil ainult üks paneel Kubernetes ressursside jälgimiseks. Selline:

Grafana paneel ainult cAdvisori mõõdikute jaoks

Sellise paneeliga ei ole probleem näha node'e, mis söövad palju mälu ja CPU-d. Probleem on mõista, mis on põhjus. Et podid paigal püsiksid, oleks muidugi võimalik seadistada garanteeritud ressursid kõigile podidele (taotletud ressursid võrduvad limiidiga). Kuid see ei ole kõige arukam raua kasutamine. Klusteril oli mitu sada gigabaiti mälu, samas kui mõned node'id nälgisid ja teistel jäi alles 4–10 GB.

Lõppkokkuvõttes jaotab Kubernetes'e planeerija töökoormusi saadaval olevate ressursside vahel ebavõrdselt. Kubernetes'e planeerija arvestab erinevaid konfiguratsioone: affinity reeglid, taints ja tolerations, node'i selektorid, mis võivad piirata saadaval olevate node'ide hulka. Kuid minu juhul ei olnud midagi sellist, ning podid planeeriti sõltuvalt taotletud ressurssidest igas node'is.

Podile valiti node, millel oli kõige rohkem vabu ressursse ja mis rahuldas taotluse tingimusi. Meil oli olukord, kus taotletud ressursid node'ides ei vastanud tegelikule kasutusele, ja siia tuli appi Kube Eagle ja selle ressursimonitorimise võimalused.

Mul on peaaegu kõik Kubernetes klastrid jälgitud ainult Node exporteri ja Kube State Metrics. Node Exporter annab statistikat sisendi, väljundi ja diskikasutuse, CPU ja mäluga, samas Kube State Metrics näitab Kubernetes objektide metrikat, nagu CPU ja mälu ressursside päringud ja limiidid.

Peame ühendama kasutusmõõdikud päringute ja limiitide mõõdikute järgi Grafanas ning siis saame kogu teabe probleemist. See kõlab lihtsalt, kuid tegelikult nimetatakse nende kahe tööriista sildid erinevalt ja mõnedel mõõdikutel pole üldse metaandmete silte. Kube Eagle teeb kõik ise ja paneel näeb välja selline:

Kube Eagle'i seirepaneel

Me oleme suutnud lahendada palju ressursiprobleeme ja säästa seadmeid:

1. Mõned arendajad ei teadnud, kui palju ressursse mikroteenused vajavad (või lihtsalt ei viitsinud). Meil polnud midagi, millega leida vale ressursipäringud - selleks on vaja teadlikkust tarbimisest pluss päringud ja limiidid. Nüüd nad näevad Prometheuse mõõdiku, jälgivad tegelikku kasutust ja kohandavad päringud ning limiidid.
2. JVM-rakendused kasutavad nii palju mälu, kui suudavad. Prügikorjaja vabastab mälu ainult siis, kui üle 75% on kasutusel. Kuna enamik teenuseid kasutab burstable mälu, oli JVM alati selle hõivanud. Seetõttu kasutasid kõik need Java-teenused palju rohkem mälu, kui oli oodata.
3. Mõned rakendused küsisid liiga palju mälu, ning Kubernetes'i ajakava ei andnud neid sõlmi teistele rakendustele, kuigi tegelikult olid need vabamad kui teised sõlmed. Üks arendaja lisas kogemata taotlusse liigse numbri ja hõivas suure hulga mälu: 20 GB asemel 2. Keegi ei märganud. Rakendusel oli 3 repliiki, nii et kannatasid lausa 3 sõlme.
4. Seadsime ressurssidepiirangud, ümberplaneerisime podid õige taotlusega ja saavutatud ideaalne tasakaal raua kasutamisel kõigis sõlmedes. Mõne sõlme oleks isegi saanud sulgeda. Siis nägime, et meil on vale masin (suunitletud CPU, mitte mälu suunas). Vahetasime tüüpi ja kustutasime veel mõned sõlmed.

Kokkuvõte

Burstable ressurssidega klastris kasutate olemasolevat riistvara tõhusamalt, kuid Kubernetes'i planeerija planeerib podid ressursi nõudmiste alusel, mis võib põhjustada probleeme. Kuidas ühte saamata jätta: vältida probleeme ja kasutada ressursse maksimaalselt — vajalik on kvaliteetne jälgimine. Selleks sobib Kube Eagle (Prometheuse eksportija ja Grafana juhtpaneel).

Allikas: habr.com