Niliunda Kube Eagle - msafirishaji wa Prometheus. Ilibadilika kuwa jambo la baridi ambalo husaidia kuelewa vizuri rasilimali za makundi madogo na ya kati. Mwishowe, nilihifadhi mamia ya dola kwa sababu nilichagua aina sahihi za mashine na kusanidi vikomo vya rasilimali za programu kwa mzigo wa kazi.
Nitakuambia juu ya faida , lakini kwanza nitaeleza nini kilichosababisha ugomvi na kwa nini ufuatiliaji wa hali ya juu ulihitajika.
Nilisimamia vikundi kadhaa vya nodi 4-50. Kila nguzo ina hadi huduma ndogo na programu 200. Ili kutumia vyema maunzi yaliyopo, matumizi mengi yalisanidiwa kwa RAM na rasilimali za CPU zinazoweza kupasuka. Kwa njia hii, maganda yanaweza kuchukua rasilimali zilizopo ikiwa ni lazima, na wakati huo huo usiingiliane na maombi mengine kwenye node hii. Naam, si ni nzuri?
Na ingawa nguzo ilitumia CPU kidogo (8%) na RAM (40%), tulikuwa na matatizo mara kwa mara na maganda yalipojaribu kutenga kumbukumbu zaidi kuliko ilivyokuwa kwenye nodi. Wakati huo tulikuwa na dashibodi moja tu ya kufuatilia rasilimali za Kubernetes. Kama hii:
Dashibodi ya Grafana yenye vipimo vya cAdvisor pekee
Kwa jopo kama hilo, sio shida kuona nodi zinazokula kumbukumbu nyingi na CPU. Tatizo ni kujua sababu ni nini. Ili kuweka maganda mahali, mtu anaweza bila shaka kuweka rasilimali zilizohakikishwa kwenye maganda yote (rasilimali zilizoombwa sawa na kikomo). Lakini hii sio matumizi ya busara zaidi ya vifaa. Nguzo hiyo ilikuwa na kumbukumbu ya gigabytes mia kadhaa, wakati nodi zingine zilikuwa na njaa, wakati zingine zilikuwa na GB 4-10 zilizobaki.
Ilibainika kuwa kipanga ratiba cha Kubernetes kilisambaza mzigo wa kazi kwa usawa katika rasilimali zinazopatikana. Mpangilio wa Kubernetes huzingatia usanidi tofauti: sheria za ushirika, uchafu na uvumilivu, wateuzi wa nodi ambazo zinaweza kupunguza nodi zinazopatikana. Lakini katika kesi yangu hapakuwa na kitu kama hicho, na maganda yalipangwa kulingana na rasilimali zilizoombwa kwenye kila nodi.
Nodi ambayo ina rasilimali nyingi za bure na ambayo inakidhi masharti ya ombi ilichaguliwa kwa pod. Tuligundua kuwa rasilimali zilizoombwa kwenye nodi hazikulingana na matumizi halisi, na hapa ndipo Kube Eagle na uwezo wake wa ufuatiliaji wa rasilimali ulikuja kuokoa.
Nina karibu nguzo zote za Kubernetes zinazofuatiliwa tu na ΠΈ . Node Exporter hutoa takwimu za I/O na diski, CPU, na matumizi ya RAM, huku Kube State Metrics inaonyesha vipimo vya kifaa cha Kubernetes kama vile maombi na CPU na vikomo vya rasilimali za kumbukumbu.
Tunahitaji kuchanganya vipimo vya matumizi na vipimo vya maombi na vikomo katika Grafana, kisha tutapata maelezo yote kuhusu tatizo. Hii inasikika kuwa rahisi, lakini zana hizi mbili kwa kweli hutaja lebo tofauti, na metriki zingine hazina lebo za metadata hata kidogo. Kube Eagle hufanya kila kitu yenyewe na paneli inaonekana kama hii:
Tuliweza kutatua shida nyingi na rasilimali na kuokoa vifaa:
- Watengenezaji wengine hawakujua ni huduma ngapi za rasilimali zinazohitajika (au hazikusumbua). Hakukuwa na njia ya sisi kupata maombi yasiyo sahihi ya rasilimali - kwa hili tunahitaji kujua matumizi pamoja na maombi na mipaka. Sasa wanaona vipimo vya Prometheus, kufuatilia matumizi halisi na kurekebisha maombi na vikomo.
- Programu za JVM huchukua RAM nyingi kadri zinavyoweza kushughulikia. Mkusanyaji wa takataka hutoa kumbukumbu tu wakati zaidi ya 75% inatumiwa. Na kwa kuwa huduma nyingi zina kumbukumbu ya kupasuka, ilikuwa inamilikiwa na JVM kila wakati. Kwa hivyo, huduma hizi zote za Java zilikuwa zinakula RAM zaidi kuliko ilivyotarajiwa.
- Programu zingine ziliomba kumbukumbu nyingi sana, na kipanga ratiba cha Kubernetes hakutoa nodi hizi kwa programu zingine, ingawa kwa kweli zilikuwa huru zaidi kuliko nodi zingine. Msanidi programu mmoja aliongeza kwa bahati mbaya tarakimu ya ziada katika ombi na kunyakua kipande kikubwa cha RAM: GB 20 badala ya 2. Hakuna aliyegundua. Programu ilikuwa na nakala 3, kwa hivyo nodi 3 nyingi ziliathiriwa.
- Tulianzisha vikomo vya rasilimali, tukapanga upya maganda na maombi sahihi, na tukapata uwiano bora wa matumizi ya maunzi kwenye nodi zote. Vifundo kadhaa vingeweza kufungwa kabisa. Na kisha tuliona kuwa tulikuwa na mashine zisizo sahihi (zilizoelekezwa kwa CPU, sio za kumbukumbu). Tulibadilisha aina na kufuta nodi kadhaa zaidi.
Matokeo ya
Ukiwa na rasilimali zinazoweza kupasuka kwenye nguzo, unatumia maunzi yanayopatikana kwa ufanisi zaidi, lakini kipanga ratiba cha Kubernetes hupanga maganda kulingana na maombi ya rasilimali, na hii imejaa. Ili kuua ndege wawili kwa jiwe moja: ili kuepuka matatizo na kutumia rasilimali kwa ukamilifu, unahitaji ufuatiliaji mzuri. Hii ndiyo sababu itakuwa na manufaa (Msafirishaji wa Prometheus na dashibodi ya Grafana).
Chanzo: mapenzi.com